LAV Filters - DirectShow Media Splitter and Decoders

[QBhd]

When you turn the AVR off it turns off your desktop, correct? If you have it setup as an extended desktop, then your "normal" primary desktop should not go blank when this happens. If you just have the one desktop that is cloned, then yes you will have a blank desktop on you monitor as well when the AVR is turned off... maybe this should be taken to another thread since this is hi-jacking nev's LAV thread.

QB

[Xaurus]

When you turn the AVR off it turns off your desktop, correct? If you have it setup as an extended desktop, then your "normal" primary desktop should not go blank when this happens. If you just have the one desktop that is cloned, then yes you will have a blank desktop on you monitor as well when the AVR is turned off... maybe this should be taken to another thread since this is hi-jacking nev's LAV thread.

QB
Yes you're right, it's off topic. I'll try your advice and use extended desktops with the computer monitor as primary. Thanks!

[mkanet]

I have no problems using any decoders on either PC (including CoreAVC(cuda) and MPC-HT (dxva) and Arcsoft.

LAVCUVID doesnt work on my Vista32 OS with Nvidia GT8500. It also doesnt work on my Windows 7 64bit PC with Nvidia GT545. I have no problems using Cuda on either PC when using all recent versions of CoreAVC 2.5.x- 3.x.

I dont have any problems using LAV Video filter with LAVCUVID integrated into it (all settings are available and configurable; (even 1080P60 using 4th generation Nvidia decoding).

There is something in LAVCUVID which prevent it from displaying it's settings... all settings are blank and wont display after reloading LAVCUVID (as if cuda is not available) and wont connect to any video renderer. I can see that the LAVCUVID settings are being saved in the registry; however, they aren;'t being displayed. No errors displayed or video since renderers such as EVR cannot connect to LAVCUVID. This is on the SAME MACHINE that can use LAV Video with highest possible settings for Nvidia Cuda. I only have either LAV Video installed or LAVCUVID standalone (not both at the same time to prevent conflicts).

So, just to be clear, what improvements were made to LAVCUVID code after it was integrated into LAV Video decoder?

I am still very curious what's so different about LAVCUVID that's causing it to not connect to any video renders (EVR, VMR, etc); but I have no problems with LAV Video using Cuda and all the highest settings.

PS: UAC it turned off (lowest setting) and I am part of the administrator's group with full permissions.

Thanks for anyone that can help.

What videocard do you have ? I know NVidia, but can you tell us the exact model ?
Type CPU ? Motherboard ?
What's the version of your vid-drivers ?
What happens if you "try"to use LAVCUVID ? No video (black screen), crash,.. what errors are given ?
Current LAV-video = former (LAV-video + LAVCUVID) with some performance improvements wrt the LAVCUVID part.

Can you use DXVA with any other decoders ? (like the internal one from MPC-HC or Cyberlink , ArcSoft, Coreavc, ffdshow-dxva mode or other??...).

I'm using LAV-video (with LAVCUVID built in) since a lot of versions back without any problems on my GTX-570 and I'm very pleased with the LAV-filters !!
Especially the HW VA de-interlacing is kind of unique!

[Mixer73]

I am still very curious what's so different about LAVCUVID that's causing it to not connect to any video renders (EVR, VMR, etc); but I have no problems with LAV Video using Cuda and all the highest settings.

Being that LAVCUVID is effectively finished, and LAVFilters is the current product, does it even matter anymore that it doesn't work?

Just use LAVFilters ;)

[Xaurus]

nevcairiel,

Is it possible to simply output DTS-HD MA and Dolby True HD and other formats over 7.1 analog outputs if I use the setup in my signature with LAV audio etc.?

[nevcairiel]

For DTS-HD MA you'll need the ArcSoft dtsdecoderdll.dll, but other then that why wouldn't it be?

[Andy o]

Xaurus, find out if your receiver can apply DSP (like room correction) to multichannel analog inputs. Most AVRs (actually I can't even remember one that does) don't apply it to multichannel analog.

[Mark_A_W]

You do the room correction in the PC. Unless you spent $$$$, it will be better and free (donate).

Source -> LAV Splitter -> LAV /Audio -> ffdshow audio (mixer and per channel delay) -> Convolver Wrapper (running DRC) -> ReClock -> HDMI or Analogue out.


http://drc-fir.sourceforge.net/

[Xaurus]

Xaurus, find out if your receiver can apply DSP (like room correction) to multichannel analog inputs. Most AVRs (actually I can't even remember one that does) don't apply it to multichannel analog.
Ah, I suspected as much. Then this is really not an option for me either since the Audyssey MultEQ-XT is really nice.

nev,
Thanks.

Mark,
I didn't spend much $$$$ but see above. :)

[Qaq]

As I understand, if I use dtsdecoderdll.dll, it also start to decode DTS (I always see 16int in ReClock's monitor window for DTS sources). Isn't it better do not use dtsdecoderdll.dll for DTS, cause in case of media adaptation by ReClock it does: 32fp>16int[decoding with rounding] >32fp[resampling] >16(24)int[final rounding]?
Of course, I can use ffdshow for DTS and LAV audio for DTS-HD, but I'd prefer to use LAV audio only.

[nevcairiel]

The dtsdecoderdll actually decodes lossy DTS to 24-bit integer, which is perfectly fine - at least recent versions like 1.1.0.8 do it like that, i think it may have been different in older versions.
I also don't really see a reason to use anything older then 1.1.0.8. The only format its really known to fail on is 6.0 audio (produces only 5.0), but that is one extremely rare format

[bjd]

The dtsdecoderdll actually decodes lossy DTS to 24-bit integer, which is perfectly fine - at least recent versions like 1.1.0.8 do it like that, i think it may have been different in older versions.
I also don't really see a reason to use anything older then 1.1.0.8. The only format its really known to fail on is 6.0 audio (produces only 5.0), but that is one extremely rare format

I would second that, the other thing to consider about 32fp DTS decoders like the ffMpeg one is that they are not reference decoders and there can be minute audible differences at high frequency extremes. 24bit PCM output of DTS from the reference Arcsoft decoder is as good as it gets.

[nevcairiel]

Re: Video Post Processing

There have been some discussions before about video post-processing, especially where it should be done (in decoder or separate filter). In principle i agree that tasks should be separated, however in reality thats a real challenge in the current DirectShow eco-system.

Here is what i've been pondering:

- "Soon" i will implement software deinterlacing directly in the LAV Video decoder, but no other post-processing.
- "Later" i will create a LAV Video Processor which will add all other post-processing operations. At this point, i might also remove deinterlacing from the video decoder (this is yet to be determined).

IMHO, this offers the best compromise. For one, people that only use ffdshow because of deinterlacing will be able to remove it from their graph soon. But its not meant to be a permanent solution - in the future, there will be a new post-processor which offers deinterlacing as well as other post-processing tasks (possibly in a modular design for easy extensibility).

[mkanet]

Nev,

You might have noticed the issue I mentioned about LAVCUVID. For some reason, it wont connect to any video renderer. Also, when I go into it's prop page, none of the setting have options selected, they are all blank. If I manually add these settings, they save to the registry; however, when I open the prop page again none of the settings have options selected (as before).

I just tried LAV Audio for the first time (after I put the latest official dtsdecoderdll.dll in the x86 folder and registered the filter). Guess what? LAV Audio does something similar.. no audio renderer wants to connect to it.

The good news is LAV Video DOES WORK. What is different about it than LAVCUVID and LAV Audio?

I'm trying to find out what's different about the LAV CUVID standalone & LAV Audio filters than any other directshow filter. I can use every single directshow filter available (that I've tried)... MPC-H audio and video filters, coreavc, Arcsoft, LAV Video even, etc. For some odd reason just the LAV CUVID/LAV Audio dont want to connect to their respective renderers. I'm trying to figure out what I have on my PC's that cause this to happen. I can reproduce this on both my WinVista 32bit PC with a (Nvidia GT8500 and Creative Labs Audigy) and my Win7 64bit (Nvidia GT545 and Creative Labs Xifi).

Is there a way to send a log/debug to show you where it's failing? I have tried and tried, but just cant get

[SamuriHL]

Sounds like a solid plan, Nev. Looking forward to "soon". :D

[naoan]

Would you implement avisynth filter on your video processor?

[hoborg]

Sounds good.
Here is my LAVF "wish" list (to remove FFDshow from my HTPC) :)

Splitter (?):
-add next audio/subtitles stream keyboard shortcuts - to be able to change them by remote controller undepended on application

Audio:
-downmix to stereo (for HDMI - TV connection)

Video:
-resize + subtitles (yes, i known...)
-DVD support (to be able to use LAV video decoder for DVD)

[nevcairiel]

Would you implement avisynth filter on your video processor?

I haven't really decided anything about video processor yet, except that it'll get the filters from libavfilter in a first step (which include filters for sharpen/blur, deband, denoise, scale and some other things).

Anything is possible, and i plan to design it in such a way that adding new components should be easy, in case someone else wants to do so.


Splitter (?):
-add next audio/subtitles stream keyboard shortcuts - to be able to change them by remote controller undepended on application

Thats doubtful to ever be implemented. A DirectShow filter should not try to control playback like that, its the players job. Maybe someone could implement a dedicated remote controlling filter that just hooks into the graph to do these kinds of things.
Maybe if i ever create a tray icon this would be an option, but its nothing to expect soon because i just use a player that does it on its own. :p

The good news is LAV Video DOES WORK. What is different about it than LAVCUVID and LAV Audio?

All my filters use the same basic structure, there is no big differences.

[Superb]

Audio:
-downmix to stereo (for HDMI - TV connection)
+1. I've helped many people setting up their systems' codecs, and noticed that many machines have a broken Windows mixer. This is probably due to broken audio drivers, but it still forces people to use ffdshow show for audio decoding rather than LAV Filters. Yeah, I know you could use ffdshow "just" for down-mixing (raw audio processing), but most people rather have only one filter that does everything.

[hoborg]

Thats doubtful to ever be implemented. A DirectShow filter should not try to control playback like that, its the players job. Maybe someone could implement a dedicated remote controlling filter that just hooks into the graph to do these kinds of things.
Maybe if i ever create a tray icon this would be an option, but its nothing to expect soon because i just use a player that does it on its own. :p
Then force hookup with ffdshow raw video filter seems to be only solution for me.
Resize + subtitles and Shortcuts for Audio/Subtitles strem selection.

[nevcairiel]

+1. I've helped many people setting up their systems' codecs, and noticed that many machines have a broken Windows mixer. This is probably due to broken audio drivers, but it still forces people to use ffdshow show for audio decoding rather than LAV Filters. Yeah, I know you could use ffdshow "just" for down-mixing (raw audio processing), but most people rather have only one filter that does everything.


Downmixing to stereo is a rather easy task. I've only really not done it yet because i kind of wanted to do some more mixing options.

How many people need Stereo downmixing in contrast to how many people "want" 5.1/7.1 upmixing?

[hoborg]

BTW, why someone need upmix stereo to 5.1/7.1?

[nevcairiel]

They don't "need" it, they want it because they think it sounds better when its coming from more speakers. :)
IMHO, that only makes sense with Music. For Video, you really need some smarter algorithm like DTS Neo:6 or Dolby ProLogic IIx

[SamuriHL]

Downmixing to stereo is a rather easy task. I've only really not done it yet because i kind of wanted to do some more mixing options.

How many people need Stereo downmixing in contrast to how many people "want" 5.1/7.1 upmixing?

My laptop could use stereo downmixng. Would be quite useful.

[Superb]

Well, I guess most people I know use their computers w/ a 2.0 setup (computer or tv speakers). I guess most people in this thread have much better audio systems, but they're probably not the best representation (my English lacks when looking for the correct term) of the general use for your splitters.
If it's "a rather easy task", it would be great if you could implement it until you'll add the advanced mixer you have in mind...
Thanks again for being so responsive and understanding. :)

[STaRGaZeR]

Not liking the sound of a separate processing filter, I see no reason to do so and a lot of DirectShow problems by doing it.

ffdshow's case: audio decoder, audio processor, video decoder, DXVA decoder, raw video filter, subtitles filter. Everything except audio and video decoders is redundant, as it offers exactly the same features, just in a different filter (if this is incorrect I'd like to know it). Yet they all cause a lot of problems with merits, connections and other usual DS bullshit.

Vote for integration within the decoders. Completely separated, in both GUI and code, but inside the same DS filter.

[nevcairiel]

Well, I guess most people I know use their computers w/ a 2.0 setup (computer or tv speakers). I guess most people in this thread have much better audio systems, but they're probably not the best representation (my English lacks when looking for the correct term) of the general use for your splitters.
If it's "a rather easy task", it would be great if you could implement it until you'll add the advanced mixer you have in mind...
Thanks again for being so responsive and understanding. :)

At least AC3 and DTS support native stereo downmixing, possibly TrueHD as well, the code isn't all that clear on that fact. Mixing multi-channel into stereo is also not that hard, just a matter of defining the right coefficients to matrix those channels together.
Not sure when i'll get to it, maybe soon. Maybe i can even do a full matrix, thinking about it, it doesn't sound all that hard....

[nevcairiel]

Not liking the sound of a separate processing filter, I see no reason to do so and a lot of DirectShow problems by doing it.

ffdshow's case: audio decoder, audio processor, video decoder, DXVA decoder, raw video filter, subtitles filter. Everything except audio and video decoders is redundant, as it offers exactly the same features, just in a different filter (if this is incorrect I'd like to know it). Yet they all cause a lot of problems with merits, connections and other usual DS bullshit.

