Problem with MOV/MPEG4...

[hello_hello]

VMR9(renderless) is the least accurate - you will always have elevated black levels. If you want the intel or any graphics card settings to affect your video, set it to video overlay mixer. Then the graphics card overlay settings will directly affect the video. You probably have other issues on playback configuration

I'd need to find myself disagreeing with that. I always use VMR9 (renderless). I'd use MadVR except I use dual monitors at different refresh rates (CRT monitor and TV), and for some reason when using MadVR, Reclock is obvlivious to the change of represh rate when I move the player from one monitor to the other. The Reclock issues is another story though.... all the screenshots I posted previously were using VMR9 (renderless) with the video card changing the levels. So for me, the levels are expanded by the video card when using VMR9, if I tell it to.
The tests kiki_vg performed earlier changing the levels with the video card drivers inticated the VMR9 levels were also being expanded by the video card.
I guess maybe there's differences between PC according to the flavour of drivers and version of Windows etc. I don't really know, I've not played around with this sort of thing much using any PC other than my own (XP, Nvidia).

Often people are more attracted to "contrast", but technically that's not the correct way to do it. Recall I said open source decoders, ffmpeg, libav, avidemux etc... decode at full range. That's fine if the conversion to RGB for display is done with full range matrix . The problem is you're not doing it that way, you're using standard range matrix for viewing - so the image is more contrasty, areas are clipped

So you're basically saying the encode which converted the levels to limited range would be "correct" (for want of a better description)?
Have you looked at the samples in post #8? I'd be interested in a second opinion. Using my TVs in-built media player to play the samples, I'd vote for the Handbrake encode looking "right", so the levels should be converted to limited when encoding.

kiki_vg,
Basically the way it works, is when video is full range, "0" is black and "255" is white. When it's limited range, "16" is black and "235" is white. PC's work in "full range" while video is normally limited. So if you display a limited range video on a PC monitor which expects "0" to be black, it'll display "16" as dark grey. Yet for the limited range video, "16" should be black. That's why when you play video on a PC it can look a little washed out if the levels aren't expanded on playback.

Try this:
Open the original video with MeGUI's script creator and preview. Switch to the Script tab. At the end of the script, add the following:

Levels(0, 1, 255, 16, 235)

The "1" is the gamma level. You can adjust it, but forget about it for the moment. The rest of it converts the full range levels (0-255) to limited/TV levels (16-235). If you were to convert the other way (TV to full range), it'd look like this:

Levels(16, 1, 235, 0 255)

If you add the full range to limited range conversion to the script
Levels(0, 1, 255, 16, 235)
and use the preview button you'll see the levels change. "Technically" I think that's the correct way to do it. They should be converted. It looks perfectly fine for your sample from post #8.
There's no right or wrong in what looks best though, so you could adjust the way the levels are converted when encoding to suite your taste. If there's not enough contrast you can effectively give it a little more by converting the levels something like this:

Levels(0, 1, 255, 8, 235)

Try that in the script and compare it to the normal full range to limited conversion. You'll see it appears to have a little more contrast?

Or you could do a normal full range to limited conversion while reducing the gamma a little if you think it needs adjusting:

Levels(0, 0.9, 255, 16, 235)

I guess what I'm saying is for me, converting the levels from full range to limited range when encoding seems the correct thing to do, but that'd be a kind of "baseline". From there, there's nothing stopping you from tweaking/adjusting to taste. The camera picture isn't always going to be perfect regardless of the levels it uses.

[poisondeathray]

GPU's have several settings. There are ones that govern the desktop (e.g. browser, non video programs) that are separate from the video overlay. The "video overlay" is the one that directly controls overlay mixer (that's why it's called the "overlay mixer")

VMR9 (renderless) has the highest CPU usage out of any renderer, and always has elevated black levels . If you've calibrated it (with test charts, test videos) to be "correct" that means the other renderers will be incorrect for that setup

The "most correct" video is Hanbrake and Adobe PP - because they have legal levels, and are not flagged otherwise.

