LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

I tried two clips from here:
http://www.ps-auxw.de/ordered/

However, it doesn't seem to be working well.
It seems to detect the ordered chapters and even merges multiple files for playback, but it shows the entire content, even section marked as "you should not see this".

Those files are encoded badly, there are no seek points/key frames on the ordered chapter border, so it can't do its thing properly. Broken files, bad examples.


I also tried the "mkv_ordered_chapters_example" (mkv/xml) sample.
It seems to work better, but selecting an edition doesn't change the media duration...
How is the player supposed to know the media-duration changed?
How about supporting the EC_LENGTH_CHANGED event?

MPC-HC picked up the duration change just fine on its own, so i didn't think there would be anything required to do. I can probably make it fire that event if it helps.


Is there a specific interface for getting ordered chapters vs standard chapters?
Or do they share the same interface?


Technically, there is no such thing as an "ordered chapter", its really a misnomer.
There is a flag in the MKV edition if the chapters are ordered, which means they define a virtual timeline instead of just labels on the plain timeline.

For the player, there is no difference at all. It still gets a normal chapter list on a normal timeline, the difference is only how the timeline is constructed in the splitter.

[nevcairiel]

I would test it using DXVAChecker as player.
Best and unique software of its kind.

No interest testing commercial players/ decoders when we have PotPlayer.

But you can't even test PotPlayer decoders in DXVAChecker, or can you?
AFAIK its limited to its own player, which makes it useless for many people.

[NikosD]

Of course I can't.

How could I test internal decoders that are not exposed as DS/MFT filters ?

I didn't expect you to ask me such questions.

What are you trying to say ?

[sneaker_ger]

Those files are encoded badly, there are no seek points/key frames on the ordered chapter border, so it can't do its thing properly. Broken files, bad examples.

I've always wondered: is this a limitation of DirectShow, i.e. can't it pass frames to down the chain but mark them as "do not display, only for decoding" or something?

[nevcairiel]

What are you trying to say ?

All i want is a decoder which works with VC-1 on the HD3xxx in MPC-HC or DXVAChecker so i can compare what it does and maybe figure out how to fix LAV, but a decoder which is limited to some closed asian player simply doesn't help.
So it would be helpful if anyone could test Cyberlinks decoder and see if it works on that old card.

I've always wondered: is this a limitation of DirectShow, i.e. can't it pass frames to down the chain but mark them as "do not display, only for decoding" or something?

No you can't do that.
I could probably make that happen with LAV Splitter + LAV Video, but it would only work in that combination, and i would rather not enable people to build such broken files.

[sneaker_ger]

Would it be possible to assign all frames that are to be skipped the same timecode?

[Qaq]

Doesn't Pot unpack its decoders somethere?

[Qaq]

All i want is a decoder which works with VC-1 on the HD3xxx in MPC-HC
I know some guy uses Cyberlink with VC-1 and HD3200. Actually I have HD3200 integrated but disabled.

[wanezhiling]

Doesn't Pot unpack its decoders somethere?
No and never will.

The reason why PotPlayer's internal filters(splitters/decoders/pp-filters) are so strong is just simple: its a ds player which merged all good stuffs in the world and did a perfect optimization, you can find *shadow* of mpc-hc/be, lav, and some commercial softwares:p in PotPlayer.

This is a sensitive topic i couldn't comment more.

Well the korean player has a wonderful user experience because of too many wonderful functions/features as its "predecessor" KMPlayer already did, at least for asia people.:)

[nevcairiel]

I know some guy uses Cyberlink with VC-1 and HD3200.

At least something. I'll try to do a comparison of the VC-1 handling and see if any obvious shows up.

[woody777]

Is it possible to "bitstream" multichannel PCM (and by bitstream, I mean bypass the Windows mixer)? I have several blu rays with RAW/PCM tracks instead of the more common DTS-MA or Dolby TrueHD.

The only way I know how to successfully bypass the Windows mixer and send multichannel PCM to my AVR is through Reclock. Otherwise, multichannel PCM is output at stereo/44.1 (Windows control panel is set to stereo/44.1 because, with the exception of a handful of multichannel PCM, everything is either truly bitstreamed or stereo/44.1 music).

Does a solution to this problem exist in LAV independent of Reclock? I know Reclock exists, but it's definitely not an ideal solution to the above problem (mainly because I'm using it in a way it was not necessarily designed for).

[Blight]

nev:
I'm sorry for wasting your time on the encoded files, they were given as a sample and I wasn't aware they were badly authored.

I don't know what MPC-HC does to get the new media duration, perhaps they are querying the graph for duration every second, but I'm not a fan of overhead, so if there can be an event driven system, I'm all for it.
I already have code in place that should hopefully make support of this event add backward compatibility with older versions of Zoom Player (and possibly other directshow players).

[nevcairiel]

Is it possible to "bitstream" multichannel PCM (and by bitstream, I mean bypass the Windows mixer)?

