ffdshow tryouts project: Discussion & Development

[tetsuo55]

Sorry but that sounds a million times more complicated then

[]Enable DXVA for all compatible h264 videos (fallback to software decoding otherwise)
"Repeat for all bitstreamable formats"

If what you suggest gets implemented it should be the same for the audio codecs that have a bitstream option.

Overall, ffdshow probably already is overly complicated for average joe users that just want to wacht a video.

[clsid]

You can not compare audio bitstreaming with DXVA. The audio stuff in ffdshow requires parsing to determine the true format. That is not required for H.264 and VC-1. And just because audio bitstreaming happens to be integrated into ffdshow is no valid argument at all for doing the same with video.

My goals are to make things more simple for the average joe. Keeping unrelated things separate is one of the ways to achieve that goal. Your argument for making a bigger mess because something is already a mess is just stupid.

[dann23]

hello. about this thing with dxva separated from normal ffdshow, I want to tell that average joe is not stupid :D
many are already familiar with this interface and know what those options do. I think separating dxva make things worse because this options is not there with the others. I think it's more usefull if dxva is on the same window with the other options for video decoding.

[albain]

@clsid : I understand your point, I won't argue with it but there are still 2 things I didn't mention or I wasn't clear enough

1/ First the code won't be cleaner because
The DXVA implementation uses the same code path as regular codecs.
The different thing is in the videocodec classes : instead of calling the processing function to apply filters, I don't call it at all.

So using a different codec won't necessarily bring cleaner code


2/ DXVA postprocessing : DXVA postprocessing is possible such as subtitles, OSD... and so reusing the existing FFDshow filters. Wouldn't it be better to make it transparent for our old friend joe ?


Also please let's remain constructive on this subject although I know that relationship with MPC team is sometimes "intense"

Anyway, I will make it in a separate filter if this is your final wish, I don't think that would be a big problem for anyone, even for you guys from MPC team.
But first let's focus on making it work, I am stuck with this green picture, and I will post a patch+working build then, and then we will make the final decisions, ok ?

[SamuriHL]

@albain - Is this green screen situation happening with an ATI card by chance? It sounds VERY similar to the crap I'm dealing with on PDVD9 which is why I ask.

[albain]

@albain - Is this green screen situation happening with an ATI card by chance? It sounds VERY similar to the crap I'm dealing with on PDVD9 which is why I ask.

Yes but I don't have this issue with MPCHC in DXVA mode.

I think this is a wrong colorspace issue but DXVA works in NV12 mode and the structures look similar between ffdshow and mpc, so...

It shouldn't be very difficult to fix....

[SamuriHL]

Can you provide the fix to Cyberlink when you're done? :p

[73ChargerFan]

My set is 1080p. I'd like to use software decoding if the video is <1080p with filters to make the scaling look better, and DXVA with different filters (e.g. color space conversions) if video is 1080p.

[_xxl]

2/ DXVA postprocessing : DXVA postprocessing is possible such as subtitles, OSD... and so reusing the existing FFDshow filters.
I would like to know which of ffdshow filters can be used in combination with DXVA?
Thanks for the improvement of ffdshow's audio code and I hope that a simple solution will be found for DXVA & ffdshow...

[tetsuo55]

I would like to know which of ffdshow filters can be used in combination with DXVA?
Thanks for the improvement of ffdshow's audio code and I hope that a simple solution will be found for DXVA & ffdshow...all filters that put some effect over the image could work. Any filter that requires the decoded video image as input wont.

[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 (http://sourceforge.net/tracker/?func=detail&aid=2914331&group_id=173941&atid=867362)

[tetsuo55]

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]

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]

EDIT : okay, parallel posting

Sometimes it is needed even posted involuntary or accidentally :)

