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

[Keiyakusha]

MPC-HTPC
Sorry but which advice you talking about? I saw what he says about .avsi that calls some plugins. I checked that and figured out that the problem in non-standard avisynth plugins that called through .avsi to be autoloaded. I can't remove them and can't rename anything because i'm using (or beter to say I'm trying to use) it. My mpc-hc version is r2474
EDIT: also my avisynth is AviSynth_260_100816
EDIT2: i see, if other programs also needs to fix something, this means the answer to my question: there is no working solution for now. Thanks. I hopes this doesn't means that every affected avisynth plugin should be fixed because this will never happens.

[p0w3rh0u5e]

I've tested a few older builds and the trouble with avisynth begun between builds 2372 and 2385.

[MPC-HTPC]

Sorry Keiyakusha,
but since you really use AviSynth then it is not an option for you to remove or rename the plugin-folder. The only solution would be, that AviSynth will be updated in order to forbid loading DLLs from the current working directory, at least this is what I assume. In your case, like you said, there is no working solution now, at least I am not aware of any.
For everybody else who does not need AviSynth, the easiest solution would be to renmae AviSynth's plugin-folder.


@ p0w3rh0u5e
Like I wrote one post above yours, this behavior is intended and is caused by Rev2374:

"Remove the current working directory from the DLL search path in order to avoid the DLL preloading vulnerability (Ticket #694)"

For further information, why this fix by the MPC-HC devs is important, please refer to this blog entry:
http://blog.trendmicro.com/new-dll-vulnerability-exploited-in-the-wild/

[p0w3rh0u5e]

Like I wrote one post above yours, this behavior is intended and is caused by Rev2374:

Dooh.. i must have overseen your posts, sorry.
Thank you very much for clarifying this for me (again). :thanks:

[MPC-HTPC]

You're welcome! :)

[Mangix]

bug: autochange doesn't work with madVR anymore.

[MPC-HTPC]

Please open a ticket for that bug on the tracker, otherwise the bug may get lost in this thread and no dev will pay attention to it! Furthermore the devs can contact you then and have the possibility to ask for further information in order to reproduce the bug. Anyhow your bug description is lacking a lot of further information like the version you have used and so on...

How to report a bug (http://sourceforge.net/apps/trac/mpc-hc/wiki/Bugs_-_Reporting)

Open a new ticket (http://sourceforge.net/apps/trac/mpc-hc/newticket)

[Keiyakusha]

Mangix
If you mean refrash rate change, as I understand from madvr thread this is a bug in madvr but madshi won't look into that because he anyway want to implement his own autochange. You can roll back to previous madvr version (or even two) to see if it works for you or not.

[Mangix]

Mangix
If you mean refrash rate change, as I understand from madvr thread this is a bug in madvr but madshi won't look into that because he anyway want to implement his own autochange. You can roll back to previous madvr version (or even two) to see if it works for you or not.

figured as much since EVR still changes refresh rate. oh well i guess i'll manually change them for now.

[Tom Keller]

I can't remove them and can't rename anything because i'm using (or beter to say I'm trying to use) it.
But since it's the avisynth autoloading feature causing that, you could simply take the avsi script, comment these lines out and load those plugins manually when needed...

[burfadel]

Try the following:

1. Copy the following into notepad, save as Filter Cache.reg (or whatever you prefer)

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\Microsoft\Multimedia\ActiveMovie\Filter Cache]


2. Double click, and accept adding it to registry. Even if this doesn't help the problem, it doesn't hurt as it flushes the cache and Windows rebuilds it. I found this as a solution to a non-related issue I was having (apparently it can affect many different things)

3. Run the following from the command prompt:
sfc /scannow
Again, probably not related but it doesn't hurt to run it! It does leave some junk files on the computer, but these don't hurt anything. Microsoft should really fix that. If you haven't run that before, its possible that errors will be found... (especially on older installs)!

4. Download the following Windows update:
http://www.mediafire.com/?m9adgzmcv2gyj4l

That update updates the files kernel32.dll and kernelbase.dll to versions 6.1.7600.20778

Can't guarantee it will resolve the issue, but it is an August 2010 hotfix that covers kernelbase.dll, its worth a try :)

