LAV Filters - DirectShow Media Splitter and Decoders

[madshi]

madVR tries to detect the range and matrix of the source, but if the decoder doesn't say which it is, madVR can only guess, based e.g. on source resolution. In your case it seems the resolution is so small that madVR guessed the source to be BT.601 with TV levels. If the source is instead BT.709 with PC levels, you can either manually switch madVR (press [Ctrl+Alt+Shift+i] to switch the source between TV <-> PC levels; press [Ctrl+Alt+Shift+m] to toggle between different decoding matrixes). Or alternatively you could use file name tags to tell madVR what to do (add the text "matrix=bt601 range=pc" to the source file name).

[nevcairiel]

I think i asked this before, but if apparently Fraps is always BT.709, i might as well hardcode that somewhere, guess i forgot to actually follow up on that =p
I created a note in my task list, so i don't forget again.

[Reino]

Well, I don't know anymore, because I'm really confused now.
LAV/ffmpeg detects FPS1(yuvj420p) files as Full-range BT.709 and in order to correct the colours, in Avisynth one has to do a "PC BT.709" --> "TV BT.601" conversion, BUT in FFDShow and LAV+madVR it's actually BT.709 that gives the same results .

Originally Posted by madshi

press [Ctrl+Alt+Shift+m] to toggle between different decoding matrixes).

A key-shortcut is the only option available? There are no such settings elsewhere?

[DarkSpace]

Originally Posted by CoRoNe

Well, I don't know anymore, because I'm really confused now.
LAV/ffmpeg detects FPS1(yuvj420p) files as Full-range BT.709 and in order to correct the colours, in Avisynth one has to do a "PC BT.709" --> "TV BT.601" conversion, BUT in FFDShow and LAV+madVR it's actually BT.709 that gives the same results .

I think I see the problem here:
You indeed have to use fullrange BT.709 to convert the YUV back to RGB. However, because the renderer you use to display the YUV doesn't know this, it guesses that TV-range BT.601 should be used on that stream and subsequently uses that to convert to RGB. This means, of course, that you need to either make the renderer use fullrange BT.709 for conversion, or convert the YUV stream so that it conforms to TV-range BT.601 before sending it to the renderer.
This also explains the series of pictures you linked earlier: You took a snapshot of the YUV output without manually converting it to RGB, so the program you used to display the video assumed TV-range BT.601 (just like the video renderer) and the colors were distorted.

[madshi]

Originally Posted by CoRoNe

A key-shortcut is the only option available? There are no such settings elsewhere?

What other settings would make sense? Forcing BT.709 to be used for *all* video files? I don't think that's a good idea because there are many true BT.601 files.

[cyberbeing]

I tested some FRAPS 3.5.99 4:2:0 captures of a test pattern downscaled by madVR, and all required use of the fullrange BT.709 matrix to be displayed correctly.

Once you draw near to 307200 total pixels (640x480 or 736x416) or less, FRAPS seems to automatically force capture of lossless RGB.

[Reino]

@ DarkSpace: Those screenshots were extracted with AvsPmod, and whether I put a ConvertToRGB at the end of the Avisynth-script or not, it's doesn't change the result.

Ok, let's say we put "FFDShow raw video filter" between LAV VD and VMR9/madVR, to ensure the renderer doesn't know anything about the stream. FFDShow reports it's getting NV12 (Uncompressed) from LAV and puts out RGB32(VMR9)/RGB24(madVR). With default settings in "FFDShow raw video filter" the output for both renderers is now the same (LAV's default output) (whereas madVR performed a range-conversion before).
Now, if I let the "FFDShow raw video filter" convert the stream to Full-range BT.709 ("Output", "RGB conversion"), I get the same result when I go to "AviSynth" and enter ColorMatrix(clamp=0, inputFR=true) (i.e. a Full-range BT.709 to TV-range BT.601 conversion), with both renderers. Now can anyone explain that to me.

@ madshi: Makes sense. Ignore my post.

[nevcairiel]

You mean on this screen?


Selecting BT.709 there tells it to use BT.709 to convert to RGB, which is the correct thing to do, because thats what is used for Fraps YV12.
If you use AviSynth, it will have to convert to RGB at some point later, so assuming this conversion uses BT.601, and you convert from BT.709 to BT.601 before, it'll then look alright. (original BT.709 -> convert to BT.601 -> convert to RGB using BT.601)

