Media Player Classic Home Cinema (MPC-HC) - DXVA!

[tetsuo55]

I wrote that because I found out it might not be the driver. Happens on another computer with Sandy Bridge I2600K integrated graphics (so yeah, still Intel gfx). DVD subtitles are displayed when a single VOB is played. It seems to me some component in the graph is bugged, or connection to Microsoft DVD navigator?

Also, there are frequent crashes only in this case, when DVD is played with subtitles set to be shown (but are not displayed). DMP file is created and MPC-HC offers me to take me to a page, but it never does.

I'd be happy to fill in a bug report, I just don't know what to do exactly.

GL
Hi.

I think the color problem you had has been fixed.
As far as forced subtitles not being enabled by default, that is something we should look into, if its just a setting somewhere it should be easy to fix.

[JEEB]

I hope so, he was interested in committing further to the project, I don't know if he was given back SVN rights or not but ideally he should be listed in the authors list as an active developer and should be invited to apply bug fixes for this along with BE.
Quite unfortunately, looking at the issue tracker responses he has made lately, he more or less shows no signs of wishing to co-operate with the MPC-HC project, and doesn't want to put out patches to review (nor sources for the binaries he posted on the issues he fixed for MPC-BE on the MPC-HC tracker the few times that happened). I do hope that the possible personal problems between certain people will heal with time, and enable more co-operation in the future, but right now I feel that the problems in communication have led to something that will take at least some time to untie. Also, if someone or some people want to work separately they should be free to do so (preferably within the rulesets set by the used software license).

In any case, the MPC-HC project is always ready to accept contributions from wherever they come from, and possible personal grudges or history of a single individual shouldn't and wouldn't play a role in the open way the project is handled with. There is no need for invitations to be given out or one to have such a thing to join the effort to develop MPC-HC to begin with (as such things do not exist), one can just come and contribute freely.

P.S.
SVN access was kept even after there were clear messages that there would be no further contributions to the project, not sure why people are talking as if access had been cut for a long time already (there was a very short period of time when the access was revoked, but this was reverted quite quickly as most people related to the project did not agree with such sudden reaction).

I do not know what the status with it is as of right now, but, as always, there is no real reason not to possibly give a person SVN access in the case of clear intent of contribution, such as posting of patches for review and such -- as well as clear effort to communicate and participate in the area of general development and code review of patches in the usual ways (trac/IRC for MPC-HC). Of course, one mustn't over-exaggerate the importance of SVN access. As some people as of late have shown, one can be a fine contributing member even without such. No SVN access does not equal "you are not welcome" or that your contribution wouldn't be noted.

[Amour]

[...]I guess you mixed x86 and x64 versions in your test. x86 version works and x64 never works.
Hu!
Perfectly right!
I tried the x86 version of 4808 because it was the file given to me to test in this thread.
All my other tests are made with x64 versions of all players.
[edit]
Bah, I found out I was testing with some x86 MPC-BE too... I should be more carefull. I didn't know it had an impact on the ability to play some files.

[Sylt]

@all, but especially to Aleksoid

Strategy in relation with the BE-Mod (http://sourceforge.net/apps/trac/mpc-hc/ticket/2284)

Aleksoid has announced that the source code of MPC-BE will be published later (with the first official BE Release).

I would hope that the Renderer Fixes and all the other internal fixes from Aleksoid will be backported. Every effort should be backported, except the interface changes of MPC-BE. XhmikosR, is that planned?

I would appreciate a response from Aleksoid why he no longer works for the MPC-HC project, although he has SVN Access?

What do you think about this post?

[Aleksoid1978]

@all, but especially to Aleksoid
What do you think about this post?

Now I'm only interested in the MPC-BE, to MPC-HC do not have any interest in. That's all.

As i say - MPC-HC has own team of developers, what you want from me ???

Now a only read trac - to see and try to fix some bug :)

[v0lt]

MPC-HC r4860
http://i.imgur.com/qUMVs.png

MPC-HC r4863
http://i.imgur.com/dbGX1.png

What was bad in the first version? :confused:

[Aleksoid1978]

@all, but especially to Aleksoid