Vote for integration within the decoders. Completely separated, in both GUI and code, but inside the same DS filter.

The thing is, i don't want to create another ffdshow.
I don't want to create a filter that has so many features that most people would never use anyway (me included). I typically don't use any post-processing short of deinterlacing, which means i don't want "my" filter to include all those options that are perfectly useless to me.

In the end, this would mean that the post-processing included in the decoder would probably be rather light-weight, possibly limited to what ffmpeg/libavfilter offers because i include those anyway. Anything beyond that i would be *very* hesitant to include in the decoder.

Note that my design would be different to ffdshow. My "video processor" would only do video processing, and my decoder would only do decoding. The decoder would not offer the post-processing options like ffdshows decoder does now.

What we would get would only be two filters:

LAV Video Decoder (ONLY decoding, both software and hardware decoders)
LAV Video Processor (all post-processing tasks)

No other special filters for special tasks.

Anyway, i doubt that i'll get to those any time soon, because as i said i don't use post-processing, and there are many other things to do which i do actually use. ;)

[andyvt]

Downmixing to stereo is a rather easy task. I've only really not done it yet because i kind of wanted to do some more mixing options.

How many people need Stereo downmixing in contrast to how many people "want" 5.1/7.1 upmixing?

FWIW, I only care about downmixing. I'd like to switch DS transcoding in DTB over to LAV (it's mostly based on custom MPC-HC filters now).

