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

[Anima123]

Aleksoid1978, what's the changelog of your test version?

I have tried your version and use LAV video decoder for RV40 decoding and it performes well. So I guess it's something related to the splitter.

[Aleksoid1978]

Aleksoid1978, what's the changelog of your test version?

I have tried your version and use LAV video decoder for RV40 decoding and it performes well. So I guess it's something related to the splitter.

I change MPC Video Decoder. Try with internal decoder.

p.s.
Karls Matroska RV9 Demo now play smooth.
http://www.mediafire.com/?9jfyr5sy0f9wp4p

[Anima123]

I tried with the internal decoder but it does not play smoothly with my RV40 files, mainly due to the known libav vector prediction errors in the RV decoder.

Too bad I have been dreaming of the perfect opensource RV decoder, it's still just one step that remains.

[Aleksoid1978]

I tried with the internal decoder but it does not play smoothly with my RV40 files, mainly due to the known libav vector prediction errors in the RV decoder.

Too bad I have been dreaming of the perfect opensource RV decoder, it's still just one step that remains.

Give me some sample RV40 to test.

[roytam1]

I tried with the internal decoder but it does not play smoothly with my RV40 files, mainly due to the known libav vector prediction errors in the RV decoder.

Too bad I have been dreaming of the perfect opensource RV decoder, it's still just one step that remains.

It is already fixed in ffmpeg/libav. LAV Splitter + LAV Video decoder which use libavformat and libavcodec *DO* play RV30/RV40 clips smoothly.

Give me some sample RV40 to test.

Private message sent.

[Reino]

I've done some testing too and I have to conclude, apart from the internal RealAudio Decoder's lag of support, it's the RealMedia Splitter in the first place that still has some issues.

RM[cook] (http://samples.mplayerhq.hu/real/AC-cook/mc_sich_ra8_44.rm): This one the RealMedia Splitter can handle well. It connects to LAV- and FFDShow Audio Decoder perfectly, but not with internal RealAudio Decoder. Roytam1 already mentioned that.

RM[atrac] (http://samples.mplayerhq.hu/real/AC-atrc/mc_sich_ra8_105.rm): The RealMedia Splitter fails immediately. No problem with the LAV Splitter.

RM[rv1,ac3] (http://samples.mplayerhq.hu/real/VC-RV10/thankyou.rm): Although AC3 is pretty unusual in a RM-container, the RealMedia Splitter connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. No support from the internal RealAudio Decoder. Again no problem with the LAV Splitter.

RM[rv2,cook] (http://samples.mplayerhq.hu/real/VC-RV20/Dolby7.5fps1.rm): The RealMedia Splitter together with the internal RealVideo Decoder can handle the video-stream, but the splitter fails with the cook audio-stream. It can't even connect with the FFDShow Audio Decoder. Again no problem with the LAV Splitter.

RM[rv3,cook] (http://samples.mplayerhq.hu/real/VC-RV30/Tom&Jerry-Cat%20Napping.rm): Initially the RealMedia Splitter handles both streams no problem. It connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. Only when you start seeking the audio becomes distorted (kind of echo).

RM[rv2,cook] (http://samples.mplayerhq.hu/real/RLG2_19.rm): Same as with RM[rv1,ac3], the RealMedia Splitter connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. No support from the internal RealAudio Decoder. Again no problem with the LAV Splitter.

RM[rv3,cook] (http://samples.mplayerhq.hu/real/RLV8_19.rm): Same.

RM[rv4,cook] (http://samples.mplayerhq.hu/real/VC-RV40/20040506.rm): Same.

So splitting atrac is still a mayor issue. Although splitting cook goes very well in a lot of cases, there are still some mayor issues. And of course at the moment internal RealAudio Decoder fails miserably.

[roytam1]

I've done some testing too and I have to conclude, apart from the internal RealAudio Decoder's lag of support, it's the RealMedia Splitter in the first place that still has some issues.

RM[cook] (http://samples.mplayerhq.hu/real/AC-cook/mc_sich_ra8_44.rm): This one the RealMedia Splitter can handle well. It connects to LAV- and FFDShow Audio Decoder perfectly, but not with internal RealAudio Decoder. Roytam1 already mentioned that.

RM[atrac] (http://samples.mplayerhq.hu/real/AC-atrc/mc_sich_ra8_105.rm): The RealMedia Splitter fails immediately. No problem with the LAV Splitter.

RM[rv1,ac3] (http://samples.mplayerhq.hu/real/VC-RV10/thankyou.rm): Although AC3 is pretty unusual in a RM-container, the RealMedia Splitter connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. No support from the internal RealAudio Decoder. Again no problem with the LAV Splitter.

RM[rv2,cook] (http://samples.mplayerhq.hu/real/VC-RV20/Dolby7.5fps1.rm): The RealMedia Splitter together with the internal RealVideo Decoder can handle the video-stream, but the splitter fails with the cook audio-stream. It can't even connect with the FFDShow Audio Decoder. Again no problem with the LAV Splitter.

RM[rv3,cook] (http://samples.mplayerhq.hu/real/VC-RV30/Tom&Jerry-Cat%20Napping.rm): Initially the RealMedia Splitter handles both streams no problem. It connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. Only when you start seeking the audio becomes distorted (kind of echo).

RM[rv2,cook] (http://samples.mplayerhq.hu/real/RLG2_19.rm): Same as with RM[rv1,ac3], the RealMedia Splitter connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. No support from the internal RealAudio Decoder. Again no problem with the LAV Splitter.

RM[rv3,cook] (http://samples.mplayerhq.hu/real/RLV8_19.rm): Same.

RM[rv4,cook] (http://samples.mplayerhq.hu/real/VC-RV40/20040506.rm): Same.

So splitting atrac is still a mayor issue. Although splitting cook goes very well in a lot of cases, there are still some mayor issues. And of course at the moment internal RealAudio Decoder fails miserably.

Not to mention the inability of splitting RALF stream.

[Aleksoid1978]

I've done some testing too and I have to conclude, apart from the internal RealAudio Decoder's lag of support, it's the RealMedia Splitter in the first place that still has some issues.

RM[cook] (http://samples.mplayerhq.hu/real/AC-cook/mc_sich_ra8_44.rm): This one the RealMedia Splitter can handle well. It connects to LAV- and FFDShow Audio Decoder perfectly, but not with internal RealAudio Decoder. Roytam1 already mentioned that.

RM[atrac] (http://samples.mplayerhq.hu/real/AC-atrc/mc_sich_ra8_105.rm): The RealMedia Splitter fails immediately. No problem with the LAV Splitter.

RM[rv1,ac3] (http://samples.mplayerhq.hu/real/VC-RV10/thankyou.rm): Although AC3 is pretty unusual in a RM-container, the RealMedia Splitter connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. No support from the internal RealAudio Decoder. Again no problem with the LAV Splitter.

RM[rv2,cook] (http://samples.mplayerhq.hu/real/VC-RV20/Dolby7.5fps1.rm): The RealMedia Splitter together with the internal RealVideo Decoder can handle the video-stream, but the splitter fails with the cook audio-stream. It can't even connect with the FFDShow Audio Decoder. Again no problem with the LAV Splitter.

RM[rv3,cook] (http://samples.mplayerhq.hu/real/VC-RV30/Tom&Jerry-Cat%20Napping.rm): Initially the RealMedia Splitter handles both streams no problem. It connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. Only when you start seeking the audio becomes distorted (kind of echo).

RM[rv2,cook] (http://samples.mplayerhq.hu/real/RLG2_19.rm): Same as with RM[rv1,ac3], the RealMedia Splitter connects with the internal RealVideo Decoder and the FFDShow Audio Decoder. No support from the internal RealAudio Decoder. Again no problem with the LAV Splitter.

RM[rv3,cook] (http://samples.mplayerhq.hu/real/RLV8_19.rm): Same.

RM[rv4,cook] (http://samples.mplayerhq.hu/real/VC-RV40/20040506.rm): Same.

So splitting atrac is still a mayor issue. Although splitting cook goes very well in a lot of cases, there are still some mayor issues. And of course at the moment internal RealAudio Decoder fails miserably.

Internal RealAudio & RealVideo Decoder - decode data through RealMedia .dll

Now i add decode RealVideo through libav - MPC Video Decoder. RealAudio - later.

[Reino]

Oh, I thought RealMedia.dll wasn't needed for the internal RealAudio Decoder anymore either. Sorry, my bad.

[Midzuki]

It is already fixed in ffmpeg/libav.

LAV Splitter + LAV Video decoder which use libavformat and libavcodec *DO* play RV30/RV40 clips smoothly.

On a very-old "monocore" Pentium 4, that's not true --- even with a 352x288 .rmvb file. :rolleyes:

The MPC-HC RealMedia filters do the job well though. :cool:

[nevcairiel]

Who cares about a old pentium 4? :p
Rather have playback without installing the Real spyware :)

[Midzuki]

In my book there are N0 good excuses for inefficient coding. :D

[nevcairiel]

Your book came with a Pentium4, its outdated! :p

[Midzuki]

Your book came with a Pentium4, its outdated! :p

Very-outdated indeed, it was written when I used to program for punch cards in ALGOL and FORTRAN. :rolleyes:

End-of-discussion, since I already know I am not the one who's gonna make you change your mind. ;)

[nevcairiel]

There is no mind to change, i'm not the one who writes those decoders, i just use them. :p
I just don't think a P4 is a system to still consider important. .)

[Midzuki]

...
I just don't think a P4 is a system to still consider important. .)

At least a Pentium 4 can/should be used for determining how fast or how slow a decoder R-E-A-L-L-Y is ;)

[Dark Eiri]

At least a Pentium 4 can/should be used for determining how fast or how slow a decoder R-E-A-L-L-Y is ;)

Not really. You could as well use a 486DX to say everything is slow.

[Midzuki]

Not really. You could as well use a 486DX to say everything is slow.

As I said above, the MPC RM Splitter + the original RealNetworks DLLs play a low-res RV40 clip smoothly on a Pentium 4,

whereas the equivalent open-source decoders do not.

These are the FACTS.

But if you prefer to classify these facts as "irrelevant",

that's an entirely-different story -.-

[Dark Eiri]

I was kidding. Chill out.

[Midzuki]

I see. :rolleyes:

[roytam1]

On a very-old "monocore" Pentium 4, that's not true --- even with a 352x288 .rmvb file. :rolleyes:

The MPC-HC RealMedia filters do the job well though. :cool:

Sorry, what did you say?
http://i.imgur.com/Zbm4ul.png (http://imgur.com/Zbm4u)

[ryrynz]

40FPS! Woot. It's a 12 year old architecture! Anything in computers over 10 years old is ancient and should be retired unless of course you don't plan on updating your system much at all.
Move with the times :D Core 2's are cheap and perform well, I recommend getting one, once you've sold your tired old P4 you likely would have only spent about $50 US.

Anyway, nobody will optimize for anything that old, just upgrade already, it's LONG overdue. Get more performance and save power to boot.

[roytam1]

40FPS! Woot. It's a 12 year old architecture! Anything in computers over 10 years old is ancient and should be retired unless of course you don't plan on updating your system much at all.
Move with the times :D Core 2's are cheap and perform well, I recommend getting one, once you've sold your tired old P4 you likely would have only spent about $50 US.

Anyway, nobody will optimize for anything that old, just upgrade already, it's LONG overdue. Get more performance and save power to boot.

I don't use it but I manage such PCs. The organization doesn't have money to replace them.

[ryrynz]

Oh, companies are a whole 'nother thing.. Some just hate spending money on anything. I feel for ya ;)

[ryrynz]

Not really. You could as well use a 486DX to say everything is slow.

If you're gonna use a 486 as an example of slow ideally you'd want to mention the 486SX which had a defective and disabled FPU. :)

[CruNcher]

Who cares about a old pentium 4? :p
Rather have playback without installing the Real spyware :)

ehh you only need to take certain engine components create a wrapper and voila @ least that's how all the asian isvs doing it including Cyberlink and Arcsoft :)

The same in terms of Performance compared to the Native decoders could also bee said of VP6/7 the original decoders without any PP active are also slightly faster then libavcodecs reverse engineering @ least in Lav Video and in terms of VP6 Libavcodec supports no Interlaced Bitstreams also their is a bug in the WMV3 decoder that isn't in Microsofts Decoder though most of these are very rare use cases :)

Sorry, what did you say?
http://i.imgur.com/Zbm4ul.png (http://imgur.com/Zbm4u)

you also have to compare complexity generally Anime guys use very heavy complexity for whatever reason they always overdo it trying to squeeze out every quality they can and in the end they most probably will never recognize the difference, but they are happy to have pushed every knoob @ the maximum and load up the decoder side as much as possible ;)
Also you test on the Null Renderer the Rendering also causes overhead as well as the Audio Decoding so 40 fps you gonna get on this system under the best conditions with 0 visual output, so you simulating a encoding case not a on screen Decoding case, maybe even with scaling going on (Software,GPU) which is gonna load the CPU/GPU much more then your current result ;)
What you are currently doing btw is exactly what Apple did when deciding for their Decoding complexity to reach as much Apple Systems as possible (every bit of quality is useless if the content cant reach the maximum amount of users in your ecosystem) in the early days :)
Though Anime guys don't think in Quality/Complexity terms unless they are forced too by for example DXVA limitations ;)

[roytam1]

ehh you only need to take certain engine components create a wrapper and voila @ least that's how all the asian isvs doing it including Cyberlink and Arcsoft :)

The same in terms of Performance compared to the Native decoders could also bee said of VP6/7 the original decoders without any PP active are also slightly faster then libavcodecs reverse engineering @ least in Lav Video and in terms of VP6 Libavcodec supports no Interlaced Bitstreams also their is a bug in the WMV3 decoder that isn't in Microsofts Decoder though most of these are very rare use cases :)



you also have to compare complexity generally Anime guys use very heavy complexity for whatever reason they always overdo it trying to squeeze out every quality they can and in the end they most probably will never recognize the difference, but they are happy to have pushed every knoob @ the maximum and load up the decoder side as much as possible ;)
Also you test on the Null Renderer the Rendering also causes overhead as well as the Audio Decoding so 40 fps you gonna get on this system under the best conditions with 0 visual output, so you simulating a encoding case not a on screen Decoding case, maybe even with scaling going on (Software,GPU) which is gonna load the CPU/GPU much more then your current result ;)
What you are currently doing btw is exactly what Apple did when deciding for their Decoding complexity to reach as much Apple Systems as possible (every bit of quality is useless if the content cant reach the maximum amount of users in your ecosystem) in the early days :)
Though Anime guys don't think in Quality/Complexity terms unless they are forced too by for example DXVA limitations ;)

actually they break DXVA limitations as they use 10-bit encoding now.

for that machine, yes it did drop frames because of the weak Riva TNT2 32MB.

[Midzuki]

...

for that machine, yes it did drop frames

because of the weak Riva TNT2 32MB.

A GeForce 5200 with 128MB does not make things better, BUT maybe a GeForce 5500 with 256MB will do. :)

------------

L.E.: As I think the current off-topic~ness has gone on long enough, I'd like to stress that:

1) there is no problem if the ffmpeg/libav teams or anyone else do not care about obsolete CPUs :)

2) there is no problem in admitting the ffmpeg/libav RM decoders are not as good as they could be ;)

3) the "official" RealMedia decoders are not fast, they are slow already :(

4) As a matter of fact, RealVideo sucks :p

Die, RealMedia, die! :D

[clsid]

RV4 decoding with LAV should be a few % faster when Nev updates his FFmpeg clone. There were some optimizations added last week.

My CPU does 2000fps on a 720x348 vid. And it isn't even overclocked. Really time to update your puny little P4.

[mindbomb]

its not completely irrelevant to think about pentium 4, since relatively new cpus like the intel atom n570 and amd c50 are basically like pentium 4s in performance.

[Midzuki]

Really time to update your puny little P4.

And I will.

However there still is no point in ignoring that (lib)avcodec not always is the fastest toy on the block. :rolleyes:

[Px]

A GeForce 5200 with 128MB does not make things better, BUT maybe a GeForce 5500 with 256MB will do. :)
20 MHz GPU speed difference can't make miracle ;)

[CruNcher]

RV4 decoding with LAV should be a few % faster when Nev updates his FFmpeg clone. There were some optimizations added last week.

My CPU does 2000fps on a 720x348 vid. And it isn't even overclocked. Really time to update your puny little P4.

the same when ffdshow and mpc-hc update their clones tsts "his FFmpeg based Directshow Decoder" wouldn't have been so rude ;)

[clsid]

FYI "clone" is a term commonly used when working with GIT repositories...

[alexins]

Yes, the internal video decoder is like that... But for that purpose, you may try the BE Mod version, its internal decoder has many more options (it's also available as a standalone filter).

In this regard I'd like to report a bug related to this decoder, although this might not be the right place to do that.
Long story short - when forcing RGB output, only half of the screen is displayed with the desired levels. For example, when playing 10bit H.264 video (which in my case is full range), and I set the input and output levels correctly, only the top half of the image is displayed as it should :). This occurs with both EVR and madVR.
http://img684.imageshack.us/img684/5209/bug10b.th.png (http://img684.imageshack.us/img684/5209/bug10b.png)

But with 8bit videos it's the other way around - they are displayed as full range by default, so for TV range videos, that would be problematic (again, only the top half of the image is displayed as desired). This problem occurs only with madVR, with EVR it's OK.
http://img685.imageshack.us/img685/3785/bug8b.th.png (http://img685.imageshack.us/img685/3785/bug8b.png)

Both examples are with 4:4:4 samples, but the situation is the same with 4:2:0 ones.

Check how it works in BE Mod r.4055. (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-6-1-4055.html)

[dzy]

Is there a way to rotate the video? For videos shot by phone cameras.

[Snowknight26]

Assuming the renderer allows it, Alt+1 or Alt+3 on the number pad.

[kasper93]

http://dl.dropbox.com/u/16282309/MPC-HC/track.order.png
Track order text boxes are disabled and useless, because we have track preferences in playback options, so maybe it should be removed from MpegSplitter options window?

BTW. updated Polish translation on trac, #1579 It could wait for more changes, but decision is yours :)

[v0lt]

@kasper93

If Change track order disabled, when tracks are sorted by ID.

If Change track order enabled and MpegSplitter is internal, when tracks are sorted by MPC-HC->Options->Playback->Default track preference.

If Change track order enabled and MpegSplitter is external, when tracks are sorted by the fields located below.

[rotflol]

I don't know if this is an appropriate venue, but I'd like to thank everyone involved in the development of MPC-HC. You're doing great work, keep it up. Thank you very much.

[v0lt]

Thank you!

[Reino]

I've done some testing too and I have to conclude, apart from the internal RealAudio Decoder's lag of support, it's the RealMedia Splitter in the first place that still has some issues.
...
RM[atrac] (http://samples.mplayerhq.hu/real/AC-atrc/mc_sich_ra8_105.rm): The RealMedia Splitter fails immediately. No problem with the LAV Splitter.
...
RM[rv2,cook] (http://samples.mplayerhq.hu/real/VC-RV20/Dolby7.5fps1.rm): The RealMedia Splitter together with the internal RealVideo Decoder can handle the video-stream, but the splitter fails with the cook audio-stream. It can't even connect with the FFDShow Audio Decoder. Again no problem with the LAV Splitter.
...I just noticed, with a freshly downloaded MPC-HC, all the issues have been fixed! Nice! At least with all samples all 3 internal filters are working perfectly, but these 2 samples are the only ones left where the RealMedia Splitter desperately wants the internal RealAudio Decoder. When I disable the internal RealAudio Decoder and force it to use the FFDShow Audio Decoder via External Filters, I still end up with a low merit MPC Audio Decoder. Just thought I'd mention.

[Aleksoid1978]

I just noticed, with a freshly downloaded MPC-HC, all the issues have been fixed! Nice! At least with all samples all 3 internal filters are working perfectly, but these 2 samples are the only ones left where the RealMedia Splitter desperately wants the internal RealAudio Decoder. When I disable the internal RealAudio Decoder and force it to use the FFDShow Audio Decoder via External Filters, I still end up with a low merit MPC Audio Decoder. Just thought I'd mention.

It's a FFdshow decoder bug. LAV fixed this(issue in Real Header parser).

[ryrynz]

Would anyone else find the seamless playback feature as sported by Potplayer useful? Ideally I'd like something that would work with LAV Filters.
I find it to be a really nice feature when running demanding Avisynth scripts where the delay processing the next file in the folder or playlist can take quite some time.

[Remicade]

There is a difference between Enable Pre-resize pixel shaders and Post ?

[cremor]

Hi,

I have a problem with 1.6.0.4014. It seems like the internal MKV splitter doesn't like files that are cleaned with mkclean (http://www.matroska.org/downloads/mkclean.html). Opening such cleaned files takes a very long time, especially for larger files or when using an external USB drive. It seems like MPC is seeking through the whole file before it starts playback (the drive is under full usage during that time).
Disabling the internal MKV splitter and using LAV splitter solves the problem.

I'd upload a sample, but since this issue can only be noticed with large files, the uploading would take forever with 0,5 MBit upload bandwith :(
But it should be easy to reproduce with a file created by mkclean, all files I tested were affected.

PS: The links in the first post, that should lead to places where bugs or new features can be reported, just lead to "Error - The Tracker has been disabled for this group".

[fairchild]

There is a difference between Enable Pre-resize pixel shaders and Post ?

Yes, generally you want to use pre-resize for functions such as the YV12 chroma upsampling shader (not sure which others), and you want to use the post-resise for things like sharpening (otherwise you oversharpen the image since in essence it would be sharpening the original size of the video then when you resize it would be sharpening again through the resizing done by the renderer)

[Ronin-7]

Is there any way to clean out the registry settings/remaining files of MPC-HC after uninstalling it ? I updated to the current version and lost all audio output.

What happened exactly was I removed old version then tried the v1.6.0.4014 x64 build but then uninstalled that as I wanted to keep using madVR so I installed the v1.6.0.4014 x32 version and after that audio no longer works, all the settings are default and all other players like VLC, Potplayer, XBMC work fine. I also tried one of the newer nightly 4048 builds and the problem persists so my guess is some registry setting perhaps ?

[Thunderbolt8]

got the problem that my MPC-HC remains in the foreground all the time, even in window mode. to access other windows, I need to minimize mpc first each time which is very annoying. it hasnt done that before I reinstalled my windows. (cant tell whether this is due to mpc-hc or maybe because of madvr or something else, dunno)

[v0lt]

@Ronin-7
mpc-hc.exe /reset

I had a similar problem when Windows is blocking the sound in the player (I tested the code). Here is another copy of the player (running from another folder) worked. After restarting Windows, the problem disappears.