X264 vs. H264...

[Subhadip Sen]

Yep, x264 can be really impressive. It's a good example for free/open-source software thats worth a closer look even for professionals. This applies to stuff like AviSynth and MPCHC or MadVR too. The HTPC-scene with all those pixel-counters (meant in a positive way) has brought up lots of good solutions. They're a bit tricky to handle from time to time, but its worth to spend some time with it.

Your encode looks nice, especially when you keep in mind what the source and bitrate is. I'll check it later on a 50" plasma..

RED's footage is just a dream for encoders, so much clean detail, no noise.... Just superb.

Indeed - open source has some of the best options for image making. AviSynth scripts are superb and often superior to their more popular commercial alternatives. MCTemporalDenoise, Deshaker, GradFun etc. offer technically superior results to their commercial counterparts. MPC-HC and MadVR are just the best option for playback, no question. The best codecs are open source too - X264, of course, but also lossless codecs such as UT or Lagarith. I guess the issue is that many of the above mentioned tools are not available on Mac OSX.

 

[Eric Z]

Maik,
In MPC-HC, I set the QuickTime format to use "QuickTime" instead of "DirectShow".
This allowed me to open the ProRes LT MOV file in MPC-HC, and here there was another surprise!
Blacks actually looked black, and the video had a nice contrasty look.
MPC-HC was running without any special shaders or ffdshow trickery. Color Management was disabled (enabling it makes the video too dark, no matter which rendering intent I chose).

I uploaded this comparison image for you guys to see the difference that a player makes:


(click the image for a larger version)


Mind you - the same ProRes LT file is playing on both players on the same computer!

A side note - I noticed banding on both players, so it probably originates from the ProRes encode.
QuickTime displays the video in a flatter look - something color graders need prior to grading.
MPC-HC displays the video in a more contrasty finished look. This does cause some lost details in the shadows, but makes the movie more pleasant to watch (notice the left shoulder of the old Chinese actor).

 

[Maik Müller]

Mind you - the same ProRes LT file is playing on both players on the same computer!

Looks like the typical result when something isn't working with the right levels (TV vs PC, the grey black-bars are a good indicator for that). Its funny to see MPC-HC doing a better job than quicktime, even while its using quicktime's components.

Edit: Banding while playing the ProRes could actually be only a playback-issue (bad 10bit > 8bit conversation).

 

[Michel Hafner]

For a high quality preset X264, 30 Mbit/s is an obscene bitrate. That's the kind of bitrate one uses with 4K 10-bit X264s (Very Slow preset)!
Of course, for Blu-ray AVCHD, 30 Mbit/s is a standard bitrate. X264 is a different story altogether. The "Very Fast" X264 preset is on par with AVCHD. The "Very Slow" preset is several times more efficient.

I don't get your point. AVC/H.264 is not an encoder, it's a standard. x264 is an encoder that encodes following that standard. So x264 is not more efficient than AVC. Apples and oranges. It is more efficient than the encoders studios usually use, it seems. I have not seen detailed comparisons, though. I wish Warner's sub 20 Mbit/s discs were encoded with x264 and AVC standard and not VC-1 for sure. You can encode for Blu Ray with x264 as you can with any other encoder following the AVC/H.264 standard. 30 Mbit/s for 1080p is high for x264, yes. But if it gets rid of visible artifacts I'll take 'obscene' any day over 'decent'.
:tongue_smilie:
(The thread title itself is misleading, it seems.)

 

[Aaron Shirley]

Imagine you have a short (like "Tattoo") and want to post it. You need a small file so you try to encode in H264 but it looks like shit. What to do. Post it with X264? Then everyone has to download a codec.

This is not right.

Jim

I had to download QT the first time I wanted to play an H.264...

 

[Stacey Spears]

I wish Warner's sub 20 Mbit/s discs were encoded with x264 and AVC standard and not VC-1 for sure.

WHV stopped using VC-1 in late 2010. The exception was Inception because Nolan requested VC-1.

Banding while playing the ProRes could actually be only a playback-issue (bad 10bit > 8bit conversation).

I believe 8-bit is all you can get from the Windows ProRes decoder.

 

[Subhadip Sen]

I don't get your point. AVC/H.264 is not an encoder, it's a standard. x264 is an encoder that encodes following that standard. So x264 is not more efficient than AVC. Apples and oranges. It is more efficient than the encoders studios usually use, it seems. I have not seen detailed comparisons, though. I wish Warner's sub 20 Mbit/s discs were encoded with x264 and AVC standard and not VC-1 for sure. You can encode for Blu Ray with x264 as you can with any other encoder following the AVC/H.264 standard. 30 Mbit/s for 1080p is high for x264, yes. But if it gets rid of visible artifacts I'll take 'obscene' any day over 'decent'.
:tongue_smilie:
(The thread title itself is misleading, it seems.)