[havas]

LAV Filters really very impressive. the only things Im confused is about subtitle.
First I never saw subtitles on the video whenever i using windows medial player or mpc(disable its subtitle function)
I've unchecked only with the macthing language option in LAV Splitter.

otherwise, I can see subtitle items in Navigate menu when using mpc open a mkv file contains subtiltes(external subtitls file seems can't)). but it seems no work.

[dbone1026]

Even better if LAV could downmix my wife when she is yelling at me (mute preferable, but downmix is still acceptable!).

I do agree though that downmix is all I care about as well, especially for my laptop which I will connect at times directly to a TV

[nand chan]

Downmix is all I care about as well, as I use headphones most of the time, and my DAC only accepts a 96/24 stereo PCM stream (not that I could send anything else over S/PDIF in the first place).

On that matter, I am of the very strong opinion that a decoder should not do post processing. For post processing, you should use post processing filters. The decoder should only decode a source to its closest identical raw representation (eg. YV12 or PCM).

All setup-dependent and/or critical processing (eg. down mixing, upmixing, resampling (audio) or upscaling, color space conversion and chroma interpolation (video)) should be done by the audio/video renderer.

All non-critical, optional post processing (eg. noise reduction, debanding, sharpening, bass boost, compression) should be done by optional filters.

So while things like audio delay should be compensated for by the audio renderer, and things like color correction should be done by the video renderer (depending on which monitor you play on), all things that are universal, independent of source/output methods and/or optional (and sometimes unnecessary) should be handled separately.

This way, you ensure that, for example, down mixing works regardless of which audio decoder you use, and you can freely enable/disable post processing filters without losing it.

Furthermore, it ensures that, when changing the output sound device in your audio renderer, it changes the way things are down mixed as well.

[nevcairiel]

On that matter, I am of the very strong opinion that a decoder should not do post processing. For post processing, you should use post processing filters. The decoder should only decode a source to its closest identical raw representation (eg. YV12 or PCM).

While i agree with you in principle, what about formats where the source actually carrys metadata that help doing a proper stereo downmix, for example like AC3 and DTS?

I would love to do everything the ideal way, however DirectShow is a platform far from ideal, so maybe one has to accept some compromises.

For example i know of no audio renderer that does proper mixing (or at least customizable mixing), so why should i not write a post-processing filter to compensate?
On the other hand, there are some players (especially WMP/WMC, but not limited to them) which do not allow a free-form graph building, and only use a decoder, no other filters between source and renderer. Secondly, those players are otherwise broken that they usually don't allow dynamic channel count changes. So if thats a feature supposed to work in those players, the decoder will need an option to convert the audio to one common channel layout (preferably matching the users preference).

DirectShow is just no place for idealism. While i try to keep some kind of standards, doing things the way i think its right instead of the way everyone else expects, sometimes you just gotta face the (sad) reality of DirectShow.

[clsid]

In case of basic audio processing such as mixing, I agree it is better to include it directly in the audio decoder.

With regard to video processing, some comments:
- don't some deblocking algos require info that is only available in the decoder?
- the MS players do not load intermediary filters in Win7. Will the decoder have an option to forcefully insert the processor in the graph?
- perhaps basic processing (deinterlace, deblock, deband) could be placed in the decoder and more advanced (and lesser used) stuff in a separate processing filter.

My short term wish list:
- tray icon for splitter
- store format settings in audio similar to video/splitter
- downmix to stereo
- 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

[nevcairiel]

Deblocking is part of the decoding, and not a post-processing step. Its always done in the decoder. I know that some decoders offer the ability to turn it off, but thats just quality degredation, and i won't offer it. :)

[clsid]

I am not talking about inloop deblocking for H.264, but the optional deblocking of for example MPEG-4 ASP.

[STaRGaZeR]

The thing is, i don't want to create another ffdshow.
I don't want to create a filter that has so many features that most people would never use anyway (me included). I typically don't use any post-processing short of deinterlacing, which means i don't want "my" filter to include all those options that are perfectly useless to me.

In the end, this would mean that the post-processing included in the decoder would probably be rather light-weight, possibly limited to what ffmpeg/libavfilter offers because i include those anyway. Anything beyond that i would be *very* hesitant to include in the decoder.

Note that my design would be different to ffdshow. My "video processor" would only do video processing, and my decoder would only do decoding. The decoder would not offer the post-processing options like ffdshows decoder does now.

What we would get would only be two filters:

LAV Video Decoder (ONLY decoding, both software and hardware decoders)
LAV Video Processor (all post-processing tasks)

No other special filters for special tasks.

Anyway, i doubt that i'll get to those any time soon, because as i said i don't use post-processing, and there are many other things to do which i do actually use. ;)

