ffdshow tryouts project: Discussion & Development [Archive] - Page 228

rica

12th April 2010, 23:55

Renderer? Do you mean splitter? If so, this is not true. Enabling internal splitter will override haali splitter. Haali won't be loaded.

Yes it was a typo; isn't it very clear?

^^thats what I mean as well

I guess you were asking something, were you?

It seemed to me you were confusing splitters, so i gave the second link in my post.
The remaining is might be related with the only current configuration method of MPC-HC or Haali. (it's just the formal side of the content.)
But thanks anyway, i'll give it a go some time.

Keiyakusha

13th April 2010, 00:21

Yes it was a typo; isn't it very clear?
Yes, its very clear. So clear that normally no one will point that out, but some less experienced users may be confused. Anyway the main part of my post was about splitter loading.

rica

13th April 2010, 00:39

Anyway the main part of my post was about splitter loading.

Yes i know.
Let me switch off myself since it's not the right thread in which discusssing on unrelated stuff.

Thunderbolt8

13th April 2010, 18:39

ffdshow can downmix as well.

MPC menu -> Play -> Filters -> bottom filter -> there you can switch streams
well, ive tried it now with the internal splitter as well and also without reclock, but my problem still remains: ac3filter gets dropped or doesnt have any sound for the other tracks. so is this now a kind of bug? if so, what prog/filter is responsible?

swordsman

14th April 2010, 12:22

You can do it yourself, you know delphi's coding, the effort is not huge

I don't have time for now

Ok, I can do it myself, but what had I do if I don't
know what you changed in lffdecoder.h (which functions you add,
remove or rearranged)

fastplayer

14th April 2010, 12:36

Ok, I can do it myself, but what had I do if I don't
know what you changed in lffdecoder.h (which functions you add,
remove or rearranged)
...but you do know:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/IffDecoder.h?view=log

swordsman

15th April 2010, 08:54

Yes, I have this one.
I thought, that as Albain said he "added 3 methods to manipulate the audio/subtitle streams inside", the interface was changed.
Sorry, my mistake.:stupid:

clsid

15th April 2010, 14:35

well, ive tried it now with the internal splitter as well and also without reclock, but my problem still remains: ac3filter gets dropped or doesnt have any sound for the other tracks. so is this now a kind of bug? if so, what prog/filter is responsible?
Are you using S/PDIF output? If so, it is probably related to the fact that only one filter instance can have exclusive access to it.

Thunderbolt8

15th April 2010, 21:06

Are you using S/PDIF output? If so, it is probably related to the fact that only one filter instance can have exclusive access to it.no, just normal output.

hoborg

16th April 2010, 08:17

tetsuo55

16th April 2010, 10:01

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-prehravani-videa-na-ati-radeonech-hd-konecne-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

16th April 2010, 18:20

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

XhmikosR

16th April 2010, 20:13

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

http://pastebin.com/SMR7E2nz

SamuriHL

16th April 2010, 20:14

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

hoborg

17th April 2010, 13:34

Hi.
Devs with ATI, can you look on this sample (http://rapidshare.com/files/376893014/_aF_Gurren.Lagann.-.16.-.Zusammenfassung_E27E7284___1_-009.mkv)?
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

18th April 2010, 01:51

Any word on whether the lossless H.264 with DXVA (http://forum.doom9.org/showthread.php?p=1372277#post1372277) issue will be fixed?

DMD

18th April 2010, 13:13

ffdshow video is a problem or mpchc? :confused:

happens with 2 different releases of ffdshow:

pin SubPicure DVD navigator connected to pin MPC

ffdshow_rev2099_20080903_clsid_sse_icl10
http://www.allfreeportal.com/imghost2/thumbs/190149ffdshow_rev2099.png ('http://www.allfreeportal.com/imghost2/images/190149ffdshow_rev2099.png')

because the pin SubPicure MPC is not automatically linked?

one of the latest releases ffdshow_rev3356_20100411_sse_icl11
http://www.allfreeportal.com/imghost2/thumbs/28207ffdshow_rev3356.png ('http://www.allfreeportal.com/imghost2/images/28207ffdshow_rev3356.png')

ikarad

18th April 2010, 19:28

http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca95e79d7d0540e1e1
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

18th April 2010, 19:31

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

18th April 2010, 21:17

tetsuo55

18th April 2010, 21:34

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

18th April 2010, 21:46

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

18th April 2010, 22:45

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

18th April 2010, 23:26

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

Keiyakusha

18th April 2010, 23:38

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

19th April 2010, 04:09

@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

19th April 2010, 08:03

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.

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

19th April 2010, 09:23

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

19th April 2010, 10:40

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

19th April 2010, 11:00

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

tetsuo55

19th April 2010, 11:13

Good point.

I oversimplified my reply to Keiyakusha.

the correct reply is:

MPC-HC includes codecs to provide a backup for when the OS or user do not provide the required codec for the file. This also provides us with the opertunity to add some advanced features like DXVA1 support with subtitles.

By default the included codecs are prefered over external ones to prevent codec hell, improve the quality of feature requests and bug reports and to make the dxva codecs available by default.

[It's not only codecs though, the same is true for source filters, splitters(parser filters), subtitle renderer and audio-/video-renderers]

madshi

19th April 2010, 11:36

Ok, thanks, that makes more sense to me... :)

But then the question is: Instead of trying to compile ffdshow into MPC HC, wouldn't it make more sense to remove those parts from MPC HC which are duplicate to ffdshow and instead rely on ffdshow to take over that work? Maybe you could distribute the full standalone ffdshow package with MPC HC to make things easier for MPC HC users (don't know if that's possible legally, though). You could also ship other external filters with MPC HC, if you like them and their license allows that.

IMHO the focus of the MPC HC team should *not* be to replace all external filters with internal stuff. The focus instead should be to give MPC HC users the best possible experience out of the box. If there are external filters available that are better than the internal filters, MPC HC should consider using those external filters by default and (as said above) maybe even distribute them with MPC HC, if legally possible. That would IMHO be the best approach for MPC HC users, although maybe it could hurt the pride of MPC HC developers...

But this kind of discussion probably belongs into the MPC HC thread...

tetsuo55

19th April 2010, 11:39

what you describe is basically what codecpacks like k-lite and cccp do.

We do not intend to do any work on the codecs, the idea to make ffdshows ffmpeg implementation cleaner is to remove the worry about codecs from the mpc-hc team completley so they can focus on stuff that actually matters.

madshi

19th April 2010, 12:02

what you describe is basically what codecpacks like k-lite and cccp do.
In case you haven't noticed, MPC HC currently is a codecpack, too! ;) It's just a more limited codecpack, because it limits itself to only self-written codecs, some of which are good, some are less good, and many are duplicates to ffdshow.

We do not intend to do any work on the codecs, the idea to make ffdshows ffmpeg implementation cleaner is to remove the worry about codecs from the mpc-hc team completley so they can focus on stuff that actually matters.
So in other words: MPC HC will stay a codecpack, and since you don't plan to work on the codecs, it will only get more outdated over time. And to make things even worse, you plan to continue prefering most internal codecs of your codecpack over external codecs by default.

IMHO you should invest some thinking over whether you want MPC HC to be a codecpack or not. If yes, you should go the full mile and include all codecs (external or not) which you find best for any given format. If no, you should move all good MPC HC filters to an external package and make MPC HC a pure media player. Right now it's neither fish nor flesh. Maybe ffdshow could be extended to also home source filters? This way all good MPC HC filters could be moved to ffdshow. But of course that's only my 2 cents... :)

tetsuo55

19th April 2010, 12:16

In case you haven't noticed, MPC HC currently is a codecpack, too! ;) It's just a more limited codecpack, because it limits itself to only self-written codecs, some of which are good, some are less good, and many are duplicates to ffdshow.

So in other words: MPC HC will stay a codecpack, and since you don't plan to work on the codecs, it will only get more outdated over time. And to make things even worse, you plan to continue prefering most internal codecs of your codecpack over external codecs by default.

IMHO you should invest some thinking over whether you want MPC HC to be a codecpack or not. If yes, you should go the full mile and include all codecs (external or not) which you find best for any given format. If no, you should move all good MPC HC filters to an external package and make MPC HC a pure media player. Right now it's neither fish nor flesh. Maybe ffdshow could be extended to also home source filters? This way all good MPC HC filters could be moved to ffdshow. But of course that's only my 2 cents... :)The same is true for all players, we have no intention to change the current behaviour. We are also the filter upstream for many open and closed source projects so changes there could wreak havok downstream.

The only thing we are trying to do (and albain has already done most of the work here) is to use ffdshows libavcodec as the (maintainable) upstream for the ffmpeg codecs included in mpc-hc as the code is 99% the same but updating it twice takes double the effort.

(Also filter A is better than filter B will have to be proven with a scientific test, we simply use the best open source upstream which is ffmpeg)

clsid

19th April 2010, 12:20

MPC already has the functionality to load external filters without requiring those filters to be registered on the system (/filter command line parameter). That could be used to replace the internal decoders if the functionality is extended with:
1) An optional bundle of recommended external filters that can be installed (or extracted) in specific subdir of MPC location. This could contain stuff like ffdshow, haali, madflac, etc.
2) Ability to select in MPC options which of those filters should be used. Filters that are detected as registered on the system should be hidden (so that registered filters take precedence over the bundled filters). There should also be buttons for opening filter properties dialogs to configure their settings.
3) MPC should create a virtual registry for these filters to store their settings, like madshi suggested. This must be stored as a file, so settings are remembered. A file with initial recommended settings must be included in the filter bundle. The virtual registry file should be in some user readable format, so that it can be easily edited.

