H.264 for Mezzanines

[benwaggoner]

I've been mulling mezzanine files lately, and been thinking about H.264 as a mezzanine format.

There was a discussion about this a while ago, but it's probably time for a new thread.
http://forum.doom9.org/showthread.php?t=153689

Here's my thinking, comparing H.264 to other common mezzanine formats like MPEG-2, ProRes, and (more rarely) Cineform.

Pros

Supports >4:2:0, >8-bit, and RGB
Supports progressive and interlaced
Good aspect ratio flagging
Better efficiency than MPEG-2
Better maximum quality than MPEG-2, particularly with heavy film grain
Broadly supported in decode
Lots of container and audio codec options
Both intra-only and intraframe encoding options
Lossless encoding mode available


Cons

Slower to decode in software
Modes beyond 8-bit 4:2:0 not as widely supported
Modes beyond 8-bit 4:2:0 less often HW decoded


The Cons aren't really that bad, considering, and High Profile MPEG-2 isn't universally supported as well.

I imagine doing something like this, but feedback appreciated!

CALVC only. CABAC is less advantagous at higher bitrates, and a lot more expensive to decode.
Use the most restrictive profile matching the source. So, if coming from MPEG-2 4:2:2, use High 4:2:2 8-bit. But ProRes HQ would use 10-bit 4:2:2
Use Level 3.0 for SD, Level 3.2 for 720p, Level 4.1 for 1080 <50p.
Allow full buffer size and peak bitrate for the Profile@Level.
Encode with a low CRF. 10? Emperical testing would be done to find a CRF where a few generations of encoding could be applied without introducing artifacts that would impact the final encode.
Short Closed GOPs for fast random access. 1-2 seconds max?
Mux in the source audio without recompression.
--preset fast? This sort of thing is generally done on fast machines, and often the source decode is the bottleneck. Having a significantly smaller mezzanine can be worth a someone slower time to create. And, of course, a lower bitrate mezzanine would be faster to transcode from.


Questions:

Would using slices with CAVLC meaningfully help software decoding speed on multicore machines?
What --tune mode? Default? Grain?
What alpha/beta? -2, -2 low enough?
What B-frame pattern? Strict pyramid with 3 B (IbBbP)? All P-frames? Simple IbP?
MPEG-4 file or Transport Stream?

Is anyone actively doing this today? Any learnings to share?

[CruNcher]

hehe my first days i began immediately doing this and got superb results over 8 bit cineform back the days Visual Lossless even @ a very early dev state compared to now :) and i did 10 Generation recoding tests, though 8 bit you can already do in Consumer hardware nowdays and keep even cabac, im currently working on some Quicksync thinks and want also to get intermediate compares running again but x264 is so efficient that it's really hard to get something usable out of it on the lowest levels @ least cabac and high bitrates is what could be really interesting and i gonna get their :)

http://cruncher.mufflastig.com/hdtv/hdv/intermediate/avc-intra/x264-intra.txt

http://cruncher.mufflastig.com/hdtv/hdv/intermediate/avc-intra/01.png to 10.png there is though a chroma decoding issue here, which got the decoder producing this to be fixed after ;)

[Atak_Snajpera]

i often use avc-intra only encoding for intermediate files. x264.exe --preset superfast --tune fastdecode --keyint 1 --CRF 14.my output container is mp4 because sony vegas does not like avc-intra only in m2ts (choppy playback)

[AnonCrow]

For mezzanine files , wouldn't it make more sense to use QP , and even set ip|pbratio to 1 ?

[smok3]

just some brainstorming;

on osx, (I do a lot of short stuff) and:

- anim.mov gets great over adobe apps and its also instantly playable over aja-kona
- anim.mov is HUGEEEE, but provides a nice icon in my finder window :P
- going from anim.mov to say 10bit 422 lossy or lossless x264 seems like a good idea, but any reediting will have to make new intermediates, since i can't open those in adobe stuff edit: update keyint=1 does open in adobe (or anything else and i can't easily view them on broadcast monitor since aja-tv will refuse to...), no thumbs, no quicktime playback (and perian is not my friend).