[v0lt]

I need Help!

sample - http://samples.mplayerhq.hu/A-codecs/qtfl32/vb3.mov

\src\filters\parser\MP4Splitter\AP4\Core\Ap4Atom.h
...
const AP4_Atom::Type AP4_ATOM_TYPE_WAVE = AP4_ATOM_TYPE('w','a','v','e');
const AP4_Atom::Type AP4_ATOM_TYPE_ENDA = AP4_ATOM_TYPE('e','n','d','a');
const AP4_Atom::Type AP4_ATOM_TYPE_CMOV = AP4_ATOM_TYPE('c','m','o','v');
...

\filters\parser\MP4Splitter\AP4\Core\Ap4SampleEntry.cpp
...
AP4_AudioSampleEntry::AP4_AudioSampleEntry(AP4_Atom::Type format,
AP4_Size size,
AP4_ByteStream& stream,
AP4_AtomFactory& atom_factory) :
AP4_MpegSampleEntry(format, size)
{
// read fields
ReadFields(stream);

// must be called after m_DescriptionVersion was already set
AP4_Size fields_size = GetFieldsSize();

// read children atoms (ex: esds and maybe others)
ReadChildren(atom_factory, stream, size-AP4_ATOM_HEADER_SIZE-fields_size);

//AP4_ATOM_TYPE_ENDA
AP4_Atom* child;
if(child = GetChild(AP4_ATOM_TYPE_WAVE)) {
if(AP4_ContainerAtom* wave = dynamic_cast<AP4_ContainerAtom*>(child)) {
child = wave->GetChild(AP4_ATOM_TYPE_ENDA);
}
}
if (child) {
AP4_UI16 d;
if (child->GetSize()-child->GetHeaderSize() == 2) {
d = ???//How to read two bytes from the atom 'enda'?
}
}
}
...
How to read two bytes from the atom 'enda'?

[Aleksoid1978]

http://pastebin.com/Guw6ScKz

Here's another possible security vulnerability bug(buffer overflow exploit) in MPC-HC, I don't know if it affects the latest builds or not, might want to check it and see if it is affected.

exploit don't work - MPC-HC open as avi, but no play and no error.

[NikosD]

Tried the video on a PC with a GeForce G 105M (actually VP3) and it still played at ~47fps...

Have you tried PotPlayer DXVA?

I got ~55fps like PDVD10 with UVD 2.2, of course

[namaiki]

Have you tried PotPlayer DXVA?

Trying it, it plays ~51fps. Dunno what filters it uses.

[NikosD]

Trying it, it plays ~51fps. Dunno what filters it uses.

Me either.
I do know the quality of this particular DXVA implementation is better than the internal CPU codec of the program!

[namaiki]

quality?

[NikosD]

Yes, the image is better. The CPU mode looks like it needs anti-aliasing.

[6205]

PotPlayer and quality? My ass :) Another Korean crap like SPlayer...

[tetsuo55]

PotPlayer and quality? My ass :) Another Korean crap like SPlayer...Keep your comments constructive, if you can prove any of those claims and they are on topic please do so in a scientific and gentlemanlike manner.

[Underground78]

Well, the "scientific" answer is probably that output should normally be the same with all decoders ... Of course, it could be some post-processing but claiming decoder X has better quality than decoder Y makes no sense.

[namaiki]

NikosD, try and confirm which video renderers (and subsequently which resizing algorithms) are being automatically selected by PotPlayer for you in DXVA and software decoding modes.

[NikosD]

PotPlayer and quality? My ass :) Another Korean crap like SPlayer...

You present yourself as a number "6205" and usually I don't reply to numbers but if you read my previous post, I write that DXVA mode has more quality than CPU mode.
That means that CPU mode has such low quality - in this particular test - that it can be overtaken by DXVA. Wake up!

[NikosD]

NikosD, try and confirm which video renderers (and subsequently which resizing algorithms) are being automatically selected by PotPlayer for you in DXVA and software decoding modes.

The discussion about quality is endless and almost purely subjective.
Let's keep it to raw performance numbers.

[NikosD]

