ffdshow tryouts project: Discussion & Development

[tetsuo55]

Originally Posted by hoborg

Finally, in ATI Catalyst 10.5 preview, ATI introduced full h.264 DXVA decoding support including profile 5.1 and 16ref frames (DXVA 2.0)
Look on video on this page:
http://www.diit.cz/clanek/akcelerace...funguje/36026/

I googled some more on this because that site is a bit vague.

I couldnt find much english chatter about this but based on google translate i read the following:

the 10.5 driver is a seperate branch from the 10.3/10.4 trunk.
Besides having a new avivo core that moves both VC1 and H264 to the "L5.1" limits and improving the transcoder many other things are changed.

OpenGL/CL drivers are up by 15 revisions!
Longstanding bugs in DirectX games appear to have been fixed, and performance is up in underperforming ones.

Please try it out! (also with the ffdshow dxva decoder)

[_xxl]

MSVC 2010 can't compile ffdshow.ax, a get errors with svn version of tuple.h. Has someone compiled successfully with MSVC2010?

[XhmikosR]

Nope, last time I tried MSVC 2010 I got some errors too.

http://pastebin.com/SMR7E2nz

[SamuriHL]

I've yet to download and install it. I hear there's some good improvements.

[hoborg]

Hi.
Devs with ATI, can you look on this sample?
There is pixelation if ATI catalyst 10.3 is in use on my 5770 (WinXP).
Strange is, this doesnot happend if PDVD9 decoder (DXVA on) is in use.
Can be problem in FFDshow DXVA decoder?

[Snowknight26]

Any word on whether the lossless H.264 with DXVA issue will be fixed?

[DMD]

ffdshow video is a problem or mpchc?

happens with 2 different releases of ffdshow:

pin SubPicure DVD navigator connected to pin MPC

ffdshow_rev2099_20080903_clsid_sse_icl10



because the pin SubPicure MPC is not automatically linked?

one of the latest releases ffdshow_rev3356_20100411_sse_icl11

[ikarad]

http://www.mediafire.com/?sharekey=3...e79d7d0540e1e1
What is the difference between ffdshow_rev3361_20100415_xhmikosr.exe and ffdshow_rev3361_20100415_xhmikosr_icl11_core2.exe?
The second file is just for double core?

[tetsuo55]

Since albain is getting closer to a stable build i would like to ask everyone to help out getting a clean libavcodec for both ffdshow and mpc-hc.

the following looks like a clean solution:

