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 :)

Non-destructive MP4 transcode

Hmm. Didn't say anything about colour-correcting during the transcode.

But yeah, MeGUI doesn't input DNxHR444's as far as I know...

In case anyone else is interested, the x264 encoder behind the MeGUI front-end does encode UHD resolutions. You can choose Level 5.2 or Unrestricted. Just transcoded an 8.75GB 6144x3160 Quicktime .mov (exported out of Redcine-X) to a 46.6MB H.264 mp4 to see how far it would go.
 
Christoffer Glans said:
You can't render out H.264 in UHD resolution from Resolve. Other encoders also have a problem with managing a good codec with small file size in that resolution.
Click to expand...
Ah, the only 4K file deliveries I've ever done have been in DPX or ProRes 444 and there is no change in either of those.

If this is a simple linear change, then how do I keep Media Encoder from screwing this up? Why can't companies just keep files as they are and not trying to stupidly compensate during transcode?
Click to expand...
What do bars and grayscale look like on a scope? This will tell you in seconds what's happening and will give you the technical information needed to diagnose and potentially solve the problem. Look at bars and grayscale in the original file, then look at the H.264 file.

Why not use H.265 or VP9, BTW? Wouldn't these be more appropriate delivery codecs for 4K? What I see Netflix, Amazon, and more and more online companies specify is MXF OP1a files. Here's Netflix' deliverable spec:

Screen%20Shot%202015-10-23%20at%201.02.44%20AM_zpsoyzypcy2.png


https://backlothelp.netflix.com/
 
Marc Wielage said:
Ah, the only 4K file deliveries I've ever done have been in DPX or ProRes 444 and there is no change in either of those.


What do bars and grayscale look like on a scope? This will tell you in seconds what's happening and will give you the technical information needed to diagnose and potentially solve the problem. Look at bars and grayscale in the original file, then look at the H.264 file.

Why not use H.265 or VP9, BTW? Wouldn't these be more appropriate delivery codecs for 4K? What I see Netflix, Amazon, and more and more online companies specify is MXF OP1a files. Here's Netflix' deliverable spec:

Screen%20Shot%202015-10-23%20at%201.02.44%20AM_zpsoyzypcy2.png


https://backlothelp.netflix.com/
Click to expand...

Bars and greyscale on a scope does not look correct, just as the images from Avid earlier shows. The H.264 file is brighter than the original file at correct video levels. The DNxHR444 is the same as a ProRes4444 delivery and it looks correct, that one is the master file I rendered out of Resolve. This is about the H.264 file that will go up on youtube. It doesn't look correct, doesn't matter if it's on playback on the computer, uploaded to youtube or on other devices. A video level, correct master file transfers to an incorrect washed out H.264 that has this problem everywhere. This is not a "player on my computer"-related problem, but something wrong with Adobe Media Encoder not being able to transfer correct values over to the H.264 file.

Scopes in Resolve show correct black and white levels just under peak on the RGB scale, rendered out in video levels should generate a perfectly correct file at video levels, which it does and it looks correctly when viewed in Avid. Problem only occurs on the H.264 file rendered through Adobe Media Encoder.

This is youtube 4K delivery. What encoders can encode in H.265 and VP9 keeping file sizes and overall quality great without gamma or level shifts?

Les Hillis said:
Hmm. Didn't say anything about colour-correcting during the transcode.

But yeah, MeGUI doesn't input DNxHR444's as far as I know...

In case anyone else is interested, the x264 encoder behind the MeGUI front-end does encode UHD resolutions. You can choose Level 5.2 or Unrestricted. Just transcoded an 8.75GB 6144x3160 Quicktime .mov (exported out of Redcine-X) to a 46.6MB H.264 mp4 to see how far it would go.
Click to expand...

Does it handle video levels correctly? Is the Redcine-X file at broadcast standards before coded to a H.264? A correctly balanced and graded image from Resolve rendered at video levels should show if it's handling everything correct.
 
Easier I think to get around the problem by applying a lut prior the export that compensate for the error. So if you find out what the error is in lift, gamma, gain. Then you can compensate for it. Possibly even in your adobe app as simple adjustments. Most likely it´s a lift/offset 10 or such that is needed. As that would be a normal legal color compensation/ fuckup.

Easiest whatch your scope and compare the clip in resolve to the exported darker clip then then compensate to get it right, as long as nothing is clipping you are not really losing anything.
 
Björn Benckert said:
Easier I think to get around the problem by applying a lut prior the export that compensate for the error. So if you find out what the error is in lift, gamma, gain. Then you can compensate for it. Possibly even in your adobe app as simple adjustments. Most likely it´s a lift/offset 10 or such that is needed. As that would be a normal legal color compensation/ fuckup.

Easiest whatch your scope and compare the clip in resolve to the exported darker clip then then compensate to get it right, as long as nothing is clipping you are not really losing anything.
Click to expand...

The only way to solve this was to render out "wrong" in that I used Data levels instead of Video levels. The output looks crushed, but put through Adobe Media Encoder it seems to look "ok". There's some shift more to blue, but that could just because of everything else destructive that happens with coding from 10 bit 444 format to an 8-bit mp4. I think that it's a little darker than the grade, but it's closer than the washed out version based on the "correct" video levels file.

I believe that Adobe Media Encoder isn't working as it should. There are not actual broadcast settings or histograms or anything to check that everything is right. Based on the LUTs within Media Encoder being focused on instagram-like looks like sepia and shit, it's clear to me that Adobe isn't really making this encoder to be a professional tool. If they were serious with that they would implement tools to manage color spaces and QC measurments of deliveries.
 
Can also confirm that the VP9 WebM free plugin for Adobe Media Encoder won't carry over the video level flag correctly. Looks washed out on youtube, not in the original file. Clearly Adobe Media Encoder skips color space information.
 
Björn Benckert said:
Get a smoke license and all your trouble will be gone. :)
Click to expand...

Haha pretty expensive way to solve a little issue. Better off paying Adobe to solve this for me :001_rolleyes:
 
Or... try MPEG Streamclip which is free. For my HD stuff I use only that. And also make my students use it ;)
 
Christoffer Glans said:
But I don't work in HD I'm afraid.
Click to expand...

Hehehe. Sorry, I guess you misunderstood my post. MPEG streamclip is perfectly capable of writing 4K H.264 - I just never needed to do so for projects. So do try it out!
If it's of any value: Jim J and Jarred where excited about the software when I pointed it out to them for exports a few years back.

For me, my exports are usually either 4K DCI or 1080p H.264 for now, that's why I haven't experimented with it thoroughly enough. But do let me know what you find out ;)
 
Here's the video in question. Because I couldn't solve it with "correct" video levels I rendered out data levels from Resolve which everyone is so inclined to call wrong and a no go. But the fact is still that this "wrong render" ends up at correct video levels when put through Media Encoder. I think it differs slightly from the grade I did, mainly the saturation went down a bit, but the shadows and highlights are far more correct on this. I tried it on every device and computer I could find and it all looks correct on youtube.

So... the fact is that Media Encoder is doing things wrong. The data level should come out as data level and video level as video levels. Instead, Media Encoder is brightening everything up a notch, whatever levels you put in. If it's video levels it comes out super-washed far under the values graded. If you render out data levels it comes out as video levels. So if you were to ever need data levels or extended range, you're screwed if you use Media Encoder. So maaaayybee Adobe should do it right for once and skip those sepia and instagram LUTs and actually focus on getting standard color spaces and delivery QC into Media Encoder. They don't need to do anything else in their next update... just... that... little... thing :P

 
I've found out that the video level / data level problems seem to occur when using DNxHR, while DNxHD seems to work. So Adobe needs to fix their DNxHR decoding asap.
 
You must log in or register to reply here.
Back
Top