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

[Snowknight26]

Playing 5.1 channel FLAC tracks still has huge issues with the x64 r990 build. As soon as you start playing, there is no sound, but when you seek, the framerate drops to something ridiculously low (15 instead of 23.976) and the audio is extremely slow.

[ADude]

DXV7 ? Cant find it - or better said: Google cant find it. Anyhow bugs should be reported... So where could one do that?

Sorry, I was distracted when typing originally, it is:

Divx7 - if you download Divx Player Version 7, it includes an H.264 decoder that is roughly competitive with others (see earlier in this thread, less than a week).

[DrNein]

I don't know, I rather look @ the black bars than miss any part of media due to cropping

Black bars were created to match AR of the media with the screen, no (?)

Yes, all shenanigans are precluded when the aspect ratio of the video frame consistently matches that of the display standard, regardless of the viewable image AR contained within.

Good point about losing image to cropping as well -particularly if restricted to a divisor since it cannot match all ARs.

[wOxxOm]

btw, MPCHC looks million times better without WS_THICKFRAME | WS_BORDER - I've always wondered how to remove that ugly ugly ugly 3px frame around the video in windowed mode... well it's easy - just replace 680080cf00 with 6800804b00 (one byte change CF->4B) in mplayerc.exe

[STaRGaZeR]

After further testing, I've found that FLAC also works for me in x64, but only if I use the internal FLAC filter with the internal decoder and I disable the internal audio switcher.

So it seems that:

The x86 and x64 FLAC source filters only want to connect to the internal decoder.

The X64 FLAC decoder only wants to connect directly to the audio renderer.

How discombobulating :)

Good find, I always have the internal switcher disabled :)

[offndr]

When I disable vsync it stays of until the next time I start MPC-HC. Then it is enabled again. Is this a bug? Or am I doing something wrong?

With vsync enabled I get choppy playback.

[Kado]

@DrNein ,Rain1
I suppose the problem was the luma range setting applied by ATI driver and not failure to playback the video using DXVA. If I recall properly the videos play fine but the luma range used is incorrect. It's always better to allow the end user to have control over the settings instead of using an automated system that may not always work correctly.

[tetsuo55]

So where can one report bugs? Is this thread read by the author or is there a specific bug-tracker-page? I would so like to play my Full-HD recorded movies but without the ingenious DVXA-Acceleration of MPC-HC its not really working fine. Yes, VLC will play the file fine but Full HD-Content without DXVA is bringing my system to the verge of collapsing...

You can report bugs here:

http://sourceforge.net/tracker2/?func=browse&group_id=170561&atid=854651

First check if the bug has not already been reported.

If you don't submit a bug to the bugtracker the chances of it getting fixed are very slim(even then there is no guarantee as this is a volunteer project, and we need as many as we can get),at the very least the report will not get lost in the 100's of pages in this thread.

[clsid]

Also keep in mind that the developers work on MPC-HC in their spare time. They have lots of bugs and feature requests on their ToDo lists. So some things simply get assigned a low priority and it might take a while before a bug that you report actually gets fixed.

[Xorp]

For TrueHD tracks the description should be "Dolby TrueHD" not "Dolby Digital True HD".

[DrNein]

@DrNein ,Rain1
I suppose the problem was the luma range setting applied by ATI driver and not failure to playback the video using DXVA. If I recall properly the videos play fine but the luma range used is incorrect. It's always better to allow the end user to have control over the settings instead of using an automated system that may not always work correctly.

Yes, the issue is luma range rather than greater failure but problems with both it and DXVA are due to non-compliant encoding -in the case of DXVA using the wrong level and/or reference frames and in the case of luma range the wrong resolutions. Maybe other hardware (and its software) treat this differently but ATI default for this setting does rather logically assume that anything other than HD standard resolutions is to be treated as otherwise. For instance, by definition of the standard 1920x800 is not HD so odd results should not be surprising. End user control is good for us and thankfully it is a simple fix but generally with a standard we should expect to trade some flexibility for the ability to playback anywhere with the same result.

[boyumeow]

When I disable vsync it stays of until the next time I start MPC-HC. Then it is enabled again. Is this a bug? Or am I doing something wrong?