(for longer stuff i'd use prores for hd and uncompressed for sd (possibly dvcpro if there are huge amounts of interlaced material - transcoding to dvcpro with ffmpeg is amazingly fast, like 7x realtime ))

Basically i'd need something much smaller than anim.mov but with same or similar quality and instant editability, osx finder thumb is actually a great feature as well...

I could not figure out how to use ut-video qt component really (but the decoder in ffmpeg is working fine (have a lot older ut.avi stuff), so again i have to make new intermediates of some sort to put this into editability mode...)

p.s. prores would almost fit, but:
- tired of geting the same ****** gamma bug
- ffmpeg encoder is quite slow

@ben: you need to fix your link to the book (i think you need to use "invert" transform of some sort).

p.s.2. in terms of intranet video sharing "10bit 422 h264" would fit great, since it can be played with flash nicely nowadays, so this file can be used for say 2nd backup... (waiting to re-write a new thumbnail-maker script for the server-side).

[kieranrk]

You've mostly described Panasonic's AVC Ultra Long-GOP here, which I don't think is too far away from standardisation.

RGB isn't well supported at all and I don't see why that would be needed for a mezz.

[Blue_MiSfit]

I see you dug out my old thread! That was a long time ago when I was considering doing a bulk ProRes -> H.264 mezzanine transcode to scavenge a bunch of free space. That never ended up happening.

However, I did a bit of H.264 mezz work using a Digital Rapids STREAM capture system and the VFW interface to x264 - specifically a modified build with built-in output options for MKV / MP4 etc (bypassing VFW limitations).

What I settled on was 8 bit 4:2:0 (since this was all that was available at the time), using ~ CRF 10-12 for 1080p / 1080i sourced from HDCAM-SR. I was using --tune fastdecode, and a fast encoding preset. I was also using a short GOP size - maybe .5 - 1 second. I was compliant with HP@4.1, using a 1 second buffer. The real-time requirement in conjunction with the capture card / system's small internal buffer made for a very picky encoding configuration, but I did get it working eventually.

Subsequent transcode was (as expected) slower than using an MPEG-2 source, but not by an enormous margin. The H.264 files did look noticeably better than the typical 50mbps MPEG-2 mezz files I'm all too familiar with, so I'd consider this exercise somewhat successful. Average bitrates were surprisingly low (30-50mbps +/-)

The transcode system in question is proprietary, but built around AviSynth so I ended up using MKV as my mezzanine container (with external AC3 / E-AC3 audio) and DirectShowSource + haali splitter + ffdshow to decode.

I think re-visiting this with newer x264 supporting 10 bit and 4:2:2 makes for a very interesting proposition.

My gut tells me that we could probably make a 1080i60 10 bit 4:2:2 stream at 100mbps that would be equivalent to ProRes 422 HQ (220mbps) in terms of quality, even after a bunch of transcode generations. It goes without saying that decode and seeking performance would be slower, but the extent of this difference and its impact on bulk transcode scenarios would be quite interesting to explore! The increase in necessary transcoding horsepower would probably more than pay for itself in the reduced storage requirement.

The ProRes decoder on Windows is an absolute dog (and not well threaded), so when trying to transcode a given stream as fast a possible it may even be faster to use H.264, provided you have extra cores to offload the decode.

Keep us up to date with what you find, Ben. I'm very interested!

Thanks,
Derek

[Atak_Snajpera]

My gut tells me that we could probably make a 1080i60 10 bit 4:2:2 stream at 100mbps that would be equivalent to ProRes 422 HQ (220mbps) in terms of quality, even after a bunch of transcode generations.
My tests show that in AVC-intra mode (--preset superfast --tune fastdecode) only very detailed sources such as parkjoy need very high bitrate.
for example
parkjoy_1080p50 needs something around 150-175Mbps to be visible transparent (At lower bitrates noise was starting to show up). So I think that we can safely assume 100Mbps enough for 30i and 30p even if source is 4:2:2

[smok3]

would there be a way to trick qt to behave as keyint=1 encodes are avc-intra?