ffdshow tryouts project: Discussion & Development

[STaRGaZeR]

I think clsid wants this separate filter because if not he'll get loads of complaints in this and other forums where he's helping joe's out. I can understand his positon but this is just stupid: you already have what you want, and it's included in the MPC standalone filters. What's the logic behing making another MPC Video Decoder with just DXVA and "with a couple of checkboxes and value fields"? Because I can't find any. You can just add these to the MPC Video Decoder dialog box (something a lot of people including me have been suggesting for a long time with no response from the devs), it'll be MUCH simpler and would do everything you want.

[khagaroth]

A fix for the installer, as it now displays garbage instead of all the custom messages after you switched to (Unicode) Inno 5.3.x - sourceforge tracker

[tetsuo55]

Originally Posted by STaRGaZeR

I think clsid wants this separate filter because if not he'll get loads of complaints in this and other forums where he's helping joe's out. I can understand his positon but this is just stupid: you already have what you want, and it's included in the MPC standalone filters. What's the logic behing making another MPC Video Decoder with just DXVA and "with a couple of checkboxes and value fields"? Because I can't find any. You can just add these to the MPC Video Decoder dialog box (something a lot of people including me have been suggesting for a long time with no response from the devs), it'll be MUCH simpler and would do everything you want.

The basic idea here is to make ffdshow feature complete as a codec, and then use it instead of the mpc video decoder, that way we only have to maintain one codec-tree instead of 2

[albain]

Originally Posted by STaRGaZeR

I think clsid wants this separate filter because if not he'll get loads of complaints in this and other forums where he's helping joe's out. I can understand his positon but this is just stupid: you already have what you want, and it's included in the MPC standalone filters. What's the logic behing making another MPC Video Decoder with just DXVA and "with a couple of checkboxes and value fields"? Because I can't find any. You can just add these to the MPC Video Decoder dialog box (something a lot of people including me have been suggesting for a long time with no response from the devs), it'll be MUCH simpler and would do everything you want.

We are not talking about the interest of bringing DXVA support to ffdshow versus MPC standalone filters but rather implement it inside a separate filter or not.
I understand clsid's position and I will follow his request at the end of the discussion which is not closed in my opinion

About MPC standalone filters, few people use them in standalone release.
Lastly, this support is also a benefit for MPC team but I will let them give more details about it

EDIT : okay, parallel posting

[rica]

Originally Posted by albain

EDIT : okay, parallel posting

Sometimes it is needed even posted involuntary or accidentally

[STaRGaZeR]

Originally Posted by albain

We are not talking about the interest of bringing DXVA support to ffdshow versus MPC standalone filters but rather implement it inside a separate filter or not.
I understand clsid's position and I will follow his request at the end of the discussion which is not closed in my opinion

About MPC standalone filters, few people use them in standalone release.
Lastly, this support is also a benefit for MPC team but I will let them give more details about it

EDIT : okay, parallel posting

Neither am I, I want DXVA in ffdshow. Inside ffdshow. I'm just saying what's the logic behind a separate filter, since we already have a separate DXVA filter that does the same thing you want accomplish. Or am I missing something?

[Keiyakusha]

Originally Posted by STaRGaZeR

Or am I missing something?

DXVA is the only "unique" thing in MPC-HC codecs set. Everything else is the same as in ffdshow (however some ffdshow filters is faster for me). As I understand from what tetsuo55 said, they will port DXVA to FFDShow and then drop support for all MPC-HC's filters.

EDIT: By the way, what about splitters? Maybe they will be fine in ffdshow as separate filter set (or how should I call this...)? Then it will be truly complete ^_^

[clsid]

Even when the DXVA filter is separated from the ffdshow filter, it should still be possible to re-use code from ffdshow, since most functionality is divided in their own source files. For example font rendering and subtitle stuff. Just the GUI needs to be redone. But considering that most GUI elements in ffdshow do not apply to DXVA, that will result in a small and simple GUI for the DXVA filter. Plus we don't need to disable stuff in the GUI when DXVA is active. For example, suppose the DXVA decoder will eventually be compatible with subtitles, then we can't just blindly re-use all the current subtitle options available in ffdshow. Things like letterboxing are obviously not possible with DXVA.

@STaRGaZeR
Making the filter separate will not in any way reduce functionality. I do not understand why people always insist on getting things integrated when it holds no benefits at all. The ffdshow filter suite will replace the (internal) decoders of MPC. Then the MPC devs can focus on the core of the player, like making it more stable and secure.

@dann23
Many here on this forum even do not fully understand the limitations that DXVA has or what all the options in ffdshow do. I have years of experience helping people with video playback, so I have a very good understanding of what is best for the people that use ffdshow.

[albain]

No, FFDShow is not (and will never be) a splitter

It has been a long time one said that ffdshow is too messy and should be splitted up into smaller parts.

Also another thing that should be done is direct media foundation support, but another layer to the code.

About different filters, one should also ask the question about the future : which DXVA filters could be added apart subtitles.
If may be smart to have only the list of available internal filters wether you are in DXVA or not.

For me this is more work to do so I am gonna think about the right implementation to do if we decide to go on that way

EDIT : parallel posting again