No one's denying that AVCHD and X264 are part of the same H.264 / MPEG-4 Part 10 standard. It is simply a matter of which features are enabled, how many B-frames are used, motion estimation method used, ME range, Subpixel refinement etc. For AVCHD - as used in Blu-rays - these settings are equivalent to X264 at the "Very Fast" preset. However, X264's "Very Slow" preset takes efficiency to a new level. This preset will simply not be compatible with X264 as AVCHD does not support UMH motion estimation, amongst several other things.

Similarly, H.264 allows for 4K 4:4:4 at upto 12-bit. AVCHD tops out at 1080p 4:2:0 8-bit. Once again, a restriction of the implementation. Note that in my post, I never once mentioned "H.264/AVC" but two implementations - AVCHD and X264. Yes, the thread title is indeed misleading! One of the main reasons is that the standard itself is regularly updated - whereas AVCHD hasn't been for years now. Which is understandable, as it would need all the Blu-ray players to be replaced as well. X264 is free of these limitations.

Of course, there's one broad standard - but every software library heavily distinguishes itself from the next in how it uses this standard. And no, due to the varying features, they are not necessarily cross-compatible (decoding).

I hope this clarifies!

It may be that you used the first 1GB file as a source, but this leaves a lot to be desired.

Can you do the same with the actual ProRes, or with a grab from the 2k x264 that is up now?

Yes, on a pixel-peeping level it is not acceptable, but I am sure you will see that it is a marked improvement over the Source. As many have pointed out already, ProRes is a major headache - especially on the Windows platform. Ideal would be a well encoded 4K X264!

Ultimately, I don't believe these rare issues detract much from the viewing experience. For most of the video, even the 1GB X264 posted holds up just fine.

 

[Danny Robashkin]

I think everyone missed my comment since it was just one line.....

Load the file in QT, and if you have a dual screen move the player so at least some pixels are on the second monitor. It will fix the gamma issue and look nice, contrasty, and saturated.

Don't ask me why....... or better yet, tell me why this is

 

[Eric Z]

Edit: Banding while playing the ProRes could actually be only a playback-issue (bad 10bit > 8bit conversation).

I set MPC-HC to use 10bit:

Please don't mind that the option is grayed-out in this screenshot. When the ProRes LT movie was playing, it was enabled.

There's no way I can tell if the player actually enabled 10bit.
My monitor (Dell U2410) supports 10bit color. My GPU (NVIDIA GTS 450) does not due to NVIDIA's driver restrictions.
However, MPC-HC reported that it wasn't using DXVA, so it was using only the CPU to decode the movie.

 

[AndreeMarkefors]

I had to download QT the first time I wanted to play an H.264...

But this is how it's supposed to be.

Since 2009 there has only been one delivery format, and that is h.264 wrapped up in a .mp4, .m4v, .flv or .mov.

mp4 should probably be preferred since it's probably the most platform agnostic. It plays well on mobile devices, consoles, PCs (Mac and Windows) and everything else, with hardware acceleration included. It's used for acquisition on consumer and prosumer cameras and camcorders.

If you cannot play a mp4 in 2011, your computer is not correctly configured. It's fair to expect that you as a user installs the most widespread codec, especially if you have anything to do with movies or video.

I'm stating this pretty "matter-of-factly", because it's how the world looks today. I'd be very surprised to learn that Windows 7 doesn't play h.264 out of the box?

If you're on an older machine, keeping up to date with codecs and plugins is one of the chores I guess?

 

[AndreeMarkefors]

Do we have moderation on these boards? It's an honest question... I just don't know...

Then someone could perhaps lift out all the posts describing personal difficulties with compression and codecs so that we can return this thread to its original intent: comparing and getting to grips with the best way to encode h.264?

Troubleshooting posts can get their own thread, thereby increasing possibility of success.

 

[Eric Z]

@AndreeMarkefors,
This post is about describing personal difficulties with compression. That's what Mr. jannard was trying to convey.

 

[AndreeMarkefors]

Yes, on a pixel-peeping level it is not acceptable, but I am sure you will see that it is a marked improvement over the Source. As many have pointed out already, ProRes is a major headache - especially on the Windows platform. Ideal would be a well encoded 4K X264!

Ultimately, I don't believe these rare issues detract much from the viewing experience. For most of the video, even the 1GB X264 posted holds up just fine.

Hey, Subhadip!

I appreciate that you took the time to do it!

I didn't look at your source frame yesterday, but looking at it now I see that your output is very similar to the source.

Unfortunately both are totally f-cked up! =)

Have you had the chance to look at the new x.264 encode or Jarred's ProRes? The source you used is the file Jim was seriously unhappy with (rightly so). It's gamma shifted and smoothed out. Nothing like the original. A quick comparison:

Your source

Actual source

I would be very interested in if your method can compress the real source with no or very little banding.