The above would allow MPC to make use of many excellent filters, while still being portable. The only difficult part is the virtual registry.

tetsuo55

19th April 2010, 12:22

I do think this change in filter loading behaviour is a good idea regardless of where and how we store the default codecs.

A patch that enables this (or at least feature request on the tracker) would be great.
(We have few devs, and those we have are not interested in changes like this, which is one of the reasons for upstreaming ffmpeg)

Maybe this creates some more clarity.

A dshow graph can be very complex and mpc-hc provides every required filter internally.
example:

player > source filter > splitter >
> video codec > video software postprocessor > video renderer (> hardware postprocess)
> Subtitle renderer > video renderer (either directly or through a 2nd surface)
> audio codec > audio software postprocessor > audio renderer (> hardware postprocess)

Thats about 10 filters (but currently mpc-hc does not offer postprocessing as both gabest and casimir seem to not like that, if they had both projects would have merged a long time ago)

clsid

19th April 2010, 13:02

Don't expect use to help out with the internal decoders of MPC. We don't have the manpower for it either, nor do we care much about it, since we obviously prefer to use ffdshow instead. I don't mind updating the ffmpeg stuff in MPC once in a while (when I have time), but that is all we can do for you.

tetsuo55

19th April 2010, 14:04

Yes you are right, we don't expect any help for our side of the story, mpc-hc devs will have to fix stuff in the ffdshow trunk.

ikarad

19th April 2010, 16:11

fastplayer

19th April 2010, 16:27

up! thanks
Read the first post of this thread, the FAQ, Google etc.

ikarad

19th April 2010, 16:42

Read the first post of this thread, the FAQ, Google etc.

It's not explained.
I don't speak about icl11 but about core2 in the name of file

hoborg

19th April 2010, 19:54

Hi devs.
I didnt think you will have some free time to look, but if you have - this sample (http://hobring.ic.cz/samples/mp4.AAC+AVC1_(1280x720@50fps).rar) (recorded by SAMSUNG camcodrder) doesnot work using FFDshow DXVA decoder - you will see only black screen if you will use MPC-HC MP4 splitter.
Becouse it is working with standart FFDshow decoder, it seems to be some kind of DXVA decoder issue.

It will start to work by using haali as the splitter or Cyberlink h.264 DXVA decoder, or by conversion in to MKV (MKV merge) - but that is not solution for me :(
Thanks.

kieranrk

19th April 2010, 20:19

In case you haven't noticed, MPC HC currently is a codecpack, too! ;)

Except without the conflicts, crashes and ancient ACM/VCM libraries that codec packs have. (also the hundreds of tray icons)

In my opinion the setup is fine. It's the right mix between standalone player and mplayer/vlc type app with support for hundreds of codecs and dozens of various options. Though there is some cruft like RealMedia and Quicktime support that's a bit dated.

Also internal DXVA is better than anything else for 1080p50 material.