LAV Filters - DirectShow Media Splitter and Decoders

[madshi]

As for color reproduction and resize quality - maybe I just can't setup it correctly, but as I said it looks in madVR as bad as in other renderers
Color reproduction: Most SD content is encoded in BT.601, while most of today's displays are calibrated nearer to BT.709. I can't speak for other renderers, but madVR converts the source gamut to the display gamut (if they differ). If your renderer doesn't do that, the colors will be incorrect, when displaying BT.601 content on a BT.709 display. Of course all color processing in madVR can be configured or alternatively turned off. Also you can check (and change) via shortcuts at runtime what madVR is doing color-wise. If your renderer shows different colors than madVR, then either madVR is setup incorrectly, or your renderer is lacking necessary processing, or there's a bug in madVR. I'd like to encourage you to check the primaries and decoding matrix your test video needs and whether both madVR and your own renderer handle that correctly. Your screenshots don't really proof much in terms of color reproduction because the big question is which display (BT.601, BT.709, or something completely different) the screenshots were made for. Making a screenshot of the original source without any color processing makes sense only if you watch the screenshot on a display which matches the color spec the source was encoded for. I'm thinking once madVR gets screenshot functionality, I'll probably add a little "BT.601" or "BT.709" or "PAL" logo in the corner of each screenshot to clarify which display the screenshot needs to be shown on, in order to get correct colors.

Resizing: Currently madVR supports the usual linear resampling filters like e.g. Lanczos. Quality should be slightly better than AviSynth"s implementation of the same algorithms because madVR does all its calculations in 32bit+ floating point bitdepth, while AviSynth (AFAIK) works in 8bit integer. Of course AviSynth has some non-linear scaling algorithms. E.g. NNEDI3 is much better quality than anything madVR currently does. But that's just the way it currently is. Non/linear scaling algorithms are planned for a future madVR version.

[Mercury_22]

Since you plan to add a mixer will it be to much to add individual volume controls for each channel like in FFD ?

It seems I'm not the only one needing those :p
...
- ability to boost volume of center channel when downmixing to stereo, as many people don't like the large volume difference between voices and sound effects

[LordMerlin]

Hello
Can I add a video decoder or processor function to increase the number of frames, or as a POT player simply showing them a few times, or the calculation of intermediate frames.
There is a DS-filter, which makes saschet intermediate frames on the video card. Uses CUDA.
website http://dmitrirender.narod.ru/

[Triplefun]

copied frpom the LAV CUVID thread ...

---------------------

Thanks for building a great codec

I run LAV on my W7/HTPC and get spectacular results

However, I would also like to use it on my WHS/PS3Mediaserver/PS3/1080p TV. I have added a GTS450 video card to the WHS although 98% of the time it runs headless. The PS3 is connected to the WHS server over a gigabit network.

I initially tried loading the LAV codec using the Shark007 codec pack (and K-Lite) but could not get it to recognise cuda.

I then loaded LAV 0.37 and found PS3Mediaserver (SB50) recognises it as an FFmpeg codec accessed via AviSynth 2.5.

When playing HD content (VC-1 and H264) using PS3 Mediaserver and a terminal connected to the server to enable CUDA processing I get:

1. lots of video stuttering (Q8400 CPU is running 20% on all 4 threads)
2. sound running 3x the video speed

I have tried adding the TMT5 audio codec with no change - can I use the dll that comes loaded with Windows7 and do I need to rename it when I add it to the LAV directory?

I have tried changing the LAV and PS3Mediaserver settings without much success. PS3Mediasever seems to run best (least stuttering) when I set:

1. the LAV video output format settings to 16 bit only
2. the LAV video display mode 25p/30p
3. the LAV deinterlacing algorithm 'none'
4. PS3Mediaserver 'lossless quality'

What more can I do to get the video and audio playing properly please?

Also when I go 'headless' GPU-Z shows the CUDA processing is not available - I have since been informed that a DVI-VGA dongle configured with three 68 Ohm resistors will simulate a monitor and trigger CUDA - many thanks.

[nevcairiel]

