Using x264 for Mezzanine files

[Blue_MiSfit]

Hi all,

I'm developing a workflow for encoding a universal mezzanine file using x264 at my job.

Basically, a "mezz" file is a high quality copy of whatever sources the facility ingests. We want to use x264 at 50mbps for 1080p content.

So, we'd take sources like ProRes, DNxHD, MPEG-2 or whatever, and transcode it to an MP4 containing 50mbps HP@4.1 H.264, with CAVLC for fast decode. This will then be stored, and the source will be killed.

This has plenty of benefits when it comes to transcoding to finally produce deliverables, but that's outside the scope of this discussion.

What I'm wondering about is how to tweak x264 for this application.

Psy optimizations are wonderful, but is it a good idea to leave them on in this case, under the assumption that the result will be transcoded again in the future. I'm probably going to use --preset veryfast in most cases.

Also, the default minimum QP in x264 (10) seems like a logical choice. Are there any benefits to be had from reducing it in this case? I sometimes get undersized files (which is perfectly fine) due to the encoder bumping up against this limitation / sanity check.

Other thoughts / suggestions are more than welcome.

Thanks!

~MiSfit

[Dark Shikari]

Lower qpmin can help on ridiculously dark footage.Psy optimizations are wonderful, but is it a good idea to leave them on in this case, under the assumption that the result will be transcoded again in the future. I'm probably going to use --preset veryfast in most cases.They should always be on. Trashing low detail areas is not a good idea ever, even if you're going to transcode again later.

[Blue_MiSfit]

Cool. Good to know. --preset veryfast still has AQ, but no RDO (given that it's using subme 1), right? I think I recall you saying subme 2 is HUGELY better than subme 1, so I may force that as well.

Given that we're budgeting for 50mbps, and don't really care - should I just lower qpmin to 1, thus virtually guaranteeing ~50mbps output? Will this break / frak up anything else?

Sample CLI:

x264.exe source.avs --bitrate 50000 --vbv-maxrate 62500 --vbv-bufsize 62500 --level 41 --preset veryfast --tune film --no-cabac --aud --output "out.mp4"


~MiSfit

[Dark Shikari]

No reason not to use qpmin 0.

I'm also pretty sure that level 4.1 allows a larger bufsize than that, but you should check what the specs of the format you're going for allow.

[Blue_MiSfit]

Cool.

Does Level 4.1 specify a max buffer size, or is that entirely up to the decoder design? I just assumed one second.

~MiSfit

[Dark Shikari]

Cool.

Does Level 4.1 specify a max buffer size, or is that entirely up to the decoder design? I just assumed one second.

~MiSfitIt specifies a buffer size, but everyone and their dog comes up with their own anyways (see Blu-ray).

[Blue_MiSfit]

Meh. Yes, I see.

What would you suggest for maximum compatibility? I think these files will almost always be worked with on a PC with a proper software H.264 decoder that is free from level restrictions, but I do want some degree of compatibility with hardware.

I will probably just use one second.. :p

[audyovydeo]

Hi all,

I'm developing a workflow for encoding a universal mezzanine file using x264 at my job.

Basically, a "mezz" file is a high quality copy of whatever sources the facility ingests. We want to use x264 at 50mbps for 1080p content.

So, we'd take sources like ProRes, DNxHD, MPEG-2 or whatever, and transcode it to an MP4 containing 50mbps HP@4.1 H.264, with CAVLC for fast decode. This will then be stored, and the source will be killed.

This has plenty of benefits when it comes to transcoding to finally produce deliverables, but that's outside the scope of this discussion.

What I'm wondering about is how to tweak x264 for this application.

Psy optimizations are wonderful, but is it a good idea to leave them on in this case, under the assumption that the result will be transcoded again in the future. I'm probably going to use --preset veryfast in most cases.

Also, the default minimum QP in x264 (10) seems like a logical choice. Are there any benefits to be had from reducing it in this case? I sometimes get undersized files (which is perfectly fine) due to the encoder bumping up against this limitation / sanity check.

Other thoughts / suggestions are more than welcome.

Thanks!

~MiSfit

I'm curious, because I toyed with this idea before, for my own stuff. I gave it up because I couldn't force myself to kill my sources. Since you seem willing to do that, doesn't this make lossless your only true choice ?
Also, what are your considerations regarding audio ?

just curious ...
audyovydeo

[magnatique]

Misfit,

I've been using crf 12 for my mezzanines following your suggestions a few months back, they work great for re-encoding.

I'll follow this thread to see what you come up with finally and possibly modify my methods.

I have had problems with importing the mp4s into Sony Vegas that we use for editing, so I had to use --keyint 30 --min-keyint 2 otherwize seeking was a HUGE problem. Aside from that, sometimes they'll work, sometimes they won't in vegas... it's really a toss I haven't been able to point the finger to what the problem was after too many tests... I finally went with the concept sony was crap and when they'd update their mp4 decoder, it would get fixed heh ;)

[Blue_MiSfit]

Regarding audio, I will likely be addressing that on a case per case basis. Most of my sources are MOVs with 2-8ch PCM, so I'll just dump these to a giant WAV.

Alternatively, I may store the H.264 mezz files with PCM audio in an MPEG Program Stream. Not sure.

Some audio sources I get as a 640kbps AC3, so I'll just keep those as-is, or mux into an MPG.

~MiSfit