src/libavcodec/ffmpeg/ (this contains the clean and complete export from ffmpeg

src/libavcodec/patches (this contains
* ffmpeg_directshow_patch (this turns it into a dshow filter)
* ffmpeg_mediafoundation_patch (this turns it into a MF filter)
* ffmpeg_h264_dxva_patch (adds DXVA1, 2 and HD)
* ffmpeg_mpeg2_dxva_patch (adds DXVA1, 2 and HD)
* ffmpeg_VC1_dxva_patch (adds DXVA1, 2 and HD)
* ffmpeg_windows_configpanel_patch (adds the settings panel)
* ffmpeg_bitstreaming_patch (adds support for bitstreaming (HD-)audio)

Both combined become the clean and correct codec.ax that can be used standalone, in ffdshow and in mpc-hc.

This way we can report bugs upstream again and updating becomes less painfull, also this part of the code can be completely shared between both projects lowering the time taken to work on that section of code.

[clsid]

Sorry, but this is a useless suggestion. First of all, except for dxva, all of those things are done outside of the ffmpeg library. Secondly, it is totally impractical to maintain code like you suggest.

If you want to simplify things for MPC, then consider using ffdshow's libavcodec.dll instead of linking it directly into MPC/MPCVideodec. Or better yet, stop trying to replicate ffdshow functionality and just tell MPC users to use ffdshow.

[tetsuo55]

Originally Posted by clsid

Sorry, but this is a useless suggestion. First of all, except for dxva, all of those things are done outside of the ffmpeg library. Secondly, it is totally impractical to maintain code like you suggest.

If you want to simplify things for MPC, then consider using ffdshow's libavcodec.dll instead of linking it directly into MPC/MPCVideodec. Or better yet, stop trying to replicate ffdshow functionality and just tell MPC users to use ffdshow.

What you suggest is the reason for my post. We still intend to include libavcodec but as a direct clean mirror from ffdshow instead.

The current implementation is messy and difficult to maintain, your post does not suggest an alternative that makes it easier.

[Keiyakusha]

is it possible to strip all decoders in mpc-hc (including DXVA ones), integate ffdshow in mpc-hc so there will be ffdshow settings page where internal filters are located and bundle ffdshow with mpc-hc?

[clsid]

The current implementation is messy and difficult to maintain, your post does not suggest an alternative that makes it easier.

Exactly what do you think is messy? Updating the FFmpeg code in MPC takes maybe half an hour. A few minutes per update if done regularly. There is little to none MPC-specific code left, so most files can just be copied from ffdshow.

is it possible to strip all decoders in mpc-hc (including DXVA ones), integate ffdshow in mpc-hc so there will be ffdshow settings page where internal filters are located and bundle ffdshow with mpc-hc?

It is possible to compile MPC without internal decoders. There is no need to 'integrate' ffdshow. Just install it and it will automagically get used when MPC has no internal filters enabled/included.

[STaRGaZeR]

Another bug bites the dust: wrong shadows in DVD subtitles fixed in r3363!

[Keiyakusha]

Originally Posted by clsid

It is possible to compile MPC without internal decoders. There is no need to 'integrate' ffdshow. Just install it and it will automagically get used when MPC has no internal filters enabled/included.

What I mean is some people was against MPC-HC without internal filters but I don't understand why do MPC-HC still needs them. Why not just drop and forget about them? In what way internal filters better than ffdshow? So I thought maybe some more integration will be fine for these people...

[STaRGaZeR]

@devs

I've fixed a problem with SSA subs. If a color is written as an integer instead of an hexadecimal and the value is negative, ffdshow outputs a greenish color while MPC outputs black, since a negative value doesn't make any sense here. With this patch ffdshow is consistent with VSFilter and MPC's internal subtitle renderer.

Patch: http://www.mediafire.com/?4wwhlztljlm
Build: http://www.mediafire.com/?lizgymxzyzh
SSA script for testing: http://www.mediafire.com/?gntnyw2tkwv

[tetsuo55]

Originally Posted by clsid

Exactly what do you think is messy? Updating the FFmpeg code in MPC takes maybe half an hour. A few minutes per update if done regularly. There is little to none MPC-specific code left, so most files can just be copied from ffdshow.

Several developers have tried to update ffmpeg but have been unable to do so.

You are most experienced in this area, could you write a detailed guide to updating? We could take over from there.

Originally Posted by Keiyakusha

What I mean is some people was against MPC-HC without internal filters but I don't understand why do MPC-HC still needs them. Why not just drop and forget about them? In what way internal filters better than ffdshow? So I thought maybe some more integration will be fine for these people...

MPC-HC is a standalone player that does not need any codecs or admin rights to work, this way it can be used on locked down environments.

[madshi]

Originally Posted by tetsuo55

MPC-HC is a standalone player that does not need any codecs or admin rights to work, this way it can be used on locked down environments.

I understand your goal, but I think you're realizing it the "wrong" way. Of course you can try compiling all needed filters into MPC, but I dare say that if you do that, you will always lose out somewhere because there are always going to be external (open or closed source) filters that will be better than MPC internal filters. Your current approach to MPC means that you're giving up on external filters in locked down environments.

IMHO the "proper" way to handle locked down environments would be to:

(1) Add a folder named "external filters" to the MPC root folder. Users could just drop in any external codec files there.
(2) MPC would enumerate through these files, load all of them via LoadLibrary, and call their "DllRegisterServer" routines during MPC initialization.
(3) To make (2) succeed even in locked down environments, MPC would hook all registry related APIs (by using Detours) and build up a temporary virtual registry storage (in RAM only). If you do this correctly, the DllRegisterServer method of most external filters should succeed, and the registration would be in your virtual registry storage. Also you should be able to fully use the external filters this way, in the same way, as if they were installed for real.

I think something like the approach above is the usual way to handle locked down environments. Instead of avoiding admin stuff, you emulate/virtualize it by hooking the APIs. Of course doing it this way is somewhat complicated. And it might fail with a few external filters (e.g. it might fail with filters that have some kind of copy protection). But I'm quite sure that it would work with by far most free external filters.

This logic would also have the added benefit that even in non-locked down environments MPC HC users could use many external filters without having to install them.

[tetsuo55]

Your description is very close to how MPC(-HC) already works.
The only difference is that we include the codecs internally as backups for when no codec is installed on the OS, or you have not selected a specific (registered or unregistered) codec.


To make MPC-HC behave like you have described all you have to do is uncheck the internal codecs, in that case they will only be used when there is no alternative. To get an unregistered codec working you select it from the external codec page.

For some features to work correctly we need the codecs to be internal (mostly DXVA-1)

I believe we should take a more modular approach and bring these two projects closer together.
It would be nice to have a single file for the player, codecs and postprocessing but on the other hand be able to install only 1 of the 3.

[madshi]

Originally Posted by tetsuo55

Your description is very close to how MPC(-HC) already works.

Keiyakusha asked why MPC HC still has internal filters. Your reply was that they're needed for locked-down environments. Now you're contradacting yourself. Either the internal filters are needed for locked-down environments or they're not. If they're not needed, your reply to Keiyakusha was incorrect. If they are needed, your reply to me is incorrect. I'm confused...