Since you plan to add a mixer will it be to much to add individual volume controls for each channel like in FFD ?

If i give you a full mixer matrix, you can just control volume with that, if you wish. I won't create a separate "volume control" thing.

[roytam1]

New nightly:
http://roy.orz.hm/lavf-w32-nightlies/lavf-my111013-rv34seekkeyframe-bb66f4f.7z

diff:
http://roy.orz.hm/lavf-w32-nightlies/lavf-my111013-rv34seekkeyframe-bb66f4f.diff

A test build for forcing the seeking of RV30/RV40 video to key frames only which preventing corrupted image after seeking of RV30/RV40 video.

[Mercury_22]

If i give you a full mixer matrix, you can just control volume with that, if you wish. I won't create a separate "volume control" thing.
As long as I can control the volume on each channel I don't care how it's done :D so :thanks:

One thing to consider the option to enable/disable matrix & control volume by remote control = keyboard shortcut

[SEt]

nevcairiel, the problem with "basic filtering" is there is no line what is still "basic" and what is not. I'm not really against implementing libavfilter - it's just useless with access to Avisynth. After using things like MDegrain in no way you are going to be satisfied with primitive denoisers. Why integrate Avisynth and not put it in separate filter? Because you can export some interesting information directly to it (like, frame type, motion vectors if decoder provides them).

I don't remember being against downmuxing (only strongly against yadif ^_^). Downmuxing is something like P016->YV12 conversion and as well belongs to decoder.

madshi, first example has nothing to do with BT.601/BT.709 gamut etc. Without metainformation (like in this case) you can only assume everything is in sRGB (image and device) and no correction is needed. And madVR does it correctly when displaying 1:1 with no scaling involved. But with any scaling it fails horribly as demonstrated.

[e-t172]

Keep in mind that Avisynth cannot handle everything. Most notably it has no concept of frame duration (i.e. VFR content). This makes it impossible to implement e.g. a reliable IVTC filter in Avisynth because some HDTV broadcasts (like CBS) like to mix soft telecine and hard telecine and switch between the two all the time, which is impossible to handle in Avisynth. That's the primary reason why my experimental IVTC filter was done as part of ffdshow and not as an Avisynth filter (I tried Avisynth, and failed).

[nand chan]

Keep in mind that Avisynth cannot handle everything. Most notably it has no concept of frame duration (i.e. VFR content). This makes it impossible to implement e.g. a reliable IVTC filter in Avisynth because some HDTV broadcasts (like CBS) like to mix soft telecine and hard telecine and switch between the two all the time, which is impossible to handle in Avisynth. That's the primary reason why my experimental IVTC filter was done as part of ffdshow and not as an Avisynth filter (I tried Avisynth, and failed).

Avisynth also has very poor support for greater than 8 bit precision (then again, so does ffdshow). I cannot use a full 10 bit pipeline without dithering anywhere.

Color reproduction: Most SD content is encoded in BT.601, while most of today's displays are calibrated nearer to BT.709. I can't speak for other renderers, but madVR converts the source gamut to the display gamut (if they differ). If your renderer doesn't do that, the colors will be incorrect, when displaying BT.601 content on a BT.709 display. Of course all color processing in madVR can be configured or alternatively turned off. Also you can check (and change) via shortcuts at runtime what madVR is doing color-wise. If your renderer shows different colors than madVR, then either madVR is setup incorrectly, or your renderer is lacking necessary processing, or there's a bug in madVR. I'd like to encourage you to check the primaries and decoding matrix your test video needs and whether both madVR and your own renderer handle that correctly. Your screenshots don't really proof much in terms of color reproduction because the big question is which display (BT.601, BT.709, or something completely different) the screenshots were made for. Making a screenshot of the original source without any color processing makes sense only if you watch the screenshot on a display which matches the color spec the source was encoded for. I'm thinking once madVR gets screenshot functionality, I'll probably add a little "BT.601" or "BT.709" or "PAL" logo in the corner of each screenshot to clarify which display the screenshot needs to be shown on, in order to get correct colors.