Well, the "scientific" answer is probably that output should normally be the same with all decoders ... Of course, it could be some post-processing but claiming decoder X has better quality than decoder Y makes no sense.

Actually it's quite the opposite. It's almost impossible to find the exact same output with "same" decoders. Only if they share same code and run at the exact same enviroment.

[MPC-HTPC]

@ Underground78

Could you figure something out with the MPEG-TS sample and the crash in MPC-HC when rapidly seeking? Was Dr.Memory working for you?

[Underground78]

@ Underground78

Could you figure something out with the MPEG-TS sample and the crash in MPC-HC when rapidly seeking? Was Dr.Memory working for you?

We tried to understand what was going on with Tetsuo using VS2010 debugger but I don't know the source code enough to find what is going wrong ...

There is in fact an assert which fails in BaseSplitterFileEx.cpp because of a value returned by BitRead (BaseSplitterFile.cpp) but we don't know why such a value appears when seeking rapidly and not when playing normally ... :(

[Superb]

Actually it's quite the opposite. It's almost impossible to find the exact same output with "same" decoders. Only if they share same code and run at the exact same enviroment.H.264 has a pixel perfect exact output no matter what decoder you use. Hardware or software. Fast or slow.

Oh, and before you try, stuff like skipping deblocking is idiotic and does not represent the normal output expected by proper decoding (it usually means the decoder is too slow to properly decode the input in realtime).

Of course there are the other steps after the decoding... stuff like resizing the video to the screen's resolution (in case it's smaller/bigger). That depends on which algorithm is used (for the resizer).

[Superb]

You present yourself as a number "6205" and usually I don't reply to numbers...
We noticed. You rather use words to define speed comparisons and quality. :P

[NikosD]

H.264 has a pixel perfect exact output no matter what decoder you use. Hardware or software. Fast or slow.

Oh, and before you try, stuff like skipping deblocking is idiotic and does not represent the normal output expected by proper decoding (it usually means the decoder is too slow to properly decode the input in realtime).

Of course there are the other steps after the decoding... stuff like resizing the video to the screen's resolution (in case it's smaller/bigger). That depends on which algorithm is used (for the resizer).

You don't say something different.

[MPC-HTPC]

We tried to understand what was going on with Tetsuo using VS2010 debugger but I don't know the source code enough to find what is going wrong ...

There is in fact an assert which fails in BaseSplitterFileEx.cpp because of a value returned by BitRead (BaseSplitterFile.cpp) but we don't know why such a value appears when seeking rapidly and not when playing normally ... :(

That sounds indeed weird, but underlines the errors I got with the debug build. Anyhow my programming skills are close to zero, so I have to hope that there is somebody who can figure out how to fix this. :)

[Guest]

You don't say something different. Of course he did. You claimed incorrectly that different *decoders* produce different output. Superb corrected you.

[NikosD]

We noticed. You rather use words to define speed comparisons and quality. :P

Have you found out a way to "measure" quality with numbers ?
Have you found out a way to "measure" speed with words ?
You are a wonder boy

[Guest]

Have you found out a way to "measure" quality with numbers ? There are many such metrics. For example, see here:

ftp://ftp.cs.wpi.edu/pub/techreports/pdf/06-02.pdf

Have you found out a way to "measure" speed with words ? Superb was remarking on a lack of data backing up your claims.

[NikosD]

Of course he did. You claimed incorrectly that different *decoders* produce different output. Superb corrected you.

Read more carefully my post and his answer. He used the words "proper" and "other steps", to describe what I wrote about same code and same enviroment.

[Superb]

Have you found out a way to "measure" quality with numbers ?
Have you found out a way to "measure" speed with words ?
You are a wonder boy

We noticed. You rather use words to define speed comparisons and quality. :PThere's only one wonder boy here.

[Guest]

Let's not get personal, guys. Thank you.

@NikosD

I already read the posts carefully. You wrongly claimed this:

It's almost impossible to find the exact same output with "same" decoders.

"Other steps" are not part of the decoder.

[NikosD]

There are many such metrics. For example, see here:

ftp://ftp.cs.wpi.edu/pub/techreports/pdf/06-02.pdf