And who wants another ffdshow, we already have one. Nobody wants all that crap that is bundled with it. The point is not about the number or complexity of filters and what not. One more filter in DS means one more problem you have to deal with, and you know this damn well. To gain what exactly? Those filters need information, that information is most of the time lost from filter to filter. Color space issues. Graph building related issues. Problems with other decoders. Long list right here.

Also IMHO it makes no sense to do some of them in the decoder, some others in a separate filter, or the other way around. By the way, the video decoder already does more than just decoding video, and the audio decoder already does more than decoding audio.

[nevcairiel]

There really isn't any serious post-processing going in in either filter.
LAV Audio can change the timestamps of the audio (delay option) as well as pad the PCM with empty channels so that broken post-processors or renderes don't choke on odd layouts, but it never actually modifys any of the audio. (LAV Audios DRC option is done *during* AC3 decoding, utilizing the AC3 internal DRC flags)
On LAV Video the only post-processing is the hardware deinterlacing, which you really cannot separate without *major* disadvantages, and i guess you could consider the pixel format conversions a "post processing" step (dithering, RGB conversions, etc).

I'm not *generally* opposed to doing basic post-processing inside the decoder, the point is just that i would never expand the decoder-internal post-processing beyond a certain point, while with a separate filter, only the sky is the limit.
But if i start to include post-processing in the decoder, its likely that i'll never do a separate post-processor at all.