With vsync enabled I get choppy playback.

If I m not wrong, it was intended by the dev for testing. Thanks.

[Mercury_22]

Starting with ffdshow rev 2660 MPC-HC it's crashing because some incompatibility of the internal mpeg splitter with the new ffdshow when I'm seeking or playing any ts or m2ts using ffd's audio. MPC-HC with other splitters it's NOT crashing !
Can someone take a look at it ! PLEASE ! :helpful: cause I DON'T think it's just FFD's fault :thanks:

Maybe this Revision 2660 - Directory Listing
Modified Sat Feb 7 08:55:27 2009 UTC (40 hours, 42 minutes ago) by h_yamagata
Use MSVC's STL instead of uClibc++.can give you a hint about where is the problem
More here: http://forum.doom9.org/showthread.php?p=1247099#post1247099

EDIT: Problem solved with FFD's rev 2669 but still since other spliters (Haali, Cyberlink ...) had no problems I think someone should take a look into it

[flanger216]

I've determined that using the audio switcher with the Xiph x64 FLAC filter/decoder also doesn't work - it crashes the player completely. Seems the x64 audio switcher is generally unstable.

[rt87]

I agree with that. Moreover, "16-235 -> 0-255 [SD]" in mpc-hc 989, has worked correctly, without errors (I specifically tested it on files with a different ratio screen).