[STaRGaZeR]

Originally Posted by clsid

@STaRGaZeR
Making the filter separate will not in any way reduce functionality. I do not understand why people always insist on getting things integrated when it holds no benefits at all. The ffdshow filter suite will replace the (internal) decoders of MPC. Then the MPC devs can focus on the core of the player, like making it more stable and secure.

So THAT's your final intention, replace MPC's internal decoders with ffdshow. You didn't say this in any of your previous post (or did I miss it?). Now everything is clear. I fully support this movement, I've always wondered why, being the same thing and ffdshow having a lot more options, they were separated.

[tetsuo55]

Originally Posted by albain

No, FFDShow is not (and will never be) a splitter

Indeed.

Originally Posted by albain

It has been a long time one said that ffdshow is too messy and should be splitted up into smaller parts.

i have not looked at the code myself, but its probably just as bad as mpc-hc

Originally Posted by albain

Also another thing that should be done is direct media foundation support, but another layer to the code.

I agree, adding this shouldnt be too difficult if you turn ffdshow into a mediafoundation codec with directshow fallback (each codec registering 2 filters)

Originally Posted by albain

About different filters, one should also ask the question about the future : which DXVA filters could be added apart subtitles.
If may be smart to have only the list of available internal filters wether you are in DXVA or not.

Filters that will surely work with DXVA are: OSD, Subtitles and bitmap overlay.
If you update the dxva decoder to a DXVA2 implementation (casimir has a POC for this), all filters would work, but it would completely stop working on xp.

Originally Posted by albain

For me this is more work to do so I am gonna think about the right implementation to do if we decide to go on that way

cannot wait to hear what you come up with

[_xxl]

I think that splitting ffdshow's video, audio, processing and subtitles, DXVA support in standalone filters is a good solution.

If you update the dxva decoder to a DXVA2 implementation (casimir has a POC for this), all filters would work, but it would completely stop working on xp.

Supporting Win7 is more important than XP.

[clsid]

Windows XP still has a 50%+ market share. But compared to Vista/7 it will more often be running on systems without DXVA support. So one day we could decide to drop DXVA support for XP. But I don't think now is the right time yet. We must also consider the fact that XP users are more likely to depend on DXVA from a performance perspective. For example many netbooks use XP.

It would be cool if we could transform the filters in ffdshow into a plugin based system. But I am not sure how difficult that will be considering that it is not unlikely that there are many nasty workarounds and hacks in the current filter chain.

[MatMaul]

VLC 1.1 supports hardware decoding using DXVA2.
moreover it uses directly the hardware decoding architecture of ffmpeg (which supports VDPAU/VA-API on linux and DXVA2 with this patch). it would be good to use it to avoid hacking of ffmpeg like in the MPC decoder.

I think it would be OK to just support DXVA2 with ffdshow, since people using XP could still use the "legacy" MPC DXVA standalone decoder.

here is the source code for the VLC decoder :
http://git.videolan.org/?p=vlc.git;a...vcodec/dxva2.c

[73ChargerFan]

How about adding to video profiles the choice of which h264 renderer & VC1 renderer to use. DXVA2 can be shown as unavailable on XP. VC1 can include the option to use MS. Also it would contain a list of compatible filter types, e.g. subtitles, all, overlay_only, etc.

[tetsuo55]

Originally Posted by MatMaul

VLC 1.1 supports hardware decoding using DXVA2.
moreover it uses directly the hardware decoding architecture of ffmpeg (which supports VDPAU/VA-API on linux and DXVA2 with this patch). it would be good to use it to avoid hacking of ffmpeg like in the MPC decoder.

I think it would be OK to just support DXVA2 with ffdshow, since people using XP could still use the "legacy" MPC DXVA standalone decoder.

here is the source code for the VLC decoder :
http://git.videolan.org/?p=vlc.git;a...vcodec/dxva2.c

Woah, i was not expecting that to happen so quickly, that code was only finished a few weeks ago

[albain]

Very interesting indeed, this could autosolve my green picture issue by the way

However, is this DXVA2 support only (vista/7) ?

We have to think about it : I'd rather take the ffmpeg over the MPC patching solution but we may have to drop DXVA1 support

@clsid : do you think you could update libavcodec with those latest APIs ?

[dann23]

Originally Posted by albain

However, is this DXVA2 support only (vista/7) ?

http://msdn.microsoft.com/en-us/libr...41(VS.85).aspx

[MatMaul]

Originally Posted by albain

Very interesting indeed, this could autosolve my green picture issue by the way

However, is this DXVA2 support only (vista/7) ?

Yes, and I think the main reason is that DXVA2 seems to support the retrieving of picture from GPU memory to the main memory (so no need for a specific renderer) which is needed to work with VLC because it doesn't support any standard directshow renderer.

[MatMaul]

I should add that I think there are some hacks needed because of bad DXVA drivers (*cough* ATI *cough*) that doesn't seem implemented in the current VLC. I am thinking of the raster vs zigag order which is triggered with files using custom matrices.
It also seems that people who write this ffmpeg patch are clever because they add a variable "workaround" (currently unused) in the context for this kind of hacks
I will send a report to vlc-devel to let them know of this awful implementation bug ^^