Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

X264 vs. H264...

Jim, Jarred,

one question:

Is the ProRes 5 GByte file extracted via software only decoding or using the RED Rocket card?

Cheers,
Axel
 
Jarred Land said:
Ok guys here is the 2K QT ProRes LIGHT file for you to play with. Truth be told i still think X264 does a better job than PRO RES LT... but H.264 is horrible to encode from.

As you will see the 4:2:2 ProRes codecs are really shitty dealing with gradients ( introducing banding etc.) ,but lets see who can take this file and shrink it the best.

For you guys that just want to watch the movie in 2K.. this 5GB file might not be worth the download.. Jim is baking a X.264 Quicktime right now in the 1Gb file size so your better off waiting.

http://red.cachefly.net/TATTOO2K-PRLT.mov.zip
Click to expand...


Is there any chance you can cut some 10-20 secs in smaller compression, just to try something out ?
I wouldn't suggest transcoding from LT as it's very thin.
 
Jannard said:
We have spent days working on this. Quicktime H.264 really sucks... sorry to say.
Click to expand...

Yes, Apple implementation of H.264 and software support for it both suck.


Jannard said:
Anyone figure out how to make this work?

Jim
Click to expand...

Yes.

Throw .mov wrapper into trash for any highly compressed h.264. You can also try .mp4 wrapper and avoid Apple tool to compress it. You should be fine with adequate settings around 20Mb/s, avoiding folks having to download x.264 support and letting everyone know why the video doesn't play on their computer.
 
For windows users having problems with unzipping the file, rest assured, it affects mac as well. It seems only OS X's default Archive Utility can extract this file. The Unarchiver, a popular alternative to OS X's default archive utility, cannot handle this zip file either. God knows what the go is with it. Would be good to know from Jarred how the file was compressed, so we can all learn not to do it like that in the future :)

Similar to the gamma woes which plague video distribution, I think a potential root cause for how we got into this situation would have to stem from colour management. I hate colour management with a passion, and when I got my first Mac only about 9 months, it was and still is my biggest dissapointment with OS X. Unlike Windows, OS X is completely colour managed. That sounds like it might be a good thing, but it also means you can't turn colour management off. As a web designer who works with RGB values, colour management is one of the biggest problems I face on OS X, which is why I still do all my designs and HTML/CSS in windows. The problem with colour management (like gamma in this case) isn't the concept - the intention of these things is good - but it's more the case that the implementation is never right. Colour management was introduced to solve a problem, not create one. Colour management done right, is where you don't even need to think about it.

Anyway, that's my two cents on the problem.
 
I'm updating/reposting, so that you all don't have to go back and dig for the other images.

My own conclusion at the bottom.

-----------------
Here are some screen grabs for your viewing pleasure. Enjoy!

They are all encodes done in Adobe Media Encoder 5.5. 2 passes variable bit rates at the noted settings.

Keep in mind that when the movie is playing back, some "artifacts" that might seem obvious on a still frame is not noticeable at all.

TAKE NOTE! They are NOT necessarily the exact same frame, so don't judge slight luminance or color differences. This post is about banding.

This is 12Mbit max 20Mbit. Size=571MB
12-20.png


ADDED--> This is the x264 provided by Jim. Size=933MB, corresponding to just over 16Mbit/s
x264.png


This is 20Mbit max 25Mbit. Size=1.28GB
20-25.png


This is 32Mbit max 40Mbit which is the 1080p default HQ preset (probably for a reason). Size=2.17GB
32-40.png


This is ProRes LT, as provided by Jarred. Size=5.49GB
PRLT.png


NEW images for overall look and feel:

This is AME, 16 max 20 Mbit, slightly smaller in size to the x264.
bar1620.png


This is ProRes LT.
barPRLT.png


This is MPEG Streamclip, x264, about just over 16 Mbit/s.
bar1620.png



I created an uncompressed file from the ProRes to use in HandBrake, and it was 77GB in size. HandBrake didn't handle this too well and crashed. I did trim the uncompressed file down to the door scene to check for banding, and it was there, just like in Jim's x.264.

My conclusion is that it's hard to get rid of the banding. It is almost linear to the bit rate, and with obscene bit rates of 30Mbit it's no longer an issue.

Jim's file corresponds to roughly 16 Mbit and it has less banding than my 12 Mbit, but more than my 20 Mbit. It's important to note that you need a reasonable monitor to see this well. I have an Apple 24" Cinema LED (by no means a reference monitor), and here it's quite easy to see the nuances. Looking at this thread on an old LCD monitor yesterday it seemed that everything was silky smooth =)

The Bar scene shows (to me) that there are no disturbing gamma issues with these encodes. AME as well as MSC does a good job. There are however differences. AME comes out slightly (small amount) darker than ProRes and MSC come out slightly brighter (small amount) than ProRes.

AME is a wee bit less saturated than ProRes, whereas MSC is a bit more saturated. Look at the barkeeper's face, and the red lacing on the woman to the right.... (hey! I said the lacing!!! avert your eyes, pervert!! =) The door scene also shows the increased saturation in the x264. Booth scenarios are easily compensated for, once you know what you get.

In my very humble opinion, I would be very happy with booth the MSC x264 and the AME from around 16Mbit. Remember that this is a direct comparison on still images. Small differences are not noticeable on moving imagery. Especially if you focus on the storytelling.
 
Here's the 200MB X264 MP4: http://www.mediafire.com/?tt601t95yn5mxdy. I strongly recommend this be played on Media Player Classic with MadVR Renderer. The source for this, as I mentioned before, is the 1GB MP4.

It just goes to prove how powerful X264 is with the right settings - even at 3 Mbit.

For banding issues, the AviSynth plugin GradFun2DBmod works like magic. Just run your video through GradFun2DBmod and all banding vanishes.
 
AndreeMarkefors said:
My conclusion is that it's hard to get rid of the banding. It is almost linear to the bit rate, and with obscene bit rates of 30Mbit it's no longer an issue.
Click to expand...
Nothing obscene about 30 MBit/s. Available on Blu Ray and actually used on quite some discs, even clean sources (e.g. Avatar).
 
AndreeMarkefors said:
Can you please do that and put up a screen?
Click to expand...

Sure, here's a very quick and dirty run through GradFun2DBMod: Source, Processed.

The source itself (1GB MP4 Jim put up) has excessive banding, along with compression artifacts to make matters worse. The result is a 6 Mbit X264 which has much lesser banding than the source (~15 Mbit), as you can see! Check the right edge of the frame for a dramatic improvement. Do note that this is a very quick, light and rough application. With tweaking much of the banding can be eliminated, even in this extreme a situation.

Michel Hafner said:
Nothing obscene about 30 MBit/s. Available on Blu Ray and actually used on quite some discs, even clean sources (e.g. Avatar).
Click to expand...

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.
 
Michel Hafner said:
Nothing obscene about 30 MBit/s. Available on Blu Ray and actually used on quite some discs, even clean sources (e.g. Avatar).
Click to expand...

Well, I'm talking about web distribution. I guess this whole thread is about that.

I don't think anyone is questioning the fact that it should be possible to put a feature on BluRay and make it look OK.
 
Yes, re-zipping with another program would be the solution, but the problem isn't caused by the .DS_Store file and __Mac_OSX folder (that stuff is just annoying, but doesn't result in problems for pc-users). Its caused by the compressor itself, apples zip-program creates invalid archives when it comes to stuff >4gb. I had this problem before....

In the meantime, all you unlucky windows-users can grab the unpacked file (zipping such a large file it into a single zip doesn't make much sense at all) from my friends server:

http://einert.org/red/TATTOO2K-PRLT.mov
http://einert.org/red/TATTOO2K-PRLT.md5

It looks like its ok to post links for re-encodes, i hope applies to a 1:1 mirror too.
Jim, Jarred, let me know if not.

Happy encoding. ;-)

PS: We can create a multi-volume rar or 7zip-archive too, if prefered, but the server should be stable enough to handle large single-file-downloads.
 
Last edited:
Subhadip Sen said:
Here's the 200MB X264 MP4: http://<a href="http://www.mediafir...http://www.mediafire.com/?tt601t95yn5mxdy</a>http://www.mediafire.com/?tt601t95yn5mxdy. I strongly recommend this be played on Media Player Classic with MadVR Renderer. The source for this, as I mentioned before, is the 1GB MP4.

It just goes to prove how powerful X264 is with the right settings - even at 3 Mbit.

For banding issues, the AviSynth plugin GradFun2DBmod works like magic. Just run your video through GradFun2DBmod and all banding vanishes.
Click to expand...
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.
 
Maik Müller Menendez said:
RED's footage is just a dream for encoders, so much clean detail, no noise.... Just superb.
Click to expand...

I'll agree that it's a dream for the camera owner =)

But it's actually the opposite for the encoders. The noise free image is what causes the banding.

It's similar to when you do 3D renderings that are totally clean- or perfect. It can help to add a minimal amount of noise to the render to help break up smooth gradients. That makes it easier for compression algorithms like .jpg or h.264 to find a good solution.
 
I took the file (on a USB flash stick) and hooked it up to a friend's MacBook, and unzipped it there.
Since my USB flash stick was formatted as NTFS, I was lucky that he had Parallels installed on it, so I could use the virtualized WinXP to move the Tattoo MOV file back to my USB flash.
What a mess...and it's not over yet.

Copied the file to a hard-drive on my Windows 7 Ultimate machine, and surprise! MPC-HC v1.5.2.3058 can't play it. VLC v1.2 beta can't play it. Those two are the only ones I use cause they're supposed to handle almost any format.
The latest K-Lite Codec Pack is of course installed, madVR v0.61 is installed, CoreAVC Pro v2.5.1 is installed. But none of that helps. I tried setting MPC-HC to use EVR Custom Preset, then I tried madVR - still nothing.

The only player that could play it was Apple's QuickTime Player.


But wait!!
The 5.03GB ProRes LT video looks washed out.
The 946MB x264 2K MP4 video looks better.

I'm using a pretty good monitor - Dell U2410 24" LCD 1920x1200.
What is going on here?
 
Eric Z said:
Copied the file to a hard-drive on my Windows 7 Ultimate machine, and surprise! MPC-HC v1.5.2.3058 can't play it. VLC v1.2 beta can't play it. Those two are the only ones I use cause they're supposed to handle almost any format.
The latest K-Lite Codec Pack is of course installed, madVR v0.61 is installed, CoreAVC Pro v2.5.1 is installed. But none of that helps. I tried setting MPC-HC to use EVR Custom Preset, then I tried madVR - still nothing.

The only player that could play it was Apple's QuickTime Player.
Click to expand...
Yeah, its a prores-file, there is no other codec than the one for quicktime.
You can configure MPCHC to use quicktime instead of trying to find directshow-filters for mov-playback (under player/formats) but thats giving you only a better frontend for playback. Its not possible to use alternate filters like MadVR with ProRes-files.

The washed-out look could be a problem of quicktime itself and the renderer it uses.
 
Looks like I just stumbled upon the gamma issue that Mr. Jannard was talking about...
 
Maik Müller Menendez said:
Yes, re-zipping with another program would be the solution, but the problem isn't caused by the .DS_Store file and __Mac_OSX folder (that stuff is just annoying, but doesn't result in problems for pc-users). Its caused by the compressor itself, apples zip-program creates invalid archives when it comes to stuff >4gb. I had this problem before....

In the meantime, all you unlucky windows-users can grab the unpacked file (zipping such a large file it into a single zip doesn't make much sense at all) from my friends server:

http://einert.org/red/TATTOO2K-PRLT.mov
http://einert.org/red/TATTOO2K-PRLT.md5

It looks like its ok to post links for re-encodes, i hope applies to a 1:1 mirror too.
Jim, Jarred, let me know if not.

Happy encoding. ;-)

PS: We can create a multi-volume rar or 7zip-archive too, if prefered, but the server should be stable enough to handle large single-file-downloads.
Click to expand...

Thanks for the mirror. Once I get the file this way, I'll post my encode.
 
You must log in or register to reply here.
Back
Top