sorry for off-topic here, but @alexins: did you check your private messages (http://forum.doom9.org/private.php)?

[Scoty]

I have buy a Nvidia GTX 260 and use the Driver 181.22 with mplayerc_homecinema_x86_v1.2.908.0 but i can not use DXVA.
Why can i not use DXVA??

[hdboy]

I have an oddity with some 1080p mkv and mp4 files where "video size" is reported as 960x540 while video is 1920x1080. see

http://img156.imageshack.us/img156/8939/mpcpropwr1.th.png (http://img156.imageshack.us/my.php?image=mpcpropwr1.png)

I'm using mpc 989, coreavc 1.8.5, haali splitter dated jan 09.

[clsid]

That is the resolution that is reported back by the video renderer I think. If you look below on your screenshot, you'll see that the input resolution is reported correctly.

Haali video renderer can sometimes resize to half the resolution. It does that in windowed mode when the original resolution is too big to fit your screen.

[Rille]

@Beliyaal

I'm having problems with huge judder after watching a movie for a while. It can work fine for anything between 1-60 minutes but suddenly starts stuttering:
http://img27.imageshack.us/img27/6272/judderxk0.th.jpg (http://img27.imageshack.us/my.php?image=judderxk0.jpg)

It will continue to do this until i pause for a few seconds and press play again:
http://img27.imageshack.us/img27/6088/afterpausezu5.th.jpg (http://img27.imageshack.us/my.php?image=afterpausezu5.jpg)

Tested on two computers. Both use:
ATI and Catalyst 8.12/9.1 (tested both)
Vista SP1 32bit with Aero enabled
EVR custom, DXVA
Tried D3D fullscreen and standard. Tried vsync, accurate vsync, locked/unlocked backbuffer, 5-20 buffers.
Using reclock and monitor set at 50Hz

Any ideas? Problem doesn't occour with first testbuild you made (the one that had lots of tearing).

[gngn]

it seems that multichannel flac streams (embedded in containers or not) are not decoded within the internal filter, correct ? missing feature or bug ?

with rev988 it will play, but it wont downmix to stereo.

[madshi]

Just received information from Microsoft about how to pass TrueHD/DTS-HD to a DirectShow audio renderer in Windows 7. If anybody is interested, please PM me.

[lexor]

xvidvideo.ru linked in OP is down (for me, at least), where else can I get recent mpc-hc builds?

[Kado]

@Scoty
Please! Have you actually read how to make DXVA work? Like renderer used, intermediate filters, reference frames, etc? Without any details help won't come to you.

[Kado]

CoreAVC v1.9.0 added CUDA H.264 video decoding! Probably rendering DXVA usesless as it (probably) does not have the DXVA limitations.

[Leak]

Probably rendering DXVA usesless as it (probably) does not have the DXVA limitations.
I'm pretty sure it draws a lot more power though since it's using the card's shader units for decoding - and low-end cards might not even have beefy enough shaders for CUDA decoding but since they've usually got the same video decoders as the high-end models they'll work just fine with DXVA.

Don't dismiss DXVA outright - if your graphics card sounds like a leafblower when using the shaders for decoding whereas it's quiet with DXVA I'd call that a significant difference... ;)

[lexor]

I'm pretty sure it draws a lot more power though since it's using the card's shader units for decoding - and low-end cards might not even have beefy enough shaders for CUDA decoding but since they've usually got the same video decoders as the high-end models they'll work just fine with DXVA.

Don't dismiss DXVA outright - if your graphics card sounds like a leafblower when using the shaders for decoding whereas it's quiet with DXVA I'd call that a significant difference... ;)
It doesn't use shaders, it uses dedicated ASIC. And the problem isn't with low-end cards (as all cards have the same ASIC unit), it's just a matter of having enough on board RAM. The problem is with the old cards, which don't have the unit.

Can't comment on power, don't have CoreAVC yet (still waiting on 64bit support) until then ffdshow is good enough. You are, however, forgetting a major advantage of other solutions, instant random seek, as opposed to 3sec delay on random jump that MPC's own implementation incurs. (and my hardware is not weak, see sig)

Now can someone please give me a link to a recent mpc-hc 32bit build (I've got an 64bit version for testing and it doesn't connect to 32 bit filters) xvidvideos.ru is still down.

[The1n]

@Casimir666

Have you seen that an Intel representative is asking for your email address over at the intel devel forums, regarding G45 and MPC DXVA.

I really hope that they can help you fix this for MPC.

The1n

[sneaker_ger]

Now can someone please give me a link to a recent mpc-hc 32bit build (I've got an 64bit version for testing and it doesn't connect to 32 bit filters) xvidvideos.ru is still down.

MPC-HC 989 32bit (from xvidvideo.ru):
http://netload.in/dateiMHY5LJKKvv/mpc-homecinema.989.7z.htm

[Px]

It doesn't use shaders, it uses dedicated ASIC.
If you don't want look stupid, read Wiki (http://en.wikipedia.org/wiki/CUDA) at least

[Leak]

It doesn't use shaders, it uses dedicated ASIC.
Considering that there's no mention of video decoding in the official CUDA documentation (http://www.nvidia.com/object/cuda_develop.html) I very much doubt that those decoders are using the dedicated video decoding hardware on the cards - I'd rather assume they'd implement a software decoder using the card's shader units.

And even then all people using ATI and Intel graphics chipsets would agree to disagree with "CUDA rendering DXVA useless"...

[STaRGaZeR]

If you don't want look stupid, read Wiki (http://en.wikipedia.org/wiki/CUDA) at least

Right now it's you the one who look stupid. CoreAVC uses a dedicated ASIC present inside the GPU, not the shaders. It's accessed through CUDA. DGAVCDecNV uses the same method.

[lexor]

@sneaker_ger: thank you very much.

If you don't want look stupid, read Wiki (http://en.wikipedia.org/wiki/CUDA) at least

Considering that there's no mention of video decoding in the official CUDA documentation (http://la.nvidia.com/object/cuda_develop.html) I very much doubt that those decoders are using the dedicated video decoding hardware on the cards - I'd rather assume they'd implement a software decoder using the card's shader units.

And even then all people using ATI and Intel graphics chipsets would agree to disagree with "CUDA rendering DXVA useless"...

My info comes from neuron2's log of his discussion with Nvidia CUDA engineer. I'm sorry if I don't take both your sources as overruling.

[Px]

CoreAVC uses a dedicated ASIC present inside the GPU, not the shaders.
Really? Then how you explain this post:
- On 1080i HDTV with DVBViewer CUDA doesn't seem to work (as said above)
- On 720p MKV CUDA is working but the framerate is too slow
- On 1080p MKV CUDA is working with low CPU (<15%) but the framerate is very slow...

http://forum.corecodec.com/viewtopic.php?p=8820#p8820

[STaRGaZeR]

Really? Then how you explain this post:

http://forum.corecodec.com/viewtopic.php?p=8820#p8820

Yes, really.

Why should I know about CoreAVC bugs? I'm not a CoreAVC developer.

[lexor]

Seriously, if you don't believe us, there is no need to argue, just go into h264 subforum and ask in the CoreAVC thread. Betaboy is pretty active there, now that there is a new release.

[Px]

Why should I know about CoreAVC bugs?
So, that is a bug, and not the consequence of small quantity of shader units, ok :rolleyes:
just go into h264 subforum and ask in the CoreAVC thread
You post information about ASIC, so you must prove this because it not follow from general information about CUDA

[gngn]

after a quick check, the new CoreAVC presents the same limitations as DXVA with MPC-HC. especially SD with over 11ReFrames.
but you can use VSFilter for subs and postprocessing with ffdshow ...

[lexor]

You post information about ASIC, so you must prove this because it not follow from general information about CUDA

I don't owe you anything. Especially after your insulting first post on the subject.

If you do not feel that this is important enough to ask CoreAVC dev about, why should I do the work on your behalf? Especially since I already read what Nvidia engineer has to say on the subject, and therefore there is no further knowledge to be gained here for me.

[STaRGaZeR]

So, that is a bug, and not the consequence of small quantity of shader units, ok :rolleyes:

Whatever floats your boat mate, this discussion is useless. Do some research before calling someone stupid ;)