Makes perfect sense to me.

[DarkSpace]

Originally Posted by CoRoNe

@ DarkSpace: Those screenshots were extracted with AvsPmod, and whether I put a ConvertToRGB at the end of the Avisynth-script or not, it's doesn't change the result.

Makes perfect sense. ConvertToRGB() defaults to always using limited-range Rec.601, regardless of resolution, so it only supports my theory of a conversion using incorrect parameters. For reference, you should use ConvertToRGB(matrix="PC.709") and try again, this should work as it's supposed to with the untouched YUV.

[aufkrawall]

Originally Posted by DarkSpace

For reference, you should use ConvertToRGB(matrix="PC.709") and try again, this should work as it's supposed to with the untouched YUV.

Result won't be accurate either since Fraps doesn't use exact 601/709 matrix.

[DarkSpace]

Originally Posted by aufkrawall

Result won't be accurate either since Fraps doesn't use exact 601/709 matrix.

Interesting. In that case, however, flagging the YUV stream as fullrange BT.709 for the renderer won't be correct, either (though it'll bring an improvement over BT.601).
Do you happen to be able to make the matrix available for anyone who wants to implement it? In that case, maybe a custom matrix designation could be passed to a renderer that supports it and enable it to use that matrix?

[aufkrawall]

Sorry, I'm not that techie, nor do I have such information available.
That must be cleared with the Fraps makers, I guess.

You may want to take a look at Handbrake, it seems to do a very good conversion for Fraps YV12, almost no difference visible.

[cyberbeing]

Originally Posted by aufkrawall

Result won't be accurate either since Fraps doesn't use exact 601/709 matrix.

Are you positive this issue still exists?

FRAPS 3.5.99 + LAV + madVR BT.709 appears to match the RGB values of my source when compared in Photoshop.

[aufkrawall]

Originally Posted by cyberbeing

Are you positive this issue still exists?

FRAPS 3.5.99 + LAV + madVR BT.709 appears to match the RGB values of my source when compared in Photoshop.

I'm going to test this hopefully tomorrow again and will also provide a sample.

[G_M_C]

@nevcairiel:

Some time ago i asked about ordered chapter MKV ( aka 'x-in-1'). You answered that it would eventually be implemented. And while I was working on my final exam paper, I missed that you've found the time to implement this feature.

So I just wanted to post a thank you Nev for this feature

[Reino]

Originally Posted by DarkSpace

ConvertToRGB() defaults to always using limited-range Rec.601.

Now, this seems to be the thing what this is all about!
So a standard RGB conversion just assumes(!) TV-Rec.601. That's why...

FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
ConvertToRGB()

...doesn't do anything. The PC-Rec.709 Fraps-file becomes TV-Rec.601 without the stream actually being changed, and that's why you'd have to change it back to PC-Rec.709 to get the right colours. Weird!! That explains FFDShow's "RGB conversion"-settings, because FFDShow automatically converts Fraps to RGB, but what about LAV+madVR? Since it all stays NV12 up untill madVR's input, are the range- and luma conversions ([Ctrl+Alt+Shift+i] and [Ctrl+Alt+Shift+m]) done after the internal RGB conversion?

In this case I used Avisynth in FFDShow yes, where the output will be converted to RGB in the end, but normally that isn't necessary of course. At least I create an Avisynth-script to feed it to x264 ultimately, which only accepts YV12.

So when editing FPS1(yuvj420p) files in Avisynth where the end result has to be YV12 for x264 to swallow, a conversion to TV-Rec.601 is needed, but for playback (RGB) a conversion to PC-Rec.709 is needed.

Originally Posted by DarkSpace