And I have a question for the admins of the MPC-HC project - exactly how much has already been donations and how they were distributed. Judging from the log at the SF - only in May there were 33 contributions
https://sourceforge.net/project/project_donations.php?group_id=170561

What about this ??? :)

[ryrynz]

In any case, the MPC-HC project is always ready to accept contributions from wherever they come from, and possible personal grudges or history of a single individual shouldn't and wouldn't play a role in the open way the project is handled with. There is no need for invitations to be given out or one to have such a thing to join the effort to develop MPC-HC to begin with (as such things do not exist), one can just come and contribute freely.


I understand that an invitation is not required for contributing to an open source project indeed even less so if you have SVN access already, but there is still the matter of working as part of a team and this seems to be the major contributing factor here.

[vBm]

What was bad in the first version? :confused:

Boxes were confusing regular users. It looks like you can edit values by clicking on it and type the number while you can't do that.

Current behavior should be temporary until all of us figure something better.

[tetsuo55]

And I have a question for the admins of the MPC-HC project - exactly how much has already been donations and how they were distributed. Judging from the log at the SF - only in May there were 33 contributions
https://sourceforge.net/project/project_donations.php?group_id=170561

What about this ??? :)From the start of MPC-HC up till last month we had recieved about 500 euro in dontations.
Casimir has used some of this money to buy videocards so he could write the initial DXVA support (IIRC)

Other than that the money has not been used or distributed to anyone.

Donations only really happen when that list shows a small Paypal logo, when the logo is not visable no money was transfered.
Since changing the donation paypal we have recieved 8 real donations totalling about 30 euros.

[v0lt]

Boxes were confusing regular users. It looks like you can edit values by clicking on it and type the number while you can't do that.
It's not a big problem.

[Underground78]

It no longer appeared for a EVR Custom Pres a few builds ago but now it's fine. You can always check with Ctrl+J.
That's because I broke the renderer selection code, EVR CP was replaced by another renderer for a short time and this other renderer probably doesn't support the DXVA display.

[GrofLuigi]

Hi.

I think the color problem you had has been fixed.
As far as forced subtitles not being enabled by default, that is something we should look into, if its just a setting somewhere it should be easy to fix.

Mpc-hc x64 works fine on Win7 x64 (same computer). Everything works, even forced subs are displayed without user intervention (maybe not every time, I'll have to double check to be sure).

The .ini's are the same. I see that win7 has YUV12 output, while the other one RGB32 (the driver doesn't accept it?). But this driver is capable of displaying subs (proven by playing just the VOBs). So there is a glitch somewhere...

GL

[hajj_3]

this .mkv file crashes mpc-hc 1.6.2.4468 x64 and also MPC-HC.1.6.2.4867.x64: http://www.sendspace.com/file/ylsquo

it was a .mp4 file originally ripped from bbc iplayer using the application get_iplayer then i used mkvmerge to cut a section out. The original .mp4 file also crashes mpc-hc btw. VLC plays back both files perfectly.

Hope you can fix this bug.

Here is the original .mp4 file's mediainfo data:

General
Complete name : D:\recordings\The_One_Show_-_23_05_2012_b01j2ms2_default.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 565 MiB
Duration : 28mn 55s
Overall bit rate mode : Variable
Overall bit rate : 2 732 Kbps
Movie name : 23/05/2012
Album : The One Show
Album/Performer : BBC TV
Grouping : Factual,Arts, Culture & the Media
Performer : BBC One
Composer : BBC iPlayer
Genre : Factual
Recorded date : 2012-05-23T19:00:00+01:00
Tagged date : UTC 2012-05-24 22:00:13
Writing application : Lavf53.4.0
Copyright : © 2012 British Broadcasting Corporation, all rights reserved
Cover : Yes
Comment : Matt Baker and Alex Jones are joined by Dragons' Den star and businesswoman Hilary Devey.
stik : 10
©lyr : Matt Baker and Alex Jones are joined by Dragons' Den star and businesswoman Hilary Devey, plus Dan Snow discovers how Britain's new aircraft carriers are being built. / / EPISODE / http://www.bbc.co.uk/iplayer/episode/b01j2ms2/The_One_Show_23_05_2012/ / / SERIES / http://www.bbc.co.uk/programmes/b01j2ms2.html
desc : Matt Baker and Alex Jones are joined by Dragons' Den star and businesswoman Hilary Devey.
tvsh : The One Show
tven : b01j2ms2
tvnn : BBC One

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 6 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 28mn 55s
Bit rate mode : Variable
Bit rate : 2 631 Kbps
Maximum bit rate : 3 500 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.114
Stream size : 544 MiB (96%)

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : 40
Duration : 28mn 55s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Stream size : 19.6 MiB (3%)

