Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
19th April 2010, 11:13 | #11381 | Link |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
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]
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC Last edited by tetsuo55; 19th April 2010 at 11:16. |
19th April 2010, 11:36 | #11382 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
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... |
19th April 2010, 11:39 | #11383 | Link |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
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.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC |
19th April 2010, 12:02 | #11384 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
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... |
||
19th April 2010, 12:16 | #11385 | Link | |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
Quote:
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)
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC Last edited by tetsuo55; 19th April 2010 at 12:20. |
|
19th April 2010, 12:20 | #11386 | Link |
*****
Join Date: Feb 2005
Posts: 5,643
|
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.
__________________
MPC-HC 2.1.7.2 |
19th April 2010, 12:22 | #11387 | Link |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
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)
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC Last edited by tetsuo55; 19th April 2010 at 12:40. |
19th April 2010, 13:02 | #11388 | Link |
*****
Join Date: Feb 2005
Posts: 5,643
|
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.
__________________
MPC-HC 2.1.7.2 |
19th April 2010, 14:04 | #11389 | Link |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
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.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC |
19th April 2010, 16:11 | #11390 | Link | |
Registered User
Join Date: Apr 2008
Posts: 546
|
Quote:
|
|
19th April 2010, 19:54 | #11393 | Link |
Registered User
Join Date: Nov 2008
Posts: 454
|
Hi devs.
I didnt think you will have some free time to look, but if you have - this sample (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.
__________________
Working machine: Win10x64 + Intel Skull Canyon My HTPC. How to start with Bitcoin |
19th April 2010, 20:19 | #11394 | Link | |
Registered User
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
|
Quote:
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. |
|
19th April 2010, 20:51 | #11395 | Link |
*****
Join Date: Feb 2005
Posts: 5,643
|
That is just nonsense. A good codec pack will give you LESS problems than MPC-HC with all of its internal filters enabled.
__________________
MPC-HC 2.1.7.2 |
19th April 2010, 21:46 | #11398 | Link |
*****
Join Date: Feb 2005
Posts: 5,643
|
Were you responding to me? If so, there are a few examples on MPC's bugtracker, like the mod16 bug, amr issues. Those bugs do not exist in ffdshow.
__________________
MPC-HC 2.1.7.2 |
19th April 2010, 21:53 | #11399 | Link |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
afaik those exist because our version of ffmpeg is broken, hence why i rather do a straight copy from ffdshow's one.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC |
19th April 2010, 22:18 | #11400 | Link | |
Registered User
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
|
Quote:
The various copying between GPU and PC memory isn't suitable for high-bandwidth 1080p50. |
|
Tags |
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl |
Thread Tools | Search this Thread |
Display Modes | |
|
|