Exactly, decode the FRAPS and send the YUV as-is to the renderer, but send along some upstream flags that specify TV-range BT.601 as the stream's decoding matrix. madVR will recognize these flags and decode the stream to RGB as TV-range BT.601, and maybe LAV could even implement an internal RGB conversion for other Renderers that don't support reading these upstream flags (as it's implemented for YCgCo now, for example).

"TV-range BT.601" now has to be "PC-range BT.709", but furthermore I second that.
--------------------------------------------------------------

Originally Posted by cyberbeing

Are you positive this issue still exists?

FRAPS 3.5.99 + LAV + madVR BT.709 appears to match the RGB values of my source when compared in Photoshop.

Originally Posted by PhrostByte

I've noticed the same, so I sent an email to FRAPS' author about 6 months ago. He just now finally got back to me with this:

Dear Cory,

   Thanks for your message and I apologize for the very long delay in getting back to you.
   In YUV mode Fraps will use 709 coefficients and generate the full range 0-255 (i.e. it's not clamped between 16-235).

Regards,
Rod Maher

It seems one of FRAPS or libav or me is doing something wrong.

[Niyawa]

I tried a search but nothing definitive came up, so I'm posting this question here.

"My friends sometimes come over and we often watch anime when they do, so I have my TV hooked up to my computer via HDMI and I put the anime on that for easier watching. When I put the player on the TV, should I switch LAV RGB output levels to TV (16-235) and then back to PC (0-225) when I'm done? Or will the difference be so minor that I shouldn't go through the trouble?"

I don't have a TV hooked up to a PC with HDMI to see it for myself, so any thoughts?

[Qotscha]

That setting has no effect at all if LAV does not do YUV -> RGB conversion. However, if it does, the correct setting depends on whether levels are changed somewhere else or not and whether TV is set for full or limited range input.

[DarkSpace]

Originally Posted by CoRoNe

Now, this seems to be the thing what this is all about!
So a standard RGB conversion just assumes(!) TV-Rec.601. That's why...

FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
ConvertToRGB()

...doesn't do anything. The PC-Rec.709 Fraps-file becomes TV-Rec.601 without the stream actually being changed, and that's why you'd have to change it back to PC-Rec.709 to get the right colours. Weird!! That explains FFDShow's "RGB conversion"-settings, because FFDShow automatically converts Fraps to RGB, but what about LAV+madVR? Since it all stays NV12 up untill madVR's input, are the range- and luma conversions ([Ctrl+Alt+Shift+i] and [Ctrl+Alt+Shift+m]) done after the internal RGB conversion?

First of all, I'd say that the "standard RGB conversion of AviSynth" is limited to TV-range Rec.601, so you need to either give it an argument to change the matrix used for conversion (I believe that AvsPmod allows you to change the RGB conversion parameters by right-clicking onto the video and defaults to resolution-based matrix selection). Alternatively, you can of course pre-compensate the YUV stream to TV-range Rec.601 instead.
About LAV+madVR, you don't need to worry. Once the matrix and range are passed on from LAV to madVR, it'll automatically work correctly. The range and matrix conversion is not done on the RGB but directly on the YUV (actually, the YUV isn't even modified in this case, it's just converted to RGB using different parameters to begin with).

Originally Posted by CoRoNe

At least I create an Avisynth-script to feed it to x264 ultimately, which only accepts YV12.

So when editing FPS1(yuvj420p) files in Avisynth where the end result has to be YV12 for x264 to swallow, a conversion to TV-Rec.601 is needed, but for playback (RGB) a conversion to PC-Rec.709 is needed.

Wrong: Command-line x264 can swallow YUV 4:2:0, 4:2:2 and also 4:4:4 and you can even send it RGB data directly. Also, there's no need to convert the YUV stream to TV-range Rec.601, as you can just flag the output stream so it tells the decoder that another matrix should be used for conversion from YUV to RGB during playback (the example also shows you how to send 4:4:4 YUV streams).

x264 --range pc --colormatrix bt709 --output "output.264" --output-csp i444 --input-range pc "input.avs"

Also, thanks for clearing up the issue of FRAPS' matrix, this means it uses indeed full range Rec.709 and not some other weird matrix.

[DragonQ]

Originally Posted by Niyawa

I tried a search but nothing definitive came up, so I'm posting this question here.

"My friends sometimes come over and we often watch anime when they do, so I have my TV hooked up to my computer via HDMI and I put the anime on that for easier watching. When I put the player on the TV, should I switch LAV RGB output levels to TV (16-235) and then back to PC (0-225) when I'm done? Or will the difference be so minor that I shouldn't go through the trouble?"

I don't have a TV hooked up to a PC with HDMI to see it for myself, so any thoughts?

Impossible to say without knowing the settings of the latpop's GPU, the media player and the TV. However, it should be really obvious if the levels are wrong if you've seen it before and know what to look for (essentially crushed blacks or grey blacks).