I've already shown that normal production tools such as the Adobe Media Encoder can do this at bit rates over 20Mbit, but the target bit rate is closer to between 5 and 8 Mbit.

 

[AndreeMarkefors]

@AndreeMarkefors,
This post is about describing personal difficulties with compression. That's what Mr. jannard was trying to convey.

I politely beg to differ.

Jim described his unhappiness and asked us if we could solve it.

I have done several encodes with various methods, and I then posted the images for discussion.

They have since drowned in what seems to be a log of various personal misfortunes.

I really don't want to come off too agitated, but I often quickly get weary on this board...

 

[Michel Hafner]

For AVCHD - as used in Blu-rays - these settings are equivalent to X264 at the "Very Fast" preset. However, X264's "Very Slow" preset takes efficiency to a new level. This preset will simply not be compatible with X264 as AVCHD does not support UMH motion estimation, amongst several other things.
.

I'm aware that the Blu Ray standard requires that not all x264 options and parameters can be set as one would like for best results, but could you please state a source for the claim that for the same target bit rate very slow preset for Blu Ray is as efficient as very fast preset for unrestricted preset?

 

[Subhadip Sen]

Hey, Subhadip!

I appreciate that you took the time to do it!

I didn't look at your source frame yesterday, but looking at it now I see that your output is very similar to the source.

Unfortunately both are totally f-cked up! =)

Ah, I see! Here's another try. The source is the 1GB X264. I have a feeling the problem was more to do with the PNG, but anyway, here are the new results: Source, Processed. The processed file is grabbed from a 5 Mbit X264 (CRF=16). As you can see, banding is reduced (though still problematic) despite compressing to 1/3rd the original bitrate, thanks to GradFun2DBMod, even though it is quick, dirty and untweaked.

Can you upload the 5 second section in ProRes (Or better)? I will try working on that. Not too keen on downloading 5GB of ProRes!

I'm aware that the Blu Ray standard requires that not all x264 options and parameters can be set as one would like for best results, but could you please state a source for the claim that for the same target bit rate very slow preset for Blu Ray is as efficient as very fast preset for unrestricted preset?

I can't find a source, unfortunately. But even if one were to use X264 to encode blu-rays, here are some restrictions for blu-ray compatibility which can be enforced with the --bluray-compat syntax:

bframe<=3, ref<=4, bpyramid<=1, weightp<=1, aud=1, nalhrd=vbr

X264 Very Fast: bframe = 3, ref=2, bpyramid = 2, weightp=1, no nalhrd restrictions, etc. There's very little documentation for the --bluray-compat string, but the overall settings do seem to be close to the Very Fast preset. Typical AVC encoders for Blu-ray use settings like bframe = 2, merange=8, bpyramid=1, etc., which are actually lower than the Very Fast preset. MainConcept High is one of the superior ones with bframe=3. Still, a far cry from bframe = 8 for Very Slow. Or UMH motion estimation or subme=10, etc.

 

[Erwin Vanderhoydonks]

Ok guys here is the 2K QT ProRes LIGHT file for you to play with.

Thanks, download about 50min, unzip and playing just fine. Thanks again...

 

[AndreeMarkefors]

Can you upload the 5 second section in ProRes (Or better)? I will try working on that.

Here's the door scene, since that's what I've been using:

http://www.productionfactory.se/reference/TATTOO2K-PRLT_Door.mov

This is 6 seconds worth of door opening and closing. It's 72MB, or so... I've used a sample of the door just after the stranger has entered the room, prior to the door closing again.

This server isn't built do cope with file sharing in any way. For the select few that already have ProRes installed and want to encode and then upload their results here, you can try it out.

PS. If Jim or Jarred have any objections to this, I'll take it down.

 

[Tom Wardrop]

But this is how it's supposed to be.

Since 2009 there has only been one delivery format, and that is h.264 wrapped up in a .mp4, .m4v, .flv or .mov.

mp4 should probably be preferred since it's probably the most platform agnostic. It plays well on mobile devices, consoles, PCs (Mac and Windows) and everything else, with hardware acceleration included. It's used for acquisition on consumer and prosumer cameras and camcorders.

I can see your logic there in preferring mp4, and it probably makes sense to use if targeting a wide audience, but popularity is a poor reason for standardizing a wrapper, and also short sighted - that sounds like a personal attack, but I can assure you it's not. MKV is with little argument, a superior format for distribution of multimedia. In addition to all the technical reasons, it's also an open standard which means it's unrestricted, easily adaptable, and wide open for criticism which promotes quality. Additionally, it's also codec agnostic, and hence will be able to cater for future codecs such as potentially RED's RedRay codec. If for example RedRay were to be wrapped in an MKV, you'd be able to take advantage of MKV's support for unlimited video, audio and subtitle streams as well as chapters, the ability to stream, etc.

 

[Eric Z]

+1 for MKV