[nand chan]

While i agree with you in principle, what about formats where the source actually carrys metadata that help doing a proper stereo downmix, for example like AC3 and DTS?

Meta data pins

I would love to do everything the ideal way, however DirectShow is a platform far from ideal, so maybe one has to accept some compromises.

Why don't we define a common, unified, expandable and future-safe DirectShow extension channel for carrying all sorts of meta data, then submitting patches to all open source projects to implement this? Instead of adding more and more hacks before we end up with a completely unusable system.

For example i know of no audio renderer that does proper mixing (or at least customizable mixing), so why should i not write a post-processing filter to compensate?

Instead of writing a post-processing filter to compensate, why don't you write an audio renderer to compensate?

On the other hand, there are some players (especially WMP/WMC, but not limited to them) which do not allow a free-form graph building, and only use a decoder, no other filters between source and renderer. Secondly, those players are otherwise broken that they usually don't allow dynamic channel count changes. So if thats a feature supposed to work in those players, the decoder will need an option to convert the audio to one common channel layout (preferably matching the users preference).

I suppose that's a reasonable complaint, but is WMP compatibility really more important than idealism? Do you still add IE6 compatibility code to every single website you write? I think conforming to the broken workings of some shitty program that should die out is not a good idea. It's better to drop support for it, to make people being to realize their choices are broken. It's not the fault of your decoders, or DirectShow, or ffdshow, if these don't work properly.