Resizing: Currently madVR supports the usual linear resampling filters like e.g. Lanczos. Quality should be slightly better than AviSynth"s implementation of the same algorithms because madVR does all its calculations in 32bit+ floating point bitdepth, while AviSynth (AFAIK) works in 8bit integer. Of course AviSynth has some non-linear scaling algorithms. E.g. NNEDI3 is much better quality than anything madVR currently does. But that's just the way it currently is. Non/linear scaling algorithms are planned for a future madVR version.

This is probably off-topic, but I don't know how fast you are going to read my reply in the madVR thread - why does changing the decoding primaries in madVR (with Ctrl + Alt + Shift + P) not affect anything?

I have here a 1920x1080 video file that was encoded using BT.601 primaries (erroneously), but I want to play it back as such. No matter which setting I have the “decoding primaries” set to in the OSD, madVR always decodes using BT.709.

In mplayer I can use -vo gl:colorspace=1 and it will use BT.601 to decode instead of the default, which results in the correct image.

[SEt]

Keep in mind that Avisynth is open source and you can extend it any way you want. Want frame duration - just write support for it. That's how open software works in general - everyone just writes what he needs.

[e-t172]

That's not that simple. If someone writes VFR support for Avisynth, third-party filters will probably need to be modified so that frame duration information isn't lost when traversing the filter. This can get quite complicated.

[nevcairiel]

While DirectShow has a concept of durations, its typically just wrong. If you need the duration, wait for the next frame, and compute the difference. ;)

[e-t172]

I didn't encounter such issues when developing my IVTC filter (maybe ffdshow is smart enough to fix the timestamps). But even if this were true, Avisynth has no concept of timestamps at all, so you can't "compute the difference" in Avisynth anyway.

[nevcairiel]

How the hell do some of those filters that modify the fps work at all if it doesnt have timestamps? o.O

[e-t172]

It's just a FPS value associated with the stream, as opposed to specific frames.

[madshi]

madshi, first example has nothing to do with BT.601/BT.709 gamut etc. Without metainformation (like in this case) you can only assume everything is in sRGB (image and device) and no correction is needed. And madVR does it correctly when displaying 1:1 with no scaling involved. But with any scaling it fails horribly as demonstrated.
I don't think assuming that content and display have identical gamut is a good idea, when talking about SD content, since (as mentioned before) most SD content is BT.601 and most modern displays are not. Of course if the source doesn't say how it was encoded you can only guess. But it makes sense to use the most probable value as a best guess.

Anyway, if colors change in madVR when turning scaling on/off (in madVR) that sounds like a bug to me, but it sounds quite weird, too, cause I've never seen a bug report like that yet. Could you please check which decoding matrix (Ctrl+Alt+Shift+M) and primaries (Ctrl+Alt+Shift+P) madVR is using with your sample, if you turn scaling on/off?

Is it possible that you're talking about scaling *externally* (e.g. with AviSynth)? In that case, if the source doesn't contain bitstream color information, most renderers (including madVR) will assume a BT.601 decoding matrix for SD content and a BT.709 decoding matrix for HD content. So if you send your test video to madVR without scaling, madVR will use the BT.601 decoding matrix. But if you scale in AviSynth madVR may eventually think you're sending native HD content and thus use the BT.709 decoding matrix. You can check that by pressing Ctrl+Alt+Shift+M in either case. I guess you're not changing the decoding matrix in AviSynth when scaling with AviSynth, are you? That would explain why you're getting incorrect colors with all renderers except your own. That would not be a bug in the other renderers, though.

This is probably off-topic, but I don't know how fast you are going to read my reply in the madVR thread - why does changing the decoding primaries in madVR (with Ctrl + Alt + Shift + P) not affect anything?

I have here a 1920x1080 video file that was encoded using BT.601 primaries (erroneously), but I want to play it back as such. No matter which setting I have the “decoding primaries” set to in the OSD, madVR always decodes using BT.709.
I don't have time to look into this atm, could be a bug in madVR.

[Pat357]