Superb was remarking on a lack of data backing up your claims.

I will not go into the discussion of qualitative metrics. You use such metrics if you want to sell something. If you understand what I mean.

About speed, I wrote before that I get ~35 fps with MPC-HC DXVA and I get ~55 fps with PotPlayer DXVA.
Which number you don't understand ?

[Superb]

Alright. I apologize for going off topic and giving too-personal comments.

Anyway, I have 8800GT here. I believe it has the VP2 engine.
I tested both 1080p60 clips posted here (one .ts and one .mts) and noticed that VP2 cannot handle the load and thus can't play the videos smoothly.
Tested w/ Microsoft's DTV-DVD Video Decoder (in DXVA mode). Tested in both WMP12 (EVR) and MPC-HC (EVR & EVR-CP).
I used DirectShowSpy to connect to the filter graph of WMP12 and view the property page for EVR.
GPU-Z showed 90-92% video decoder usage.

I guess one would need either VP3 or VP4 to decode them smoothly.

[Guest]

@NikosD

I'm talking about your claims about different output from different decoders. Anyway, since you dismiss my demonstration that the idea of quality metrics is well-known, contrary to your erroneous claim, I'll go away, as the discussion is not productive.

[Guest]

Anyway, I have 8800GT here. I believe it has the VP2 engine. I tested both 1080p60 clips posted here (one .ts and one .mts) and noticed that VP2 cannot handle the load and thus can't play the videos smoothly. That is consistent with the known performance of the VP2. Refer to the DGDecNV benchmark thread if you are interested in seeing results for other cards.

[NikosD]

Let's not get personal, guys. Thank you.

@NikosD

I already read the posts carefully. You wrongly claimed this:



"Other steps" are not part of the decoder.

I see the misunderstanding.
PotPlayer is not a decoder. It's an All-in-one player. So it doesn't do only decoding.
You stuck in the word decoder. Replace it with player, because we were talking about PotPlayer software and not for some DXVA or software codec

[Guest]

You stuck in the word decoder. Wrong. As I already stated, you originally said this:

"It's almost impossible to find the exact same output with "same" decoders."

Note that you used the word "decoder". I did not "stick it in". Please do not blame me for your inability to distinguish between a player and a decoder. I tried to correct the record for others viewing the thread, just as Superb did.

[NikosD]

@NikosD

I'm talking about your claims about different output from different decoders. Anyway, since you dismiss my demonstration that the idea of quality metrics is well-known, contrary to your erroneous claim, I'll go away, as the discussion is not productive.

About different output and different decoders, see my previous post.
About qualitative metrics, of course they are well-known.

We do business with them! We sell products and we are fooling people with them!

Sorry for the off-topic and the phylosophical discussion

[NikosD]

Wrong. As I already stated, you originally said this:

"It's almost impossible to find the exact same output with "same" decoders."

Note that you used the word "decoder". I did not "stick it in". Please do not blame me for your inability to distinguish between a player and a decoder. I tried to correct the record for others viewing the thread, just as Superb did.

Come on now! You can do better than this.

[tetsuo55]

Image comparisons should not be taken as a standalone fact.

Differences between image A and B need to be explained, the explenation should be falsifiable, but fail to be falsified.

[NikosD]

Is it in your plans to fix the DXVA issue with UHD clips? (post 14405)
And the performance of AVCHD clips ? (post 14432)

Thank you

[tetsuo55]

If there is a ticket for it on the tracker then yes.

[NikosD]

Image comparisons should not be taken as a standalone fact.

Differences between image A and B need to be explained, the explenation should be falsifiable, but fail to be falsified.

My final opinion:

Assessing image quality is a hard thing to do. There are no objective methods to measure the quality of images, let alone video sequences.
Unlike MPEG-2 and other earlier video standards, all correct H.264 decoders are required to produce exactly the same images, bit for bit. Everything else would be a bug. Of course there are bugs, but if all the decoders work “correctly enough” they produce images free of decoder error artifacts.

So, if decoder A produces different results from decoder B, this means that at least one of them is buggy or does some post-filtering it isn’t supposed to do.

The End

[tetsuo55]

thats exactly what i meant so we agree