DirectShow is just no place for idealism. While i try to keep some kind of standards, doing things the way i think its right instead of the way everyone else expects, sometimes you just gotta face the (sad) reality of DirectShow.

Is it time for DirectShow 2? How about a hybrid standard that allows passing GPU resources as well, so you can combine GPU post processing filters just like normal filters?

[nevcairiel]

Why don't we define a common, unified, expandable and future-safe DirectShow extension channel for carrying all sorts of meta data, then submitting patches to all open source projects to implement this? Instead of adding more and more hacks before we end up with a completely unusable system.

DirectShow cannot be safed anymore.
Anyway, regarding the example, the downmixing meta data is typically not exported from a decoder. You just tell it to give you stereo, and so it does. Even if there was a possibility to export that to a mixer component downstream, the data is not accessible without alot of extra work.


Instead of writing a post-processing filter to compensate, why don't you write an audio renderer to compensate?

Because writing a audio renderer that does what i need is 1000x times more complex.

I suppose that's a reasonable complaint, but is WMP compatibility really more important than idealism? Do you still add IE6 compatibility code to every single website you write?
No, but i support IE8 and IE9. :p
WMP is quite a common player, and especially WMC is used quite commonly because it has a nice interface and is easy to use with a remote control. I usually don't spend all that much time trying to get something specific to work on WMP/WMC, but i won't completely abandon it either.


Is it time for DirectShow 2?
Its called Media Foundation, and it solves many of the DirectShow headaches. Sadly other then WMP and some other rather exotic players nothing supports it.

How about a hybrid standard that allows passing GPU resources as well, so you can combine GPU post processing filters just like normal filters?
In Media Foundation its actually possible to have a DXVA-aware post-processor, not just decoders. In this mode you pass around D3D textures with the image on them instead of memory buffers.

I would love to write a full processing chain "done right" in Media Foundation, but what good is writing all this code if there is nothing to use it.

The main point is, there aren't all that many active DirectShow developers around, especially those willing to share their stuff, and not lock it in their own commercial players (I'm actually kind of surprised no-one approached me yet trying to recruit me into some commercial DirectShow software. :p)
Development time is severly limited, and idealism does cost a whole lot more time, especially if you're fighting to live in an eco system that really doesn't support your design all that well.