He "likes" the high contrasty look (many general public do) , but it's not correct because there will be missing details (e.g. the rocks) that are clipped on the RGB conversion with a standard matrix when viewed. What happened was avidemux uses libav (decodes full range, because it accepts the full range flag in the MOV), encoded (levels passed though), but it wasn't flagged as full range. So it's decoded and converted to RGB for display with a standard matrix. (Full range data , viewed with the "rec" matrix, not "pc" matrix) . If it was flagged full range, and your setup read flags properly, then that avidemux version could have been ok as well

And I agree that's the "correct" thing to do, convert to limited range, or use a decoder that decodes std range in the first place. Most configurations aren't setup to handle full range correctly, or might not read/obey flags .

[hello_hello]

VMR9 (renderless) has the highest CPU usage out of any renderer, and always has elevated black levels . If you've calibrated it (with test charts, test videos) to be "correct" that means the other renderers will be incorrect for that setup

I didn't know that. My TV isn't calibrated as such, just adjusted to what I think looks correct, which wasn't all that far off the default "standard" setting anyway. I think I just reduced the saturation and sharpening to a more natural level and disabled all the picture enhancing stuff.
Now I think about it, I think I put some black on the screen, then increased the brightness until I could see the first few dancing grey pixels appear in the black area (with my nose an inch from the screen) then I reduced the brightness until they disappeared, and that's about as calibrated as I got.

I can't at the moment, but I'll do some renderer comparing later.

[kiki_vg]

Try this:
Open the original video with MeGUI's script creator and preview. Switch to the Script tab. At the end of the script, add the following...

I will test what ever you want no problem, but clear for me one thing.

If I want to see original Canon video on expanded. For that I must set on VMR9 in MPC, right?
And that's this your image, right?

Original expanded

[Attachment 24524 - Click to enlarge]

If I want to see original Canon video not expanded. For that I must set on madVR, right?
Your image, original not expanded, right?

[Attachment 24525 - Click to enlarge]

If I want to see video converted with adobe/handbrake, in MPC I must set on VMR9, right?
Your image, handbrake expanded, right?

[Attachment 24526 - Click to enlarge]

If I want to see video converted with adobe/handbrake, in MPC I must set on madVR, right?
Your image, handbrake not expanded, right?

[Attachment 24527 - Click to enlarge]

And that's exactly how I see my videos, original and converted (with adobe/handbrake).

What confuses me is picture of original video with expanded levels, shouldn't it looks like converted video with expanded levels?
That I can't understand. In my head this two image should looks the same, same way not expanded videos should looks the same. But, ok, if I'm wrong, if that some rules how should be, then OK.
So, that mean, if I want to my converted video with adobe/handbrake looks exactly like original video with expanded levels looks, then I must edit and set that colors in Adobe for that, right?

If that way how I should set settings to see expanded and not expanded levels, then I agree with you, avidemux is not doing good job.

[hello_hello]

Well I'll confess if there's a difference between renderers I'm struggling to see it. I put some black on the screen and played with the brightness and black seemed to be black at the same point for each renderer. If there's differences, I don't know how to look for them, or they're pretty subtle.

I'm not sure if screenshots would really prove much, but here's what I'm seeing. The Nvidia drivers are set to expand the levels.

VMR9 on the left, EVR on the right, and MadVR on the bottom. They're stacked that way so I could resize all three to fit on the TV at the same time and compare them side by side. Even when I maximise all three on the TV and switch between them that way I can't tell them apart. Well..... MadVR obviously resizes differently because fullscreen (the video is 720p) I can see it's a fraction sharper, but that's an upscaling thing. The levels and colours look the same to me.

[hello_hello]

If I want to see original Canon video on expanded. For that I must set on VMR9 in MPC, right?
And that's this your image, right?
Original expanded

[Attachment 24524 - Click to enlarge]

If my video card is set to expand the levels, then that's how it looks for me using VMR9. Too dark.

If I want to see original Canon video not expanded. For that I must set on madVR, right?
Your image, original not expanded, right?

[Attachment 24525 - Click to enlarge]

Yes, When I use MadVR is doesn't expand the levels of the original regardless of the driver settings.

If I want to see video converted with adobe/handbrake, in MPC I must set on VMR9, right?
Your image, handbrake expanded, right?