[Aleksoid1978]

From the start of MPC-HC up till last month we had recieved about 500 euro in dontations.
Casimir has used some of this money to buy videocards so he could write the initial DXVA support (IIRC)

Other than that the money has not been used or distributed to anyone.

Donations only really happen when that list shows a small Paypal logo, when the logo is not visable no money was transfered.
Since changing the donation paypal we have recieved 8 real donations totalling about 30 euros.

Offered to buy Ati or Intel SB - then I can try to improve DXVA decoder on this hardware ??? What you think ???
:)

[Amour]

Offered to buy Ati or Intel SB - then I can try to improve DXVA decoder on this hardware ??? What you think ???
:)
Someone said:
"Now I'm only interested in the MPC-BE, to MPC-HC do not have any interest in. That's all."

Now, I'm sure you can change your mind, but the entry point for peace would be to make MPC-BE source-code public. Second point for peace would be to merge both projects with some kind of checkbox in the options of MPC to choose for the Old buttons or the New buttons, the Dark theme or the Light theme. Entry point of this cannot be made with money gifts to the other party.

[ryrynz]

We have yet to see even the original BE black skin make an appearance, what's the hold up with that?

[Octo-puss]

Someone said:
"Now I'm only interested in the MPC-BE, to MPC-HC do not have any interest in. That's all."

Now, I'm sure you can change your mind, but the entry point for peace would be to make MPC-BE source-code public. Second point for peace would be to merge both projects with some kind of checkbox in the options of MPC to choose for the Old buttons or the New buttons, the Dark theme or the Light theme. Entry point of this cannot be made with money gifts to the other party.
It smells of him seeing a change of getting a free videocard. Judging from his post in last weeks, he lost most of my respect tbh. He's just jerking us off.

[Mercury_22]

Since lately he is the only one with real contributions to the video decoders to me it seems more than a "common sense" for him to receive a video card instead of other but like Amour said at this point he has to make the first step

[ryrynz]

Probably not a big deal anyway, it's more than likely LAV will be integrated at some point.

[JEEB]

First of all, let's keep it civil, please :)

Secondly, I welcome any signs of development efforts, but it seems (relatively) clear right now that LAV Video's DXVA implementation is dealing better with the various quirks of current hardware than MPC-HC's. It's also under the same license, and the whole LAV project stems to minimize custom code or ways of compilation compared to vanilla ffmpeg and friends.

Thus if there would be a big effort put into development related to the splitters and decoders and such, it should in my humble opinion be aimed towards making an effort towards minimizing the duplicated code between various projects, and the streamlining of the whole MPC-HC as a project. This is of course not limited towards DXVA at all, but using a separate library (LAV Filters, possibly with some customizations related to how/where settings are saved and so forth) for splitting and decoding instead of a collection of older, custom internal filters would not only make the code base of MPC-HC smaller, but would also enable people to concentrate efforts on parsing/decoding in a single project instead of multiple. I have great respect towards Gabest, Casimir, Aleksoid and everyone else related to the development of these filters, but it just seems like there's no reason to keep multiple, very similar, solutions around (especially when all sides would gain by unifying effort).

Some people do of course like f.ex. Gabest's MPEG-PS/TS splitter, and those could be left in separate official projects/repositories, and people could tend to them if they so wish.