Well it is of course possible, as you already know - but not by anything LAV can do. It outside of its control.

You need an audio renderer which uses exclusive mode, and the only viable option for this right now is ReClock, unless you use a player which has its own renderer which offers the same functionality.

[Weirdo]

I'm getting shaky video at the top of the window on some streams (http://www.mediafire.com/?c6pqdcebp8wfox8) with Yadif enabled. More noticeable with EVR, madVR a bit less but still there.

[Reino]

I might be missing something but why does FPS1(yuvj420p) need to be TV-range Rec.601, wouldn't TV-range Rec.709 be good?Screenshot (Fraps)______AVISource (LAGS(rgb24))___AVISource (FPS1(yuvj420p))___FFVideoSource+ColorMatrix(dest0,clamp0,inputFR) (FPS1(yuvj420p))
____________________(recorded with MSI Afterburner*)___(a.k.a. Fraps' own decoder)_______(a.k.a. TV range Rec.709, for comparison)
http://www.ld-host.de/uploads/thumbnails/ce40618b49dfc38494f8f552aef59b48.png (http://www.ld-host.de/uploads/images/ce40618b49dfc38494f8f552aef59b48.png)___http://www.ld-host.de/uploads/thumbnails/0da3f2df2496f170c81bcd6e56350b1e.png (http://www.ld-host.de/uploads/images/0da3f2df2496f170c81bcd6e56350b1e.png)_____http://www.ld-host.de/uploads/thumbnails/3512069e890c80d157d6f173b92265b5.png (http://www.ld-host.de/uploads/images/3512069e890c80d157d6f173b92265b5.png)________http://www.ld-host.de/uploads/thumbnails/ebb9d8346baa93c420cdfa80efca261d.png (http://www.ld-host.de/uploads/images/ebb9d8346baa93c420cdfa80efca261d.png)

*because my old pc has problems with FPS1(bgra)

Rather self-explanatory I'd say.
Fraps in YUV mode encodes to Full range Rec.709. Fraps' own decoder does a YV12(PC.709)-->RGB(Rec601) conversion by default, unlike ffmpeg.

[DarkSpace]

Fraps in YUV mode encodes to Full range Rec.709. Fraps' own decoder does a YV12(PC.709)-->RGB(Rec601) conversion by default, unlike ffmpeg.
Aside from the fact that this sounds just weird (RGB -> YUV with PC.709 and afterwards YUV -> RGB with TV.601 will distort colors, and also range), shouldn't it be okay for the decoder to output YUV and just flag it as TV.601 instead of TV.709 (or PC.709), then? I fail to see the problem, aside from a very weird way of handling YUV.

Edit: I just realized that this may not seem as clear to someone else as it seems to me, but as I understand it, you're saying that FRAPS simply converts the YUV stream that uses PC.709 matrix coefficients back to RGB using another set of of coefficients, namely TV.601, without modifying the YUV stream at any time.

[Reino]

Flag it? As in metadata? And then what?

"without modifying the YUV stream at any time." ? A Conversion is something different than a modification in this case in your opinion?

[woody777]

Well it is of course possible, as you already know - but not by anything LAV can do. It outside of its control.

You need an audio renderer which uses exclusive mode, and the only viable option for this right now is ReClock, unless you use a player which has its own renderer which offers the same functionality.

Thank you, Nev. I was pretty sure I already knew the answer. I may need to look into a script to toggle between 2ch/44.1Hz/16bit and 6ch/48Hz/24bit for the movie in question.

[DarkSpace]

Flag it? As in metadata? And then what?
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).

"without modifying the YUV stream at any time." ? A Conversion is something different than a modification in this case in your opinion?
For me, a conversion from YUV to RGB doesn't modify the YUV stream in this context, it rather destroys the YUV and replaces it by RGB. If there's something else you mean by modifying, could you please elaborate further?
I only meant to say that there's nothing strange going on between converting from RGB to YUV (A) and converting from YUV to RGB (B). That means that the YUV stream in (A) is the same as the YUV stream in (B), and in AviSynth notation, the process would look something like this:
Input(RGB24)
ConvertToYV12(matrix="PC.709") #PC-range 709
ConvertToRGB24(matrix="Rec.601") #TV-range 601
Output()

[Reino]

Just like EVR, I noticed madVR converts a FPS1(yuvj420p) file to TV-range. But are you sure madVR is capable of doing a BT.709 --> BT.601 conversion, because I haven't found any related settings, and the funny thing is, although it's still BT.709, madVR's OSD reports "matrix BT.601 (best guess)".

In that case, I don't think the YUV stream is modified any other way, but to be absolutely sure we'd have to ask the Fraps developer.

[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 :confused:.

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]

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 :confused:.
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]

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?
http://forum.videohelp.com/attachment.php?attachmentid=8335&d=1314187885

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]

@ 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]

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]

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]

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]

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 :cool:

[Reino]

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.

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