Personally, i could do without any post-processing beyond what LAV Video/LAV Audio already do now (if you can call that post-processing). Since i have no great personal interest in it, its doubtful that any design that requires alot of extra effort would actually be implemented. So the question gets basically down to: basic post-processing in the filter, or not at all. Since i can make some people happy with at least providing the very basic/important tasks like deinterlacing, i might as well do so. Deinterlacing is the renderers job, IMHO, but waiting until madVR does it is boring. I never was really patient in such situations. :)

Its hard to balance between ones ideals and actually writing software thats usable. At the end of the day, i prefer siting down and actually watching a movie with the stuff i developed. :)

[clsid]

Just keep it simple and add the basic processing to the decoders. Advanced stuff like Avisynth is only used by a tiny minority, and those can continue to use ffdshow for processing. For standard users, yourself included, the basics will be more than sufficient, and it is preferable to have just a single filter doing it magic.

[ajp_anton]

- "Later" i will create a LAV Video Processor which will add all other post-processing operations. At this point, i might also remove deinterlacing from the video decoder (this is yet to be determined).Avisynth processing, please? =)
So you can do pretty much anything you like.

[SEt]

Another request for Avisynth processing in video decoder (and no need for anything else). "Some basic filtering" with myriads of options looks very ffdshow-ish and belongs to separate filter.

Downmixing would be great in audio decoder (the only reason I still use ffdshow audio decoder).

I disagree that deinterlacing is renderer's job - it should be done before almost any other filtering, so unless you want to put all filtering into renderer - decoder is good place for it.

[andyvt]

I disagree that deinterlacing is renderer's job - it should be done before almost any other filtering, so unless you want to put all filtering into renderer - decoder is good place for it.

DI in the decoder would make transcoding easier too.

[kennae]

+1 for downmixing to stereo, really all I can think of using.

[patul]

I would love to write a full processing chain "done right" in Media Foundation, but what good is writing all this code if there is nothing to use it.


Maybe it's the time for MF-based LAV Player? :p

[nevcairiel]

Another request for Avisynth processing in video decoder (and no need for anything else). "Some basic filtering" with myriads of options looks very ffdshow-ish and belongs to separate filter.
AviSynth is such a complicated thing to support properly that it also belongs in its own filter, tbh. :)

My "basic filtering" would probably fill half a propertys page, it would be limited to: deinterlace, denoise, deband and sharpen/blur.

My main concern is that AviSynth is very complicated to use, even in simple setups. It requires setup of external support libraries (AviSynth itself and some plugins you want to use), so for anyone just wanting a simple denoiser or sharpener, thats alot to ask. From the code side of things, integrating libavfilter is pretty straight forward, so only the options concern remains.

I might be willing to offer AviSynth support some day, but i don't want it to be the only way to do some very basic every-day processing.


Downmixing would be great in audio decoder (the only reason I still use ffdshow audio decoder).

Didn't you just recently advocate against doing such things in the decoder? :)

Where i am standing right now on the whole subject, i will definitely add deinterlacing to the video decoder, and i will most likely add a mixer to the audio decoder. Anything beyond that, i'm not sure yet. Since deinterlacing will already use libavfilter, adding more filters will just be a matter of adding the options, the code is already there ... so why not? It will be limited to 3 or 4 processing operations, and there won't be much choice between different algorithms like ffdshow has.

Maybe it's the time for MF-based LAV Player? :p
I'll lock myself in a room for a year or two and come out when its ready. :p

[boyumeow]

@mkanet,

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

[Motenai Yoda]

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

[PeQuE]

Hi nevcariel,

I've uploaded a video (in fact, recorded mpeg2 TV .ts) that Lav Video is failing at deinterlacing from time to time.

http://dl.dropbox.com/u/15222696/MP_20111005_18-05_Bar%C3%A7a%20TV_Temps%20de%20joc.%20La%20Lliga.ts

As a side comment, Win7 MS DVB included codec for MPEG2 is also failing the same way, while Cyberlink (9 & 11) Video/SP Decoder is doing it well.

Hope you can take a look.

Thanks a lot!
Hi...

Did you find a moment to have a look at that, nev?

Thanks again!