Exported file much ...
 

Exported file much brighter than original  

  RSS

Lightforce
(@lightforce)
New Member
Joined: 5 months ago
Posts: 3
04/05/2019 4:56 pm  

Hello!

I have tested the trial version 2.0.0 today. Great and fast Plugin! Unfortunately the exported video is much brighter than the Original from my GoPRO HERO (YUV 4:2:0). With the latest Lagarith-Plugin I don't have this issue but it seems that it converts the color to the wrong format (rec.601 instead rec.709). That's one of the reason why I wanted to use Magic YUV instead, even because I would save some time when I don't want to have converting the colors back to rec.709 like with Lagarith. But what could be the reason for the much brighter result or is this a limitation of the trial version?

This topic was modified 5 months ago by Lightforce

Quote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 3 years ago
Posts: 174
04/05/2019 5:26 pm  

Hi and welcome,

rec.601/709 mismatch usually results in some color shifts, but it shouldn't be something very apparent, especially not in brightness. I'd suspect it's more likely to be a full-range/limited-range mismatch issue.

The trial is identical to the full version (same speed and features), the only difference is that the trial puts a watermark on top, that is all.

Could you describe your workflow/process in detail (format of footage, programs being used, program and codec settings, codec variant used, etc.)? In addition to that, please enable logging in the global MagicYUV VFW codec configuration dialog, do a processing, and then send me all the logfiles (you can look at them yourself too). Also take note of the red/green [M] icon in the taskbar notification area while compressing/decompressing: if you hover your mouse over it, it will show some details about what format is it currently processing (raw input pixel format, resolution, etc.), that information is also crucial.

Also, if you have a short sample clip that I can try, that can be helpful too.


ReplyQuote
Lightforce
(@lightforce)
New Member
Joined: 5 months ago
Posts: 3
04/05/2019 6:10 pm  

I've edited my thread once again which unfortunately wasn't updated after I did it two times (moderated), so I repead once again what I've found out meanwhile. It seems to be that this only happens with MPC-HC when playing AVI's, even the Magic YUV encoded files. After encoding it with MeGUI and the x264 codec in MP4 format, the colors looks nearly as bright as the original from my GoPro HERO. So it's not an issue with your codec (I'm so glad). 😀

Apart from that it would be interesting what's the reason for this and how can I fix it so that Magic YUV and possibly other AVI's plays in the same brightness. I'm thankful for every tip. 🙂

This post was modified 5 months ago 2 times by Lightforce

ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 3 years ago
Posts: 174
04/05/2019 6:34 pm  

MPC-HC complicates things, as it has it's own decoder for MagicYUV built-in (through ffmpeg), so it can sidestep the official MagicYUV codec entirely. The best way to ensure that the official MagicYUV codec is being used is to enable the notification icon in the global MagicYUV VFW codec configuration dialog and look for the green/red [M] icon on the taskbar notification area during playback/encoding. If it's not there, then something else is decoding MagicYUV.

Anyway, even in the above case, it should still decode exactly the same as the official codec, albeit much slower.

The issue is most likely that MPC-HC requests the codec to decode as YUV (most likely as some form of YUV 4:2:2, as that is a commonly hardware-accelerated pixel format), in which case the conversion to RGB for final display could happen somewhere inside the graphics card, even out of reach for MPC-HC, and in that case global graphics card driver video settings kick-in. I remember nVidia having limited/full-range YUV/RGB settings globally, which kick-in in this case, and could cause misinterpretation issues.

The difference between the above (MPC-HC), and editing software is that editing software almost always present RGB to the codec during encoding and request RGB from the codec during decoding. You can call this the app-codec "interface" or "boundary" pixel format. Using RGB is a safe bet, as it doesn't suffer from misinterpretation of rec.601/709 and limited/full-range issues, as all RGB-YUV conversion happens inside the codec. MPC-HC prefers playback speed, and uses formats which are faster to transfer/decode, but could cause these issues in case of YUV.

In general, it is best to always use limited-range for YUV (and also have your graphics card driver video settings as such), except when you are in total control and know what happens at each step of the encode/decode pipeline.


ReplyQuote

Please Login or Register