[STaRGaZeR]

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]

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]

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

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

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

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)

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.

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 waycannot 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 (http://git.videolan.org/?p=vlc.git;a=blob;f=extras/contrib/src/Patches/ffmpeg-dxva2.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=blob;f=modules/codec/avcodec/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]

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 (http://git.videolan.org/?p=vlc.git;a=blob;f=extras/contrib/src/Patches/ffmpeg-dxva2.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=blob;f=modules/codec/avcodec/dxva2.cWoah, 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]

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



http://msdn.microsoft.com/en-us/library/cc307941(VS.85).aspx

[MatMaul]

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 :D
I will send a report to vlc-devel to let them know of this awful implementation bug ^^

[albain]

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.

Are you sure about that ?

Because I read DXVA 2 docs a while ago and they didn't mention this possibility. Also the DXVA (1 or 2) APIs take an encoded picture and returns nothing

If it was possible to grab a decoded picture back from the GPU memory (which I doubt), then ffdshow internal filters could work

EDIT : the patch you mentioned is from VLC team, not ffmpeg. The benefit I see is that APIs are finally all included into ffmpeg but there are still some stuff that have to remain into directshow layer (so ffdhow code) such as the DXVA allocator...
But afterwards it is not very different from MPC patch, maybe cleaner, I don't know yet

[tetsuo55]

Are you sure about that ?

Because I read DXVA 2 docs a while ago and they didn't mention this possibility. Also the DXVA (1 or 2) APIs take an encoded picture and returns nothing

If it was possible to grab a decoded picture back from the GPU memory (which I doubt), then ffdshow internal filters could work

EDIT : the patch you mentioned is from VLC team, not ffmpeg. The benefit I see is that APIs are finally all included into ffmpeg but there are still some stuff that have to remain into directshow layer (so ffdhow code) such as the DXVA allocator...
But afterwards it is not very different from MPC patch, maybe cleaner, I don't know yetthats the whole idea with dxva2, completely independent, you can renderer it to a dx surface and then take that image into the ffdshow postprocessing chain

[MatMaul]

EDIT : the patch you mentioned is from VLC team, not ffmpeg. The benefit I see is that APIs are finally all included into ffmpeg but there are still some stuff that have to remain into directshow layer (so ffdhow code) such as the DXVA allocator...
But afterwards it is not very different from MPC patch, maybe cleaner, I don't know yet
I think it is still a lot cleaner since you can directly use the public ffmpeg API and not some exported functions.

[NiFa]

Is there any plans to add DTS encoding support to ffdshow?
Sorry if this was asked earlier.

[73ChargerFan]

No freeware dts encoder has been written, they are all commercial.

[NiFa]

How come, that no one have written freeware or open source dts encoder? I so hope that someone would do it, but I can't do anything 'bout it if no one is willing to do it. :(

[SamuriHL]

The specs aren't available afaik.

[tetsuo55]

How come, that no one have written freeware or open source dts encoder? I so hope that someone would do it, but I can't do anything 'bout it if no one is willing to do it. :(the company that owns DTS is very willing and able to sue anyone who dares to try. But the main reason is that they keep all their technoligy secret, reverse engineering from nothing is very difficult.

[NiFa]

Ok, now I understand, thanks to making this clear.

[markanini]

I agree Support for <Vista is more important than WinXP. It's an outdated OS with some issues in media support compared to later Windows versions. Maybe detecting Windows version and applying DXVA1/2 accordingly would be feasable?

[Keiyakusha]

Isn't AC3 with the same bitrate as DTS gives twice better quality?

[SamuriHL]

AC3 is limited to 640kbps. DTS can do up to 1.5mbps.

[Keiyakusha]

AC3 is limited to 640kbps. DTS can do up to 1.5mbps.

Yes, but AC3 640 kbps gives the same quality as DTS 1.5mbps.
Can anyone confirm or deny?

[SamuriHL]

Yes, but AC3 640 kbps gives the same quality as DTS 1.5mbps.
Can anyone confirm or deny?

That's not my feeling on it, no. Back when I was doing DVD regularly, DTS always sounded much better for a variety of reasons. One of which is the higher bitrate, but, there are others, too.

[Keiyakusha]

But higher bitrate doesn't mean higher quality if we talking about different formats

[SamuriHL]

http://www.audioholics.com/education/surround-sound/dolby-digital-vs-dts-a-guide-to-the-strengths-of-the-formats

I don't want to take this thread further off topic, but, that should help.

[Snowknight26]

The tooltip for Auto under Input Levels in ffdshow's video config is a bit misleading. It doesn't say whether ffdshow will disregard the flag or not.

[tetsuo55]

DTS is should be better, but i doubt it really matters for realtime encoding

[_xxl]

There is a soc project for dca encoding here:
svn://svn.mplayerhq.hu/soc/dcaenc
This source is based on code from here:
http://roundup.ffmpeg.org/roundup/ffmpeg/file153/edts-20080207.tar.gz

[SamuriHL]

DTS is should be better, but i doubt it really matters for realtime encoding

I would completely agree with that.