FRAPS seems to use its own custom color matrix for converting RGB to YV12 and back again. ConvertToRGB32(matrix="PC.709") does, AFAIK, not match the original colors exactly.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]

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

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]

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

[Niyawa]

I see. Thanks guys.

[mindbomb]

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?


there are test videos out there for black level and white level. when you switch between 16-236 to 0-255, one will be very wrong. I think that is the best way to tell.

[wanezhiling]

http://www.sendspace.com/file/rdiz1f

cuvid issue (http://i.minus.com/i3GJ76NiXetTy.png), other decoding modes are fine.

[nevcairiel]

Can't do much about CUVID issues, the decoder is a completely black box, i give it a packet, it gives me an image.
Most of the time such issues are a problem in their parser, so i suggest different drivers, or complaining to nvidia. :)

[wanezhiling]

o.O

ok, blame nvidia...

[aufkrawall]

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.
I've tested this now and it still doesn't use compliant 601/709 matrix (then it would be lossless).
But however, it seems either because of new Avisynth or Fraps versions, situation has improved a lot.

How Fraps YV12 looks like with Fraps' VFW decoder (how it should be, the "original"):
http://www.abload.de/thumb/origfrapsg2arm.png (http://www.abload.de/image.php?img=origfrapsg2arm.png)

ConvertToRGB(matrix="PC.601") (the same like adding no conversion to the script) + x264 lossless:
http://www.abload.de/thumb/rgbpc601c9lvm.png (http://www.abload.de/image.php?img=rgbpc601c9lvm.png)
Ferns look more blurry and image is slightly darker (please don't judge this with a crappy display :p ).

ConvertToRGB(matrix="PC.709") or ConvertToRGB(matrix="rec709") have totally wrong brightness (I've flagged the vids correctly with x264)

ConvertToYV12(matrix="rec709") + x264 lossless:
http://www.abload.de/thumb/yv12rec709hnb9s.png (http://www.abload.de/image.php?img=yv12rec709hnb9s.png)
Looks well. Ferns aren't always as sharp as the original but it's hardly noticible, the same goes for some color shift with flowers. This was worse with older Fraps/Avisynth versions, whole image became more blurry etc.
That's what everyone wants, since apart from LAV/madVR, stupid other players always expect rec709, at least with video resolutions.

Original Fraps YV12 video decoded with LAV (image saved with madVR):
http://www.abload.de/thumb/lavv4yyn.png (http://www.abload.de/image.php?img=lavv4yyn.png)
Colors are wrong and also slightly wrong brightness.

That way imho it shouldn't be recommended to watch Fraps YV12 video with LAV. Stupid thing is just that madVR isn't compatible to VFW decoders, so then one has to stick to LAV though.
The last time Nev said he doesn't want to fix it since it's rather "dirty". Is there a chance that you've changed your mind?
I'm afraid otherwise there will never be any solution.
There's a "real" need for it, btw (e.g. texture filtering comparison vids):
http://www.computerbase.de/artikel/grafikkarten/2012/test-intel-graphics-hd-4000-und-2500/4/

Sample Fraps vid:
http://www.mediafire.com/?9kto2socl294ymb

[wanezhiling]

http://www.sendspace.com/file/ow06qp
lav s + lav v, stutter

[nevcairiel]

http://www.sendspace.com/file/ow06qp
lav s + lav v, stutter

The file has broken timestamps, nothing that can be done.

[aufkrawall]

Handbrake's conversion isn't lossless either. :sly:

[cyberbeing]

I'm not seeing any matrix issue in your FRAPS avi sample aufkarwall, after testing this myself. Your Avisynth ConverttoRGB(matrix="PC.601") image is also not PC.601 either, so it makes me wonder how you are feeding x264 your decoded FRAPS footage.

LAV Video YV12 + Avisynth ConverttoRGB(matrix="PC.601")
http://img21.imageshack.us/img21/4421/lavconverttorgbpc601avs.th.png (http://imageshack.us/a/img21/4421/lavconverttorgbpc601avs.png)

FRAPS Decoder RGB32 + madVR
http://img824.imageshack.us/img824/2982/frapsmadvr.th.png (http://imageshack.us/a/img824/2982/frapsmadvr.png)

LAV Video YV12 + Avisynth ConverttoRGB(matrix="PC.709")
http://img822.imageshack.us/img822/8581/lavconverttorgbpc709avs.th.png (http://imageshack.us/a/img822/8581/lavconverttorgbpc709avs.png)

LAV Video NV12 + madVR Fullrange BT.709
http://img9.imageshack.us/img9/1795/lavbt709madvr.th.png (http://imageshack.us/a/img9/1795/lavbt709madvr.png)


The only anomaly I do see is that the FRAPS official decoder appears to use incorrect chroma positioning when upsampling from YV12 to RGB, resulting in chroma bleeding and a shifted image.

http://screenshotcomparison.com/comparison/19224