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

Christoffer Glans

Christoffer Glans

Well-known member
Joined
Jun 11, 2007
Messages
4,993
Reaction score
36
Points
48
Age
42
Location
Stockholm, Sweden
I've been using Adobe Media Encoder for most of my transcodes, but it seems that all master exports from Resolve doesn't transcode well in Media Encoder. There's a lot of gamma shifts happening when trying to do mp4-conversions (youtube/vimeo/webb delivery).
Rendering out in video levels from Resolve should be correctly gamma-corrected when playing the file, but Media Encoder seems to encode the flatness into a new file instead of reading it correctly.

Is there a totally non-destructive MP4-encoder that translates the grade into an MP4 without destroying any color or gamma? Or is there a setting in Media Encoder that takes care of this?
 
What happens if you just render out directly from Resolve? That's what I do, and it looks OK to me, for purposes of a quick client viewing copy for the web.
 
Hey Christoffer,

Have you tried playing the same file in both quicktime and VLC to see if it might be the player? I noticed gamma shifts with prores changing between playing it back in QT and vlc. QT washed it out but when uploading to vimeo it looked fine. I probably have my head up my rear but it's worth a shot.
 
Here's the issue I'm trying to get right.

In these two pictures I've used the same source. The first image shows an in Avid AMA-linked import of the original DNxHR444 file rendered out of Resolve with video levels. The second shows the AMA-linked H.264 rendered through Adobe Media Encoder based of the same DNxHR444 file.
Clearly, Adobe Media Encoder destroys the video level handling and washes out the file. The histogram in the first image shows how it's supposed to be, while the histogram of the H.264 shows a flatter wrong look, even though it's a Media Encoder render of the same file.


Image 1 - Original DNxHR444 (video levels from Resolve).
levels1.JPG




Image 2 - H.264 4K render based on the original DNxHR444 file, rendered with Adobe Media Encoder.
levels2.JPG
 
It's not a quicktime, it's an .mp4 The gamma issues also are mostly present on Macs, while I'm on PC.
Thing is that Adobe Media Encoder is the only encoder that I find can create great quality videos, it's just that when encoding mp4s this happens and I'm not sure how to get rid of it.
 
Christoffer Glans said:
It's not a quicktime, it's an .mp4 The gamma issues also are mostly present on Macs, while I'm on PC.
Thing is that Adobe Media Encoder is the only encoder that I find can create great quality videos, it's just that when encoding mp4s this happens and I'm not sure how to get rid of it.
Click to expand...

Well .mp4 works just the same.

It can fuck things up in a few different ways.