[Attachment 24526 - Click to enlarge]

That's the same as the previous, yes? Then if that's the Handbrake encode, to see it that way using VMR9 I'd need to have the video card expanding the levels.

If I want to see video converted with adobe/handbrake, in MPC I must set on madVR, right?
Your image, handbrake not expanded, right?

[Attachment 24527 - Click to enlarge]

That's not expanded, but MadVR does expand, so it shouldn't look like that using MadVR. For me it looks like that if I use VMR9 and the video card is set not to expand the levels.

What confuses me is picture of original video with expanded levels, shouldn't it looks like converted video with expanded levels?
That I can't understand. In my head this two image should looks the same, same way not expanded videos should looks the same. But, ok, if I'm wrong, if that some rules how should be, then OK.

The original video has full range levels, They shouldn't be expanded on playback, but when using VMR9 and I have the video card set to expand the levels and it just expands everything, even though the original is already full range. That's why the first pic looks too dark to me when using VMR9. With MadVR it's fine.

So, that mean, if I want to my converted video with adobe/handbrake looks exactly like original video with expanded levels looks, then I must edit and set that colors in Adobe for that, right?

I'm confused now...... Adobe and Handbrake are converting the levels to limited. On playback the levels would normally be expanded again, so those versions should look the same as the original.

I'd trust MadVR. I'm sure if you open each version with it you'll find the original, Adobe and Handbrake versions all look the same. The MeGUI/Avidemux version should look darker than the original because it's levels weren't converted to limited range when encoding. Therefore Adobe and Handbrake are getting it right.

The way it works for me is if I open the original video using MeGUI and compare the preview to the original video being displayed using MadVR, the MeGUI preview looks darker.
After adding the conversion to the script:
ColorYUV(Levels="PC->TV")
MeGUI's preview looks the same as the original (MadVR).
When the video is encoded with the conversion in the script, the encoded version has limited levels. Display the encode using MadVR and it'll expand the levels (correctly) and it'll still look the same as the original.

Having said all that, there's different ways to convert the levels (it's another story). The method I described earlier may produce a slightly different result on some videos, because it limits the luminance range.

The levels function has a parameter called "coring". You can read about it here. http://avisynth.nl/index.php/Levels

I think the upshot of it though is these two methods should convert the levels to limited range the same way and when they're expanded back to full range they should look the same as the original:

ColorYUV(Levels="PC->TV")
Levels(0, 1, 255, 16, 235, coring=false)

This may look slightly different ("good different" or "bad different" might depend on the video).

Levels(0, 1, 255, 16, 235)

[hello_hello]

I think now poisondeathray has agreed with me I can fairly confidently say.....

Convert with MeGUI.

Stick this at the end of the script MeGUI creates:
ColorYUV(Levels="PC->TV")

And everything will be okay.

[poisondeathray]

You can only use 1 video player at a time when doing your tests. Only 1 video instance can use the graphic card, the other video instances won't be

It's only "full range" if your initial decoder decodes it as full range. If your decoder ignores the flag, then it's not full range. If I strip the full range flag, then it will be limited range in all decoders. In fact that's what some people do with Canon cameras. Many argue that the full range flag shouldn't be there in the first place

ColorYUV(Levels="PC->TV") will work, but technically it's actually not ideal - If your intent was to have everything is standard range YUV, decoding it while ignoring the full range flag will give you a picture that has no banding. Because ColorYUV works in 8bit, no dithering, you might be able to see banding in some situations. You can certainly pick up the banding using a waveform monitor. Basically any manipulation has the potential to degrade the image. Decoding it full range, then "squishing" the levels is certainly a manipulation. You can reduce it by using dithering (either smoothlevels instead, or levels with dither=true)

[hello_hello]

You can only use 1 video player at a time when doing your tests. Only 1 video instance can use the graphic card, the other video instances won't be

So how does it work when I've got three instances of MPC-HC open at the same time, all playing video (not paused) on the same monitor?

It's only "full range" if your initial decoder decodes it as full range. If your decoder ignores the flag, then it's not full range. If I strip the full range flag, then it will be limited range in all decoders. In fact that's what some people do with Canon cameras. Many argue that the full range flag shouldn't be there in the first place