You post information about ASIC, so you must prove this because it not follow from general information about CUDA

It's well know that it uses the internal ASIC accessed through CUDA, but you say it uses the shaders, so you should post information about how CoreAVC or DGAVCDecNV use the shaders. Please tell us how neuron2 or the CoreAVC developers have written a CUDA based decoder from scratch. It's a pity you won't find any info, because it doesn't exist.

[Kado]

Well I tried it and using CUDA is the same as using MPC-HC DXVA because it uses the H.264 bitstream decoder. The difference is that you can use any renderer you want and still use the DXVA capabilities!
DXVA Checker still says that the CoreAVC filter does not support DXVA maybe because it accesses the Bitstream decoder differently, but if you start playback the icon goes green.
Since it uses the Bitstream decoder the card will not heat up (not that that was a problem for me because I have an Arctic Cooling Accelero Xtreme 9800 (http://www.arctic-cooling.com/catalog/product_info.php?cPath=2_&mID=102) over my 9800GTX:D)!

P.S.=> It seems that forceware 185.20 are not supported by CoreAVC because I had to downgrade to 182.05 to use CUDA.

Vobsub can now be used along with CUDA/DXVA.
Tried with EVA 1.01 H.264 and it gives a blocky image with weird colors and MPC-HC DXVA decoder using DXVA produces a normal picture.
CoreAVC rule set to use or not DXVA is worser than MPC-HC decoder because it decodes 12 ref frame files giving corrupted playback.

[Px]

It's well know that it uses the internal ASIC accessed through CUDA, but you say it uses the shaders
CUDA is made to use shader blocks in general purpose computing, so when someone talking about acceleration with CUDA - it means the same.
But you claiming that not in this case - ok, I've read corresponding threads and see that "CUDA Decoder" is only interface to bitstream decoder, same as DXVA with same limitations
Ok, I've taking my words back :)

[nitec]

Hi,

Guru3D released an article about MPC-HC and hardware video acceleration.

http://www.guru3d.com/article/accelerate-x264-1080p-movies-over-the-gpu-guide/1

[Casimir666]

Have you seen that an Intel representative is asking for your email address over at the intel devel forums, regarding G45 and MPC DXVA.

I really hope that they can help you fix this for MPC.

The1n

Ok thanks :-)

[Snowknight26]

Guru3D released an article about MPC-HC and hardware video acceleration.

The whole article is a laugh. :rolleyes:

[STaRGaZeR]

CUDA is made to use shader blocks in general purpose computing, so when someone talking about acceleration with CUDA - it means the same.
But you claiming that not in this case - ok, I've read corresponding threads and see that "CUDA Decoder" is only interface to bitstream decoder, same as DXVA with same limitations
Ok, I've taking my words back :)

No, it does not mean the same. VP2 is not a "shader block" and it can be accessed through CUDA. Shaders are general purpose units, while VP2 is a dedicated processor that can only do certain things in this case related to video decoding. That invalidates your claim.

DXVA does not use the shaders, it uses VPx (which is the ASIC embedded into the GPU we're talking about). CoreAVC and DGAVCDecNV use the same VPx processor to decode the video, but accessed through CUDA instead of the Microsoft API. This will result in the same problems/advantages that when using DXVA, with the benefit of not needing to connect the decoder to the renderer directly, and being renderer independent, which is a big plus. But if you try to play a file exceding the decoding capabilities of the VPx unit it'll show blockiness or any kind of visual glitches. That's the limitation of hardware decoders.

[Px]

No, it does not mean the same.
In all cases, except this marketing stuff (Let's use cool name CUDA!!!111) it means the same

[THX-UltraII]

Anyone heard from Beliyaal anything? I saw that his last post dates from the 4th of this month. Anyone know if he is still working on new MPC-HC patches?

[THX-UltraII]

and another question about the ac3filter that untill now cannot be answered on the AVS, videotech or AC#filter forum. Always keep in mind that I want just passthrough of SPDIF and NO decoding being done by AC3filter:

1.
When I play regular dvd's (VIDEO_TS folders with included .vob files) SPDIF passthrough work great (sample 1). I can see in the Decoder info that the sound is only beeing passed through by AC3 filter and that the filter does not decode it.

2.
When I play HD content, it gets different. Playing .mkv files gives my also SPDIF passthrough (sample 2). But playing my .wmv material, the ac3 filter has to decode it (sample 3) or else I do not see Dolby Digital on my receiver display. I know this has something to do with how the movie was ripped and decoded. Also also see that the presented signal is PCM. I would like to know if these kind of files (where the audio is presented in PCM) can be played in some way that my receiver does the decoding.

Before asking more questions, Ill first post this one, one thing at a time ;)


sample 1:
Input format: MPEG Program Stream - 48000
User format: PCM24 - 0
Output format: SPDIF 3/2.1 (5.1) 48000

Use SPDIF
SPDIF status: SPDIF passthrough
SPDIF passthrough for: MPA AC3 DTS
Use AC3 encoder (encode stereo PCM)
Do not check SPDIF sample rate
Do not query for SPDIF output support

Decoding chain:
(MPEG Program Stream - 48000) -> Demux -> (AC3 - 48000) -> Spdifer -> (SPDIF 3/2.1 (5.1) 48000) -> Dejitter -> (SPDIF 3/2.1 (5.1) 48000)

Filters info (in order of processing):

Demux:
-

Spdifer:
Stream format: AC3 3/2.1 (5.1) 48000Hz
Bitstream type: byte stream
Frame size: 1536
Samples: 1536
Bitrate: 384kbps
SPDIF stream type: 0x1
Frame interval: 1536
Actual bitrate: 384kbps
Output format: SPDIF 3/2.1 (5.1) 48000Hz
SPDIF format: wrapped
Bitstream: 16bit LE
Frame size: 6144

Dejitter:
-

sample 2:
Input format: DTS - 48000
User format: PCM24 - 0
Output format: SPDIF 3/2.1 (5.1) 48000

Use SPDIF
SPDIF status: SPDIF passthrough
SPDIF passthrough for: MPA AC3 DTS
Use AC3 encoder (encode stereo PCM)
Do not check SPDIF sample rate
Do not query for SPDIF output support

Decoding chain:
(DTS - 48000) -> Spdifer -> (SPDIF 3/2.1 (5.1) 48000) -> Dejitter -> (SPDIF 3/2.1 (5.1) 48000)

Filters info (in order of processing):

Spdifer:
Stream format: DTS 3/2.1 (5.1) 48000Hz
Bitstream type: 16bit big endian
Frame size: free format
Samples: 512
Bitrate: unknown
SPDIF stream type: 0xb
Frame interval: 2012
Actual bitrate: 1509kbps
Output format: SPDIF 3/2.1 (5.1) 48000Hz
SPDIF format: wrapped
Bitstream: 16bit LE
Frame size: 2048

Dejitter:
-

sample 3:
Input format: PCM24 3/2.1 (5.1) 48000
User format: PCM24 - 0
Output format: SPDIF 3/2.1 (5.1) 48000

Use SPDIF
SPDIF status: AC3 encode
SPDIF passthrough for: MPA AC3 DTS
Use AC3 encoder (encode stereo PCM)
Do not check SPDIF sample rate
Do not query for SPDIF output support

Decoding chain:
(PCM24 3/2.1 (5.1) 48000) -> Processor -> (Linear PCM 3/2.1 (5.1) 48000) -> Encoder -> (AC3 3/2.1 (5.1) 48000) -> Spdifer -> (SPDIF 3/2.1 (5.1) 48000) -> Dejitter -> (SPDIF 3/2.1 (5.1) 48000)

Filters info (in order of processing):

Processor:
(PCM24 3/2.1 (5.1) 48000) -> PCM->Linear converter -> (Linear PCM 3/2.1 (5.1) 48000) -> Input levels -> (Linear PCM 3/2.1 (5.1) 48000) -> Equalizer -> (Linear PCM 3/2.1 (5.1) 48000) -> SRC -> (Linear PCM 3/2.1 (5.1) 48000) -> Mixer -> (Linear PCM 3/2.1 (5.1) 48000) -> Bass redirection -> (Linear PCM 3/2.1 (5.1) 48000) -> Dither -> (Linear PCM 3/2.1 (5.1) 48000) -> AGC -> (Linear PCM 3/2.1 (5.1) 48000) -> Delay -> (Linear PCM 3/2.1 (5.1) 48000) -> Spectrum -> (Linear PCM 3/2.1 (5.1) 48000) -> Output levels -> (Linear PCM 3/2.1 (5.1) 48000)

Encoder:
-

Spdifer:
Stream format: AC3 3/2.1 (5.1) 48000Hz
Bitstream type: byte stream
Frame size: 2560
Samples: 1536
Bitrate: 640kbps
SPDIF stream type: 0x1
Frame interval: 2560
Actual bitrate: 640kbps
Output format: SPDIF 3/2.1 (5.1) 48000Hz
SPDIF format: wrapped
Bitstream: 16bit LE
Frame size: 6144

Dejitter:
-

[japa]

I have a problem with subtitles, some characters are not displayed correctly... Can anyone help me?
http://i42.tinypic.com/334kok1.jpg

[Casshern]

Hi,

i think this is a AC3Filter related question - and has nothing to do with MPC HC. But let me try to answer: wmv is a container format and often contains audio encoded with microsofts audio codec. Most receivers cannot decode this format - so it has to be decoded by the pc first. If its decoded its in PCM. From this point there are soime alternative:
1) Mix it down to stereo and transfer it as such over SP/DIF to the receiver
2) Use a number of analog connections to get the multichannel sound to the receiver
3) Reencode the PCM to AC3 and then pass the multichannel sound to the receiver. Most receivers can handle AC3

You can configure ac3filter on what to do if it gets passed the alread decoded pcm channels. The decoding to pcm is done by microsofts directshow filters before ac3filter.

I hope this answers you question.

and another question about the ac3filter that untill now cannot be answered on the AVS, videotech or AC#filter forum. Always keep in mind that I want just passthrough of SPDIF and NO decoding being done by AC3filter:

1.
When I play regular dvd's (VIDEO_TS folders with included .vob files) SPDIF passthrough work great (sample 1). I can see in the Decoder info that the sound is only beeing passed through by AC3 filter and that the filter does not decode it.

2.
When I play HD content, it gets different. Playing .mkv files gives my also SPDIF passthrough (sample 2). But playing my .wmv material, the ac3 filter has to decode it (sample 3) or else I do not see Dolby Digital on my receiver display. I know this has something to do with how the movie was ripped and decoded. Also also see that the presented signal is PCM. I would like to know if these kind of files (where the audio is presented in PCM) can be played in some way that my receiver does the decoding.

Before asking more questions, Ill first post this one, one thing at a time ;)


sample 1:


sample 2:


sample 3: