QuiskTime H.264 16 bit - is this possible?

[Andrew M.]

I just checked the specs for H.264 and it looks like QT 7.x is supporting H.264/MPEG-4 AVC combination.

look all the way down for QT 7.x description here:
http://en.wikipedia.org/wiki/QuickTime
http://en.wikipedia.org/wiki/QuickTime#QuickTime_7.x


but the H.264 is limited in its highest implementation 4:4:4 to 14 bits?
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles


Is this why so many people are reporting highlights clipping at 8 stops?

So how REDCINE and SCRATCH has a choice of QT H.264 16 bits?
Does it mean 10 bits or 14 bits?

While rendering to the 16 bit QT H.264 as oppose to 8 bit increases the size of the .mov file by 15% or so, can't figure it out.

Anybody can help me here?

 

[Andrew M.]

Originally Posted by Axel Mertes
Hi Andrew,

we did some research today.

According to our own search results and the current entries on

http://en.wikipedia.org/wiki/H264

we came to the conclusion that there is currently NO software that supports 11-14 bit high profile 4:4:4 H.264 encoding at all. See the lower part table in the wikipedia.

Even 10 bit seems to be almost out of reach.

I really wonder which software you are using there, that gives you these options...

The X.264 codec allows us to select many options that would yield towards the 14 bit capable profile, but the important setting is kept in baseline, so ending up in 8 bit output too.

We found two major issues with the H.264 encoding as of now:

1. The slight gamma shift, which is driving us nuts over here, as the very same file is having at least 3 different looks in playback on the very same incarnation of Quicktime, depending on how you play it etc.

2. The artefacts on lower quality settings. The 75% setting we used for COLD STORAGE teaser was almost the lowest end we can go, without further sacrificing the look with artefacts.

We did today encode a music video at 75% with H.264 and it was really bad experience, the background was a crappy ocean of banding. All the subtle gradients from the shooting where dying there. We'll try again tomorrow with higher quality settings to see how or if we can safe it.

What is your experience with brightness / gamma shifts in H.264 or QT in general?

Axel

I use QT H.264 16 bits from SCRATCH or REDCINE

However I don't see much difference between 8 and 16 bit setting, from there.

I see gamma shifts and bending.
Gama shifts you can try to fix by playing with gamma setting in project and export setting in AE and Encor.

After setting all parameters to wide RGB gamut and using the screen with wide gamut I managed to make things to look the same on the edit monitor and Blu-ray attached BRAVIA. It just took me one week or so to figure it out.
So no gamma shifts anymore but I can’t get rid of bending in some circumstances, like blue sky above the horizon. This drives me nuts….

It is probably because somewhere in the transforming chain, the linear 16 bit data is compressed in 8 bits log and then uncompressed back to 10 bit linear.

Andrew

 

[Jeff Brue]

tis not 8 bit log that fomat died a long time ago as useless.

 

[Andrew M.]

If it is not this so what it could be.
I just generated not compressed AVI from 16 bits tiffs and judging on the size of the end product file it is 8 bit AVI. As I read everywhere AVI is 8 bit 4:2:2 maximum.
I also don’t see much difference exporting from REDCINE or SCRATCH in QT 8 bit versus 16 bit.

Looks like the whole world except DPX and TIFF is set on 8 bit 4:2:2.
Only ProRes, I think is 4:2:2 10 bit maximum, is that right?

Is there a way out there to produce AVC as a H.264 High Profile Specification 10 bits ?

 

[Axel Mertes]

If it is not this so what it could be.
I just generated not compressed AVI from 16 bits tiffs and judging on the size of the end product file it is 8 bit AVI. As I read everywhere AVI is 8 bit 4:2:2 maximum.
I also don’t see much difference exporting from REDCINE or SCRATCH in QT 8 bit versus 16 bit.

Looks like the whole world except DPX and TIFF is set on 8 bit 4:2:2.
Only ProRes, I think is 4:2:2 10 bit maximum, is that right?

Is there a way out there to produce AVC as a H.264 High Profile Specification 10 bits ?

After all investigations - which you really triggered now on my side - I'd say that there is currently no easy way to encode an H.264 / AVC file with more than 8 bits. According to the wikipedia about "H264" there is only the product at http://www.vsofts.com/ that seems to allow 10 bit encoding. Even if you have a real 10 bit file, how would a player play it?

Technically, as its just digital data, it may be well possible that e.g. the PS3 decoded the 10 bit stream and outputs the pure digital data to the HDMI port. But it may also be the case that it internally just decodes in 8 bit, knowing it may not be capable of outputting more than this. There is no easy way of finding out.

Next problem, assuming we have real 10 bit AVC files and 10 bit playback, which monitor will shows us that 10 bit advanced difference - guaranteed?

I assume that not even RED CINE or SCRATCH will output to anything more than 8 bit in H.264, except you use e.g. the ProRes422 or Blackmagic Design or Cineform codecs as targets.

There are some codecs on the market that really support more than 8 bits, but then we have to ask RGB or YUV? 10 bit YUV is closer to 8 bit RGB in the end, given its 4:2:2 YUV to 4:4:4 RGB transformation. 10 bit YUV is like 20 bits in total in 4:2:2 mode, so you convert from 20 bits to 24 bits RGB? Not exactly, but thats the "digital" info being compared in quantities, not color reproduction.

So codecs that support 10 or more bits are:

Cineform
ProRes422
DNxHD
Leitch LTV/DPS
Blackmagic Design
Matrox DigiSuite & Axio
AVID

There are surely more I simply don't remember now.

I am currently doing some deep analysis on codecs encoder -> player color reproduction chain. I might have found a working "work around" - not a perfect solution IMHO - that I want to test within the next days. I will keep it a secret until I am sure how to handle it and how the results will look like.

But I can say it looks promising

So stay tuned,

Axel

 

[Ed Blythe]

Great post Axel, look forward to your follow up.

 

[Andrew M.]

Axel, PLAYSTATION3 game output is 12 bit as per tech specs.

I will call Sony support and check with them as to the video output from the file.

Looks like they do not use hardware for codecs since I didn't have VC-1 support when I got it first time.
I had to update firmware/os to have this ability.
Also, only from version 3 up they support AVC H.264

Mean time I am producing nice Blu-rays in AE and burning it in Encore.
Make sure that you do not transcode anything in AE, just link project from Encore and let Encore to do transcode from there.
Also, when scaling down from 4K take DPX or TIFF in to AE use colorista if needed, then do not process anything, edit all in 4K
At the end create new composition 1920x1080 with highest setting 24 or 29.97 (BRAVIA works with both) use scaling transform from 4K to 1080p by adding effect to the composition. This is very important, don't use anything else for scaling.
In effect->transform->scaling use SIN transform in transform setting, works great with details.

Now save project, close AE. Start Encore set project properties to Blu-ray H.264 set 24 frame 35/35 MBits/sec highest quality, enable color management and only now link to the AE project from file menu.
Check settings and project properties again create timeline and hit transcode.
Takes long but it is worth it.

So PLAYSTATION3 looks like it is just a small computer with tight code using probably some DSP.
Very good for checking Blu-ray final product, and not expensive.

I just have to read this:
http://electronics.howstuffworks.com/playstation-three.htm
http://www.theinquirer.net/en/inquirer/news/2003/01/07/playstation3-architecture-revealed
http://en.wikipedia.org/wiki/Playstation3

 

[Axel Mertes]

Hi Andrew,

while waiting for some feedback on our tests, I'll say thanks for these additions infos and your workflow decscription. We will give that a try over here.


Thanks,
Axel

 

[Andrew M.]

12 bits (bpc) Epson projector

12 bits (bpc) Epson projector

Just in case you want to go 12 bits bpc

http://www.sci-worx.com/news/press/detailpressrelease.aspx?id=414

and 12 bit ready Blu-ray player

http://www.krunker.com/2008/05/07/p...-players-elite-bdp-05fb-and-pioneer-bdp-51fd/


And 12 bit JVC large LCD

http://www.jvc.com/press/index.jsp?item=625&pageID=3&PressKitID=13


end this one has 14 bit internal color manipulation but nothing said about actual RGB bpc

http://us.sanyo.com/business/projectors/home_theater/index.cfm?productID=1524

It actually shows you how many bpc your imput is!
good for figuring out your level of bpc from your devices

 

[Axel Mertes]

Hi Andrew,

thanks for the links. We are currently investigating the hardware devices a bit more. We negotiate with Blackmagic Design and JVC these days, lets see what the results really are.

Further we have worked on our solution.

At least for the PC platform I have a working approach, which means I can create a H.264 Quicktime file that looks almost OK when played on PC Quicktime.

We do some research here to see if we can really make "cross platform" files as its basically desired.

We simply fight the fact that Apple managed to screw up the whole concept completely.

I am not happy to say that, but many pro users out there give a damn shit on Apple & Quicktime as long as the problem persists. This is an absolute NO-GO scenario for many of us.

Please see the attached JPG files for reference. One shows the actual result from a DPX sequence transcoded into Quicktime 7.3.1 with H.264 codec at 75% quality settings. The result looks nearly identical with Quicktime 7.4.5 H.264 codec at 100%, so this is NOT the issue causing the remarkable color & gamma shifts and changes.

Then there is the result with a special 3D LUT we had been working on, that pre-compensates the shifts caused by Quicktimes H.264 encoding engine. So we encoded again in Quicktime 7.4.5 a H.264 file with 100% quality setting. See how close the result matches the original, how small the binary difference results are.

Clearly there is still some color change in there, because of the quantisation that happens when data is processed in Quicktime in 8 bit. Our 3D LUT is applied in 16 bit color space, so the loss happens when 16 bit gets truncated to 8 bits and Quicktime applies its shifts to the color, loosing actually some gradiental steps.

I am actually absolutely not a friend of hire & fire policy, but if I were responsible at Apple I'd ask who is responsible for this problem not being addressed and give him a choice: Fix it or take your papers...

Looking forward to your results.

Cheers,
Axel

 

[Andrew M.]

Thank you for post.
I like the differentiation method you use, great idea!

I am experimenting with color space conversion in AE and Premiere.
When I load the 16 bit TIF without any corrections as a conversion from RED RAW
it shows up as a sRGB IEC6 1966-2.1 color space.
I am still having hard time to convert 16 bit to 10 or 8 bit color space using H.264 codec in AE or PR without banding artefacts.

 

[Axel Mertes]

Thanks,

differentiation is not perfect IMHO but a good way to catch the viewers eye on the issue. As the lower right is an auto-gained view of the differences, it could sometimes look really bad, but the result wasn't really that bad.

I think in future I may swap to a constantly gained "difference", so the results are more comparable.

The lower left is the real difference, in binary representation. Low frequency changes are usually not showing up much, resulting in a more or less black image. Thats then a good signal. If you see a grayscaled ghost image there, then its a gamma shift. If its a colored ghost image, then you are within color shifts (and probably gamma shifts too, at the same time).

I really really really wonder why programmers at Apple started with this crap at all, why they invested time to modify something which no one wants them to modify. If we encode videos, we want them in the colors they had. If codecs loose some details due to colors space conversions and compression quantisation artefacts, well, thats ok and can be expected. But what happens here is out of speak.

About the banding you see:

Can you create / encode artifical "gradients" into H.264 using your apps, that do not show the banding?

Or could you send me an image that I can encode for you, once with once without the LUT, so you can check if it makes a difference?

Cheers,
Axel

 

[Andrew M.]

Yes there is a way to make smooth transition in one color that looks smooth no banding.
Then if I want to adjust this color to make it just a bit different (adding say green to blue) I see on 8 bit tiff banding but no banding on the 16 bit tiff.

How can I upload the tiff file to you? it is 40+ MB?

 

[Axel Mertes]

Andrew,

I have PMed you, see your inbox.

Axel