Patching AVC Video to Full Level

Marco. wrote on 5/14/2020, 3:52 PM

Some of you may know one of the very few real issues of Vegas Pro relating to video output levels is for any kind of AVC rendering Vegas Pro would add the "limited range" meta data, no matter if you really ensured your levels are limited or full range. So if you're going to output a full level AVC video, no matter if you do accidentally or intended, those decoders which read and use that kind of meta data will finally output false/clipped levels (such like MPC player or the YouTube upload decoder).

Of course if you accidentally output full level video, you probably usually use a "Computer RGB to Studio RGB" conversion in Vegas Pro instead. But for an intended full level output you could use FFmpeg tools to just patch your final video without the need of a re-encoding.

And here's a way I use Vegasaur to patch the meta data of a final rendered clip to "Full Level" which is then correctly read and used by players like MPC and the YouTube upload decoder (remember this is for AVC rendering only):

In the Smart Trim tool of Vegasaur open the "Build Custom Command" window (like seen in the screenshot above) and copy and paste this text into the command line window:

-ss {start} -i "{input}" -c:v copy -bsf:v h264_metadata=video_full_range_flag=1 -c:a copy -t {duration} "{output}[mp4]"


Then click the preset icon (the yellow star) on the lower left, select "Create", name your preset, done.
Your full level patch will be available via the preset list of Vegasaur's smart trim tool now.

Comments

Musicvid wrote on 5/14/2020, 4:32 PM

@Marco.

 

Does the reflagged video then report 'yuvj420p' rather than 'yuv420p' per the Apple flag?

Marco. wrote on 5/14/2020, 4:46 PM

I don't know, but I doubt. Do you have such an Apple file available for testing?

It's intended for the Vegas Pro AVC render output, having used either MainConcept AVC or Magix AVC (which color space meta data is always set to "YUV"). What it then does, and solely this, is changing the "Color Range" meta data from "Limited" to "Full".

 

Musicvid wrote on 5/14/2020, 5:07 PM

Its a flag for generic mp4 and m4v. It got spotty acceptance until VLC/ffmpeg decided to make it work.

What it then does, and solely this, is changing the "Color Range" meta data from "Limited" to "Full".

Ah yes, that's the way my MediaInfo version is now showing it, as Full and Limited, instead of yuvj420p and yuv420p respectively, with playback levels as expected for the two. Another way to do this is to enter

:fullrange=on

into a Handbrake options box, or

--fullrange on

in an x264 command line.

Finally, more footage from phones and portables is being flagged this way, so better results on Youtube. It's OK with me if Vegas never uses it, owing to large numbers of 2nd and 3rd generation downloads that are flagged just plain wrong!

Marco. wrote on 5/14/2020, 5:58 PM

I just tried patching to "yuvj420p" via FFmpeg but this doesn't seem to work. It looks like for such a conversion type it would need a re-encode (which I want to avoid). In the end the color range meta data should do the same, assumed a system reads and uses this data.

"It's OK with me if Vegas never uses it, owing to large numbers of 2nd and 3rd generation downloads that are flagged just plain wrong!"

Yes, and unfortunately even if the flag is set correctly, some systems read and use it and some do not. Impossible to properly handle this without having some knowlege about how a video will be finally processed.

Marco. wrote on 5/14/2020, 6:10 PM

Btw – if for AVC rendering you use Voukoder instead of Magix or MainConcept AVC you could directly set the appropriate range info in the color space filter. It should look like this:

The Vegas Pro AVC output then equals the patched MainConcept/Magix render in regards of the full range meta data (while in all these cases the true video stream data is untouched, which is unlike having used a "Computer RGB to Studio RGB" Levels FX).

Musicvid wrote on 5/14/2020, 10:28 PM

Yes, and unfortunately even if the flag is set correctly, some systems read and use it and some do not. Impossible to properly handle this without having some knowlege about how a video will be finally processed.

Yes -- Apple's folly. And Premiere's.