As for other things where effort should be put, there is the merging of useful/working parts of JanWillem32's changeset. We have demi` and Underground78, as well as Xhmikosr talking to him and working with him every now and then to see if the humongous changeset can be split and reviewed in parts. This has led to some changes related to finally getting the subtitle renderer fixed in certain ways being merged in lately, but this is just a small, miniscule piece of a very large, tedious task given the fact that JW32 hasn't been using a revision control system, and thus people have to go through the single big changeset, try to understand the changes and what they do/affect, communicate with JW32 regards them, and then separate them into related parts that can later be looked at again and finally committed. This goes for any bigger change, including the possible merging of any new skins. I just don't see anyone from the MPC-HC project wanting another "Kekkonen (http://media-cache-ec0.pinterest.com/upload/11610911509708850_Tz3wN6e3.jpg)" a la when beliyaal's rendering branch was merged to enter the commit history any more. I personally stumbled upon such trying to find out why there was an unused code path in the rendering code -- having a gigantic merge commit without specific comments related to it come up as where the change was born is just one of those cases where you have to just start waving your hands around in agony because you have no idea if that code is useful for some case, or just a simple leftover that could be removed.

Then, as for somewhat smaller problems, there's, for example, the quirks related to the custom code creating the DirectShow filter chains for playback. Right now if the RDP Redirection DShow filter or something similar is registered, you will not get a separate VSFilter into your filter chain (while using the standard ways of creating a DShow filter chain would get it there). You might not be using VSFilter yourself, but this just tells you that something is wrong in there. I see there is no issue on the new trac for this currently (I should write it down some time), but this problem has been around for quite a while now, and became clearly visible as the RDP Redirection filter was bundled with newer versions of Windows.

Anyways, this was just a couple of problems I happen to know, the code base of MPC/MPC-HC has been twingling and somewhat chaotically growing/changing during the last X years, and it needs love -- badly.

[ney2x]

TPAM +1 :)

Just integrate LAV Audio/Video/Filters/Splitter to MPC-HC.

[Aleksoid1978]

TPAM +1 :)

Just integrate LAV Audio/Video/Filters/Splitter to MPC-HC.

I agree - delete all internal filters and integrate LAV. That is all - all at once would be easier to live

And then everything will cease to hunt for source of MPC-BE. :)

[JEEB]

I agree - delete all internal filters and integrate LAV. That is all - all at once would be easier to live :)
What would be your idea of implementing such a change btw?