It gets a tag telling the reader to show it with 0,0,0 rased above legal levels. kind of lifting the left bottom control point on curves to 10 I think it is.
Or you encoder actually burn the file with the values lifted to 10 (or what evert the legal level is, don't remember the exact number)
Or you reader has a tag that tells it to display it above legal levels.
Or your system got a tag telling all or some programs to display the file at legal levels...

it could only be lifted 10,10,10 in the bottom and or also pushed down 10 in the top or both or even worse, i could be the encoder setting that clips 10 in the bottom and 10 in the top.

When my clients have the displaying issues on their computers and see clipped or lifted films I tell them to use VLC to view it, a lot of times that actually display it right. As VLC does not really seem to care for those display tags.

And even if mp4 is not a quicktime I think it´s rendered trough the same pipe, no?
 
It's showing up as washed out in every player, VLC, QT, Windows Media Player classic etc. but the thing is that Avid doesn't interpret, it notes on the actual file levels before suggesting conversion, if you do it by AMA-link and check the source settings. This is why there's something off.
 
Have the same issue here, only my .mp4 exported video is darker than my ProRes master sequence in Premiere CC.
 
Does it need to be an .mp4, can it be a .mov instead?

The best h264 encoder out there is the x264 encoder, which on Mac you can install as a component of Quicktime.

PC I'm not so sure, it may be a standalone command-line encoder or there may be a way to install it as part of Media Encoder, etc and on PC it probably does make .mp4 files.

It's open source: http://www.videolan.org/developers/x264.html

I've never had gamma issues with x264 and it's also the encoder used by Vimeo, Youtube etc, it's open source and the defacto web standard and has far more controls for motion estimation, inter and intra frames than any of the standard NLE toolsets for encoding H264.

(Of course, if you're already using it then it's a whole other kettle of fish...)
 
None of this makes sense. I rendered out a quicktime from Resolve in DNxHR444 in UHD resolution and video levels. That's exactly what you should do.
Now, looking at the file in Avid shows the correct values for video levels and also seem correct on my output monitor.

Now...

I need to encode a UHD youtube H.264 and the best encoder to get high quality low sized files for this is the Adobe Media Encoder. Everything else I've tried just outputs extremely large files or low quality encoding, even though it's at the same bitrate. But when I do this, the file gets washed out. It's not washed out in the sense that it's a player issue, it's washed out in any player and shows up wrong in both Avid and Resolve when checking the levels there.

So, there's CLEARLY something wrong with how Avid Media Encoder is coding these files as they should show up as correct in software that interpret based on the file, not some computer gamma, right?
 
...to continue. I tested uploading the video-levels H.264 file to youtube and it looked like crap on all my devices. It doesn't look right at all. I now rendered out a data levels file from Resolve, the way you're not supposed to do. Now, when encoding in Media Encoder it looks a bit dark and crushed and the H.264 does look slightly different in it's levels, but it definitely look a lot closer to what my grade in Resolve looks like.

But this should not be, video levels should transfer correctly throughout. I've been involved with discussions before about the video vs data levels, but it always comes down to this problem. Whatever people say, the end result is never correct when I use video levels and Adobe Media Encoder is a freakin joke when it comes to managing this input/output. If the upload to youtube renders this wrong, then it clearly is a problem that isn't player-related.
 
This is the difference on youtube... clearly something wrong, right?

Youtube Video levels H.264 (Media Encoder)
youtubevideo.png


Youtube RGB levels H.264 (Media Encoder)
youtubergb.png
 
Render SMPTE color bars and a grayscale test pattern, and look at what happens to those on a scope. Then if needed, alter the rendered video accordingly to compensate. I would bet it's a fairly simple linear change (unless things are getting clipped/crushed).

Either that, or avoid using Media Encoder. Again: is there an issue with just rendering out H.264 directly from Resolve? I do it all the time, and it's fine.
 
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.
This is why I asked about another encoder. Are there any encoders capable of doing the good quality encoding and small file sizes like Adobe Media Encoder while not destroying the file in the way it does?

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?
 
It might not suit your preferred workflow, but if you haven't tried it, MeGUI (http://sourceforge.net/projects/megui/) does x264 encoding and allows for lots of adjustments/tweaking of encoding parameters.

So many variables and potential points of failure though when transcoding and uploading to Youtube for viewing on the web. For example, I've uploaded 4K stuff that has very similar gamma shift issues to what you've shown above, until you manually drag the timeline in the Youtube player back several times to make the original gamma somehow kick in (!). And even that 'solution' still doesn't work when viewing at lower resolutions in the Youtube player.

Good luck with it anyway. If you find a good solution to the file-size vs. image-quality challenge let us know.
 
I'm against putting parameters of color and gamma changes into the encoding software since I've already done critical color grading. The solution is not "grading in the encoding software".
 
x264 doesn't really provide many parameters for colour and certainly none will be on be dafault. MeGUI looks like a really good solution for encoding using x264 on a PC, I'd give it a go.
 
Will Steer said:
x264 doesn't really provide many parameters for colour and certainly none will be on be dafault. MeGUI looks like a really good solution for encoding using x264 on a PC, I'd give it a go.
Click to expand...

Doesn't support UHD or DNxHR444. This encoder is not an advanced professional encoder. I need something that can encode UHD H.264.
 
You must log in or register to reply here.
Back
Top