Exported file much brighter than original

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.

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. 🙂

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.