What I thought about would be checking if certain dynamic libraries that provide certain functions are available from the folder of the binary. If this is true, the filter chain creation part would give them priority and use them instead of whatever found on the user's general directshow system in case they are turned on in settings (a bit like the current 'external filters' functionality). As for settings, the MPC-HC LAV fork could save settings under MPC-HC's registry key, or settings could be negotiated after the library is generally loaded for check-up at start-up of the player with a possible settings API created together with nev (thus settings-related stuff could be kept completely on MPC-HC's side, possibly enabling an easier way to keep the "portable mode" functionality -- as well as possibly enabling MPC-HC to not have its own fork of LAV Filters, but to be able to use "vanilla" code base for its needs).

Anyways, this would need quite some work -- but I would guess it'd be worth it in the end (if nothing else, it would remove the need of MPC-HC itself having to care about many things not related to DirectShow playback itself :) )

Also, as far as your fork goes, everything found and deemed useful will be backported, there is no specific hunt for anything. This is standard procedure for any known fork we know of. I hope we can have a productive relationships both ways from now on, and that such things that happened on the issue tracker wouldn't happen again (no source for binaries when requested and so forth).

[SamuriHL]

LAV Filters already provides support for being loaded without being registered. Other players use private copies without having the filters registered. IMO, this is the cleanest way to do it. That way you don't mess with the user's existing filters, but, also isolate the player from those same potentially messy filters. You can already do this anyway. Create a filterless build of MPC-HC. Then in the external filters you just load the LAV filters and set to preferred. So, a potential way to do this is to detect that they've put LAV filters in a "filters" dir under the MPC-HC dir or some other known location, and then offer a "use lav filters" option in MPC-HC. I know that's much simpler sounding than it is to write, but, most of the code to do it should already be there.

[vood007]

I think the "one small exe to play them all" idea is MPC´s main argument. If this path is left MPC is just another GOM, KM or Potplayer... Make it stable, add some useful features and improve usability but dont try to make it something it never was meant to be. Its still Media Player >Classic<. Not talking about the missing menpower.

[SamuriHL]

I don't personally get the "one exe" mentality. What difference does it make if it's built into an exe or are sitting in a subdirectory of the install? What I'm suggesting is to externalize the existing filters, as well. So those that like the current setup could select a "Use MPC-HC filters" and it'd select the ones found in the "filters" sub dir and you'd get the same end user experience that you have today. But the idea is to make it a bit more extensible and "integrated" with more modern filters to allow the greatest flexibility. That way I can select the "Use LAV Filters" option and MPC-HC configures them and/or exposes configuration options specific to LAV like it does now for its own internal filters. Just a thought I guess.

[ageback]

S.Chinese update to rev 4886
https://dl.dropbox.com/u/132862/mplayerc.sc.rc.txt

[vBm]

In total of 70 tickets were closed for this version. Some of them were bug reports that were fixed and some were new feature requests that made their way to trunk. There are a lot of those that waren't on trac before they landed to trunk.

r4902 (https://sourceforge.net/apps/trac/mpc-hc/changeset/4902) has been tagged as stable revision for 1.6.2 version of MPC-HC.

Links to download pages and links to complete trunk log and changelog is here (https://sourceforge.net/apps/trac/mpc-hc/wiki/Changelog/1.6.2).


Thanks to all that contributed in any way.

[Amour]

Here is the same frame from three different players: VLC, SMPlayer and MPC-HC.
http://img52.imageshack.us/img52/4331/cariocavlc.png
http://img41.imageshack.us/img41/7524/cariocasmp.png
http://img713.imageshack.us/img713/3401/cariocampchc.png

Why are there human shadows for VLC and SMplayer but not for MPC-HC?
Is it possible to improve the display of this kind of frame even more or is it impossible to do better?

[v0lt]

Is it possible to improve the display of this kind of frame even more or is it impossible to do better?
Сan not be.

[wanezhiling]

I agree - delete all internal filters and integrate LAV. That is all - all at once would be easier to live

And then everything will cease to hunt for source of MPC-BE. :)
Can't wait to see the MPC-BE integrated LAV which can support bink video.

I can expect the BE project will be more popular in Asia as how current LAV is.

[clsid]

You don't need to wait for anything. It is already possible.

The K-Lite packs contain stable SVN builds of MPC-HC where all inferior internal filters have been removed. External filters are used automatically. You can choose between LAV/ffdshow for audio and video decoding. Choose between LAV/Haali as splitter for individual formats. madVR is included. A simple MediaInfo GUI is included. GraphStudioNext is included. All optional and fully customizable. You can install just what you want/need. Has a major update about once a month, with usually a few incremental updates in between.

[ajp_anton]

When advancing frame by frame, it will still leave the video paused where i started the frame by frame steps.
When hitting play afterwards, the audio will play from where it was paused, and the video will not play until the audio has catched up.
If stepping backwards, it will jump back all the way to where it was paused and step backwards from there. This is quite annoying, as it totally eliminates the ability to frame-step back and forth.

Also, frame-stepping only works well with madVR (EVR is weird when going backwards, and going forward may skip the first frame).

[Underground78]

The behavior is completely dependent of the renderer, decoder, etc. At worst frame stepping is implemented by finding the average frame duration and seeking to (current time +/- average frame duration).

I tested it with VMR9 and the internal filters. It always worked quite well when stepping forward. Stepping backward worked correctly with a Xvid sample and a H264 sample but it was kind of broken with a MPEG2 sample.

[ajp_anton]

Well, stepping only forward and only backward works fine, but stepping forward a few frames and then trying to go backward doesn't. Or well, it works, but the backwards step isn't taken from the current forward-stepped frame, but from the frame you paused on earlier.
I use LAV and madVR.

[Underground78]

I checked the code and it seems correct. The behavior was also correct when I tested but I need to try with madVR. Does this happen in both cases (stepping back then forward or the other way around)? Also does this happen with all files?

Edit: I can reproduce with madVR, it seems it only happens when stepping forward and then back.

Edit 2: I will have to discuss that with Madshi, I know where it goes wrong but I'm not sure if it's madVR or MPC-HC's fault. If you could open a ticket on MPC-HC's bug tracker and CC me there that would be perfect.

[DragonQ]

For some reason I can't get smooth playback on my HTPC (see sig) using MPC-HC. MediaPortal using EVR works fine but both EVR and MadVR have problems in MPC-HC. I'm using the latest versions of LAV Splitter, LAV Video Decoder and ffdshow Audio Decoder, plus the latest versions of MPC-HC, MadVR and nVidia drivers. LAV is set to DXVA2 Native (which means it uses software decoding with MadVR).

Basically it just behaves like the CPU and/or GPU aren't powerful enough - frames delayed or dropped every few seconds, unsmooth playback. However, CPU usage is minimal, GPU usage is minimal, the EVR graph is perfectly smooth and the files all play fine in both MediaPortal and also on other machines (all of which are also using MPC-HC + LAV + EVR/MadVR). The only indicator I have that I'm not going mental is the "presentation glitches" counter in MadVR, which keeps going up. It's hard to tell but I *think* playback is fine, or at least much better, when using EVR in a window (rather than full screen).

What could be causing this?? :(

[ajp_anton]

I checked the code and it seems correct. The behavior was also correct when I tested but I need to try with madVR. Does this happen in both cases (stepping back then forward or the other way around)? Also does this happen with all files?

Edit: I can reproduce with madVR, it seems it only happens when stepping forward and then back.

Edit 2: I will have to discuss that with Madshi, I know where it goes wrong but I'm not sure if it's madVR or MPC-HC's fault. If you could open a ticket on MPC-HC's bug tracker and CC me there that would be perfect.OK tested with VMR9 and it's working. Kinda, when changing direction I have to press that direction one extra time =).

This is my first time going to sourceforge without downloading something, and didn't know what a ticket is. No idea if I did it right, it should be ticket #2325 I think.

[xiulet]

with new oficial 1.6.2.4902 not macrovision fail with madvr http://forum.doom9.org/showthread.php?p=1576154#post1576154

with 4922, macrovision fail again , why?

thank you very much , ad1

[Underground78]

I don't think anything related to macrovision changed between those two revisions. Are you sure r4902 is really working?

[xiulet]

I don't think anything related to macrovision changed between those two revisions. Are you sure r4902 is really working?

yes, do you see the capture? on link, may be don't real but.... :)

dosen't matter

[Underground78]

What I meant is if you go back to r4902 is it still working?

[xiulet]

What I meant is if you go back to r4902 is it still working?

yes with r4902 not macrovision fail, there are problems with dvd menus that hangs up the mpc , but with others works well, and sometimes starting the same dvd the video is stuttering ...but it work's, not with 4922 and before 4902 with same 0.82.5madvr :)

and lavfilter and lavaudio 50.5 not lav video, i am using internal codecs for video.

but how i say , doesn't matter :)

thanks a lot

[kasper93]

"macrovision fail" depends almost on every filter in graph. And even what DVD is played. One thing is sure, it's bug related to madVR and that can't be fixed on mpc-hc side(maybe by using custom parser for DVD's instead of Microsoft dvd navigator but IDK.), so this discussion is pointless. Just search forum, everything has been told already.

[ajp_anton]

Somewhere between 4848 and 4872, the auto-zoom size was changed. Any reason for that? I liked the old slightly larger size a lot more.

[ryrynz]

Found the update for 1.6.2 listed on Guru3d, nice to see it getting some recognition. It's an achievement to have it listed on their page IMO, nice one guys.

[kasper93]

Found the update for 1.6.2 listed on Guru3d, nice to see it getting some recognition. It's an achievement to have it listed on their page IMO, nice one guys.

Well, users are not a problem, MPC-HC has users and will have. Problem is that MPC-HC needs more developers. Right now we have few people who are doing their best to keep this project alive and we should thank them.

[ryrynz]

Don't forget more awareness of the project can help bring developers in too as they are users also.

[aufkrawall]

What speaks against using LAV splitter and decoders?
Then devs could concentrate better on the real player.