I guess I can only go by how the OP's samples look to me. Without converting the levels to limited range when encoding, the encoded version looks too dark to me (or too much contrast), so from that perspective I'd consider the original to be full range.
Assuming how it looks to me is how it'd look to most other people..... that's why I was hoping some other posters would download the samples and offer an opinion.

[LigH.de]

You can only use 1 video player at a time when doing your tests. Only 1 video instance can use the graphic card, the other video instances won't be

So how does it work when I've got three instances of MPC-HC open at the same time, all playing video (not paused) on the same monitor?

It depends on the renderer.

Only one player can use the "Hardware Overlay" renderer. But there are other renderers which can be used several times.

[poisondeathray]

Only 1 video player can use the GPU graphics overlay. The other instances will default to another renderer that isn't GPU assisted (the renderer might not be using what you think it is). This is discussed in quite a few threads - you can search if you want more info. Basically it affects almost all video applications except most NLE's because their preview doesn't directly use the overlay settings - they are affected by the windows GDI (desktop) settings , not video overlay settings

Taking screenshots through a media player isn't always "accurate" because of this, even if you have only 1 instance. Some renderers don't allow you to take screenshots , some alter the appearance of the screenshot. You always have to ask how the screenshot was taken. Besides the renderer, other things can affect the "screenshot" - For example if I take a screenshot with vdub, it will use Rec601 (not 709) . If I take a screenshot with VRM9 (renderless) , the black levels will be elevated (at least on some setups)

If MPCHC was set to use something like QT for decoding (since it's a MOV) , it would look limited range - would I conclude that it's limited range ? It's functionally clamped but you dont' see the characteristic banding that you see when you adjust the levels from full range. The reason is it's decoded at limited range, not decoded at full range then levels "squished" .

I agree you should definitely keep things legal range YUV because most setups only handle legal range properly. But if you setup MadVR correctly, it can handle full range if it's flagged full range.

[hello_hello]

All very interesting...... thanks for the info.

If MPCHC was set to use something like QT for decoding (since it's a MOV) , it would look limited range - would I conclude that it's limited range ? It's functionally clamped but you dont' see the characteristic banding that you see when you adjust the levels from full range. The reason is it's decoded at limited range, not decoded at full range then levels "squished" .

So would Handbrake/Adobe be decoding it at limited range? I'd assume so given I don't recall mention of level adjusting in Handbrake's log file. If that's the case then I guess it'd be better to convert using Handbrake then convert with MeGUI while adding levels conversion to the script.

Even though I've been to the MPC-HC settings page at least half a dozen times today, I forgot MPC-HC had a separate option for QuickTime video. So I guess I don't quite understand how that works.

Why do these two configurations give me different levels when playing the original mov file (VMR9 is darker with the video card set to expand the levels) given the Quicktime video setting remains unchanged? I don't have anything Quicktime/Apple installed. What exactly would the definition of "Quicktime video" be?

[poisondeathray]

Yes, have a look at handbrake's log file there might be some clues as to what it's doing behind the scenes. Adobe doesn't adjust levels unless you tell it to, so it's decoding at standard range (and there is no funky YUV<=>RGB business going on, because PP CC is able to work in YUV natively)

I'm not sure how MPCHC handles that renderer choice internally for QT vs. DirectShow . You could ask one of the developers. But before the Renderer choice, the internal configuration matters - ie. what splitter and decoder is being used for MOV files. If you don't have anything Apple/QT installed, likely it's set to use the internal configuration. But if you see the lav icons or ffdshow icons pop up when you play the video, that tells you what decoder is being used (not the internal MPCHC configuration, but the system installed directshow decoder)

The definition of "Quicktime Video" is anything MOV wrapped

Also when you apply changes, make sure you close MPCHC (or any video player) and restart it before checking

[hello_hello]

If you don't have anything Apple/QT installed, likely it's set to use the internal configuration. But if you see the lav icons or ffdshow icons pop up when you play the video, that tells you what decoder is being used (not the internal MPCHC configuration, but the system installed directshow decoder)

It's using LAV for decoding when playing mov files.