why with a divx and avisource on avisynth it still pupop-me "Couldn't locate a decompressor for fourcc dx50"?
(I think it doesn't work even changing fourcc to xvid, or divx...)
ps ffvh instead doesn't work at all...
Try with "DirectShowSource" instead.

[nand chan]

I don't have time to look into this atm, could be a bug in madVR.

Did some further testing, it only happens if you have “disable calibration controls for this display” enabled. So never mind, I just had to set my display to use BT.709 and the change works fine.

[nand chan]

@nevcairiel:

If I only enable RGB32 output in LAV Video, which algorithm does it use to upscale chroma? Is it possible to implement Mitchell-Netravali upscaling for this task? Also, does it still dither properly and use the correct levels (eg. when outputting YV12), even if you output RGB32? Does it use swscale for this?

Basically, I want to use LAV Video to convert to RGB32 with the best possible quality.

[nevcairiel]

@nevcairiel:

If I only enable RGB32 output in LAV Video, which algorithm does it use to upscale chroma? Is it possible to implement Mitchell-Netravali upscaling for this task? Also, does it still dither properly and use the correct levels (eg. when outputting YV12), even if you output RGB32? Does it use swscale for this?

Basically, I want to use LAV Video to convert to RGB32 with the best possible quality.

The chroma upscaling uses Bilinear Interpolation. The whole algorithm is written with custom SSE2 intrinsics.
Another algorithm is not possible without rewriting the whole thing (and anything beyond bilinear really pushes the complexity of the assembler code). The only option would be to convert it to YUV444 with swscale before and convert that to RGB then, but that means there is some loss (after the YUV444 conversion, swscale will round/dither it back to 8-bit, it isn't any smarter)

My RGB converter supports native 9 and 10-bit input, and everything is dithered to 8-bit RGB after the conversion (from about 15-bit internal precision, iirc).
The input levels are of course probed from the stream, the RGB output levels are configurable. It supports the BT.709/601 and SMPTE240M matrices. If the stream does not flag any, the usual decision based on video size is done (SD = 601, HD = 709).

It does not use swscale, because swscale is either way too slow, or very low-quality (whatever mode you prefer).

In short: Its already the best quality i'm willing to offer. Possibly inferior to madVR, but definitely superior to EVR.

[nand chan]

The chroma upscaling uses Bilinear Interpolation.
Another algorithm is not possible without rewriting the whole thing. The only option would be to convert it to YUV444 with swscale before and convert that to RGB then, but that means there is some loss (after the YUV444 conversion, you would have to round/dither it back to 8-bit, swscale isn't any smarter)

Well that's just unacceptable, I don't like bilinear for chroma. Oh well.

My RGB converter supports native 9 and 10-bit input, and everything is dithered to 8-bit RGB after the conversion (from about 15-bit internal precision, iirc).
The input levels are of course probed from the stream, the RGB output levels are configurable. It supports the BT.709/601 and SMPTE240M matrices. If the stream does not flag any, the usual decision based on video size is done (SD = 601, HD = 709).

It does not use swscale, because swscale is either way too slow, or very low-quality (whatever mode you prefer).

By input level I didn't mean full range or limited range, I meant does the bit depth get converted correctly? Since your 10 bit -> 8 bit YV12 dithering does it correctly I'm going to assume yes, but I wasn't sure whether the same is true for 10 bit -> 8-bit RGB32.

But regardless, it doesn't matter if I can't use Mitchell-Netravali for upsampling chroma. It seems I'll have to stick with the horribly broken ISR for now then. :(

[nevcairiel]

You're welcome to write a new upscaler in SSE2. :)
The Bilinear scaler was straight-foward, so i took the time to write it. But i'm using madVR, so i would never require anything more advanced myself.

[nand chan]

You're welcome to write a new upscaler in SSE2. :)
The Bilinear scaler was straight-foward, so i took the time to write it. But i'm using madVR, so i would never require anything more advanced myself.

I'd use madVR to upscale/convert as well, but then I can't get decent subtitles. The only viable option is to use VSFilter in RGB32 mode (its YUV mode is shit, and the ISR is shit as well because it doesn't work for anamorphic releases / messes up font sizes and 3d transforms).

So that means I have to input RGB32 to VSFilter, which means I have to convert from P010 to it somewhere along the line. I'd use avisynth but avisynth only supports YV12 input.

[SEt]

madshi, again, the problem is not decoding matrix / primaries. I've posted the sample. You write trivial avisynth script
ImageSource("colorsrc.png")
ConvertToRGB32()

ConvertToRGB32() is not needed but madVR crashes on RGB24. Next, you open the script in MPC-HC (I assume that's the intended use of madVR). Set size to 100% - image displays correctly. Now, resize the player window and see horrible color artifacts yourself.

It's not a "bug" it just looks like madVR doesn't do true scaling but takes the same shortcut as almost everyone else (ironically, it claims to take "no shortcuts").

[nevcairiel]

I guess not liking Anime makes ones life much easier. The occasional PGS subtitles for a alien language on Blu-rays is ok with the ISR as well. :)

@SEt:
madVR does not support RGB24 - which i can understand, the 3 byte pixels are horrible for alignment. :D

But please take all unrelated topics in their own threads.

[SEt]

nevcairiel, no, liking Anime is what drives like half the devs here to write programs/plugins. ^_^
madVR kind of support it (as it connects with RGB24), but unable to handle it correctly.

As for chroma scaling - I don't think really high quality colorspace conversions are required. They are just a fallback in case next filter is unable to understand for example P010.

[STaRGaZeR]

nevcairiel, no, liking Anime is what drives like half the devs here to write programs/plugins.

While true, in this very forum you can see people that take it way too far, to the point it's just retarded ;)

[mkanet]

Oh I didnt think about turning "ON" UAC Default. Usually, having it enabled is what introduces problems with some apps. The first thing I do after installing Win7 is put it to the lowest setting possible. Does LAV filters need for UAC to be at the default level?

PS: I've only installed LAV filters once; and, it was the latest version 37 on a completely brand new installation of Win7 with SP1 64bit.

@mkanet,

How about turn on UAC (default) in Win7 and clean install of latest LAV Filters to see if it works. Thanks.

[mark0077]

LAV Video
Has anyone tested the de-interlacing quality output from LAV Video. I am using LAV Splitter, Audio and Video with my GTX 295. I'm using CUVID hardware decoder, Deinterlacing set to Adaptive, Mode 50p/60p, and "High-Quality Processing" enabled.

Unfortunately I'm getting very bad deinterlacing quality. I'm using de-interlacing tests of many different input formats and its common to them all unfortunately. When not using LAV Video de-interlacing, and using software yadif, or output directly nv12 from ffdshow for example, de-interlacing quality is back to perfect.

I'm willing to perform any tests / experiments necessary, I'd love to see this working correctly.

LAV Audio
One other slight issue I have is when playing back some music videos today which have AAC tracks, LAV Audio doesn't kick in, instead the internal mpc-hc AAC decoder, even though Lav Audio is set to prefer. Is this an mpc-hc issue or LAV?

[mindbomb]

quick questions:

vp8 decoding is multithreaded in lav video?

and in a related note, 1080p vp8, is it similiar to 1080p mpeg 2 in terms of decoding performance?

[nevcairiel]

I'm willing to perform any tests / experiments necessary, I'd love to see this working correctly.


Try the stand-alone LAV CUVID if its working better there?
Just to rule out nothing broke when integrating it (or optimizing it recently)

I'm getting the same quality from the CUVID deinterlacer and using EVR.
If you're on Windows XP, turn off "High-Quality Processing".

Also, 0.37 has a bug which causes EVR to display funny things if you have EVR-CPs Color Management active, its already fixed for a next version (look on the last page for a nightly build from roytam)



vp8 decoding is multithreaded in lav video?
Yes.

1080p vp8, is it similiar to 1080p mpeg 2 in terms of decoding performance?
No idea, benchmark it. :p VP8 is certainly faster then H264, but it may be slower then MPEG2

[LordMerlin]

Ok. Quest again. What about smoothing playbak by double frame rating or frame interpolation?

[pirlouy]

The thing with post-processing is that it needs profiles management. Indeed, it often depends on conditions. So I thing it should be a separate filter.
For me the best thing would be if nevcairiel could write something to allow plugins (or extensions or addons, etc.) but I guess it would be a pain to find the good way to develop this...

[nand chan]

The thing with post-processing is that it needs profiles management. Indeed, it often depends on conditions. So I thing it should be a separate filter.
For me the best thing would be if nevcairiel could write something to allow plugins (or extensions or addons, etc.) but I guess it would be a pain to find the good way to develop this...

That's why you should just use ffdshow for post processing, it has filters and all of this stuff already built in. Even if you have to dither P010 -> YV12 in LAV Video, I've found it to be basically nearly bit perfect in my results (no tangible difference in pixel values). It should not be an issue.

[mark0077]

Try the stand-alone LAV CUVID if its working better there?
Just to rule out nothing broke when integrating it (or optimizing it recently)


Hi, I'm actually finding it most prominent with mpeg2 content. The same issue arises with mpeg2 content using lav cuvid, with high quality procssing on or off, aswell as the field order being forced from auto to either top or bottom. Could it be specific to my gtx 295 perhaps, that it doesn't support hardware de-interlacing of mpeg2 through the methods used by lav video / lav cuvid?

I'm in Win 7 64bit with madVR as the video renderer although evr doesn't make a difference of course.

[nevcairiel]

Hi, I'm actually finding it most prominent with mpeg2 content. The same issue arises with mpeg2 content using lav cuvid, with high quality procssing on or off, aswell as the field order being forced from auto to either top or bottom. Could it be specific to my gtx 295 perhaps, that it doesn't support hardware de-interlacing of mpeg2 through the methods used by lav video / lav cuvid?

I'm in Win 7 64bit with madVR as the video renderer although evr doesn't make a difference of course.

You said direct output of nv12 from ffdshow without prior deinterlacing is perfect, but you also say you use madVR. madVR does not perform any deinterlacing, so that would mean your video either isnt interlaced to begin with, or i'm confused here? :d

[mark0077]

Oh yeah when going from ffdshow nv12 -> hardware deinterlacer I'm using evr-cp. When using software de-interlacer yadif, I'm using madVR. :) Sorry for confusing. ATM I'm trying to use LAV Video de-interlacing -> madVR which is of course where I'm running into quality issues.

This is one sample I'm finding useful to differentiate vertrezmotion.ts . I'm not sure if you have that particular sample, if not I'll track it down.

[mzso]

And the best part is the whole new product will be delivered by leprechauns and fairies, carried on carts pulled by unicorns...



Most legacy rates... Apart from 25/50, you know the ones that a very large part of the world that is NotAmerica uses?
I'm pretty sure a 120 Hz display can handle 100 Hz.

[nevcairiel]

Oh yeah when going from ffdshow nv12 -> hardware deinterlacer I'm using evr-cp. When using software de-interlacer yadif, I'm using madVR. :) Sorry for confusing. ATM I'm trying to use LAV Video de-interlacing -> madVR which is of course where I'm running into quality issues.

This is one sample I'm finding useful to differentiate vertrezmotion.ts . I'm not sure if you have that particular sample, if not I'll track it down.

I don't know if you tested that yet, but how does it look if you set the hardware deinterlacing to "Weave" ?
Maybe its a decoder problem...

Does it happen on all MPEG-2 files?

[mark0077]

Thanks nev, yeah with Weave, the image looks simply interlaced. With adaptive parts of the image look like they are gone crazy jumping and flickering. Its happening on all mpeg2 content I have tried.

On things like dvd's (played by opening the vobs themselves), its noticible to my eye that the quality isn't great, but all of these test files show up the problem in a more exxagerated fashion. Can I give any more info / screenshots etc to help? Thanks again

[THX-UltraII]

I want to use SVP (http://www.avsforum.com/avs-vb/showthread.php?t=1326189) in combination with LAV video decoder but it seems that in order to run SVP I need to run FFdshow. So I installed FFdshow and UNchecked all codecs at the input section except RAW video where I choose ALL. I thought this was supposed to be the way to make ffdshow work? Am I doing something wrong here?

[CruNcher]

I want to use SVP (http://www.avsforum.com/avs-vb/showthread.php?t=1326189) in combination with LAV video decoder but it seems that in order to run SVP I need to run FFdshow. So I installed FFdshow and UNchecked all codecs at the input section except RAW video where I choose ALL. I thought this was supposed to be the way to make ffdshow work? Am I doing something wrong here?

Thats correct you also need to load the script that initializes it in the Avisynth part of ffdshow and that is something missing in Lav Video (Avisynth Script load support). Though the problem is that ffdshow now becomes part of every dshow chain that's loaded with all it's consequences like killing DXVA or crashing Lav Video when using the Lav Cuvid part and i guess it would also influence 10 bit output from Lav Video ? ;)

[mark0077]

CruNcher, THX-UltraII, actually I am able to use LAV Video / LAV Cuvid perfectly do hardware decoding, and then run my svp avisynthscripts afterwards so ffdshow doesn't stop lav video doing hardware decoding as far as I can see.

Actually I can set my svp scripts to higher quality when I enable lav video / cuvid hardware decoding because of the amount of work it takes away from my cpu, its a great combination.

[CruNcher]

That's the goal of it reducing CPU by using the DSP (input) mixing this flexible with the realtime manipulation capabilities of ffdshow (CPU) is indeed a powerful combination if both input/output working flawless together and mixing this with SVP (CPU/GPU) additionally enhances this with a very powerful tool that makes some ISV solutions look pretty odd in comparison and mixing this then on top of the icecream additionally with PS (GPU) you have the most powerful combination and flexibility you can think off Playback wise ;)

[THX-UltraII]

CruNcher, THX-UltraII, actually I am able to use LAV Video / LAV Cuvid perfectly do hardware decoding, and then run my svp avisynthscripts afterwards so ffdshow doesn't stop lav video doing hardware decoding as far as I can see.

Actually I can set my svp scripts to higher quality when I enable lav video / cuvid hardware decoding because of the amount of work it takes away from my cpu, its a great combination.

How do I make it work that I can use LAV video decoder AND SVP together? Like I said, I already installed ffdhow and ONLY checked RAW all supported in the input section but ffdshow simply does not load when I run MPC-HC and SVP of course then says that it is waiting for ffdshow.

[mark0077]

In my external filter window in mpc-hc I simply have my LAV splitter, lav video, lav audio, and ffdshow Video decoder, all set to prefer. In the AviSynth tab, (when I choose to use it, not at the moment as I'm trying to figure out some de-interlacing issues), I just have it import a custom script I choose to use using the following (rather than using svp itself as it doesn't allow control of many important things I like to use, like the use of the high quality dct=true options)

import("G:\avisynth_scripts\InterFrame.avsi")

I use svp / avisynth dlls as packaged in the interframe package here http://forum.doom9.org/showthread.php?t=160226 , and use a custom version of the InterFrame avisynth script attached. So I'm still using svp dlls, just not the svp software in the tray which forces ffdshow to point to its own avisynth script.

[pirlouy]

That's why you should just use ffdshow for post processing, it has filters and all of this stuff already built in. Even if you have to dither P010 -> YV12 in LAV Video, I've found it to be basically nearly bit perfect in my results (no tangible difference in pixel values). It should not be an issue.
Yes, but FFDShow is not really popular in these time...
Nobody wants to really work on it; if it was modular, maybe some developers would be interested...

[ryrynz]

Though the problem is that ffdshow now becomes part of every dshow chain that's loaded with all it's consequences like killing DXVA or crashing Lav Video when using the Lav Cuvid part

Is it consistent crashing? I just went out and got a 550 Ti so I could use ffdshow raw with Lav Cuvid so I could have more CPU power available for Avisynth.

[fastplayer]

Hi nev!
Seeking this WebM file (video-only) with LAV 0.37 causes MPC-HC rev3758 to freeze (not responding):
http://people.gnome.org/~michael/data/2011-10-10-lool-demo.webm
Using MPC's internal filters works just fine.