Media Player Classic Home Cinema (MPC-HC) - DXVA! [Archive] - Page 280

Dreamhacker

17th August 2010, 12:08

Patch which enables the following options in the registry/ini:

- PrioritizeExternalSubtitles
- DisableInternalSubtitles

The first one makes MPC-HC always default to an external subtitle over the internal subtitle if both are available.
The second one makes MPC-HC never load internal subtitles (mind that it doesn't look for forced subtitles that should be left on at this moment).

Link: http://home.nith.no/~lilgun/mpc-hc-subtitle-options.patch

PS: Gonna add interface options for them too at some point, but will try to get the new bar class done first (crashes get prio :P).

omri09

17th August 2010, 12:26

There is no difference in functionality if you mean that by difference. I would recommend you to stick with the x86 version, even with Win7 x64, and be satisfied. :)

:thanks: :p

MPC-HTPC

17th August 2010, 12:31

Great news that you are working on a new bar class, Dreamhacker. Thanks for that one in advance! ;)

And I hope your subtitle changes will be integrated into SVN soon, so we can try them! Also thanks for that one and the coming interface options in the future. :)

mark0077

17th August 2010, 14:15

Hi, I assume nobody else is having issues with mpc and haali media splitter with m2ts files. I'm getting no truehd if I use haali, and with dts, I'm getting channels switching autmoatically every couple of seconds... really strange.

Is there a way for me to debug this, ie debug why I get no audio at all with truehd... is there some way to make mpc / haali create a log for example to say why no audio decoder is in the chain...

Superb

17th August 2010, 14:31

burfadel

17th August 2010, 14:36

Ever since I've owned my radeon HD5450, I've been getting an error message using DXVA saying "display driver amdkmdap has stopped responding". It only happens on certain (high bitrate 1080p) movies like Avatar or Transformers. I decided to test the card out in my XP machine and I was error free.

My system is completely stable, and I've literally tried every "fix" for this common error.

Have you tried updating the driver? ATI have made it extremely easy to know what driver is out, they release one once a month and have a year.month naming scheme. Currently the latest is Catalyst 10.7 (year 2010, month July), with 10.8 coming out before the end of the month. ATI may release hotfix drivers that fix specific problems (and based on a different driver version) such as the current 10.7a. Despite what people claim ATI drivers aren't worse than Nvidia drivers in terms of stability. Most games that present problems with ATI mysteriously have the Nvidia logo on them :rolleyes:

Virtual_ManPL

17th August 2010, 15:41

Just curious, why I can't use external Haali splitter (not registered to system, only extracted from installer) added to external filters in MPC-HC. Internal splitters MKV,MP4,AVI,MPEG,OGG are disabled. Setting "Any type - Any type" didn't help too. Same with LAVFSplitter (https://forum.doom9.org/showthread.php?t=156191)
It's known bug ?

hoborg

17th August 2010, 15:44

DGMurdockIII

17th August 2010, 16:33

if libbluray was integrated in to Media Player Classic Home Cinema I would use this player over vlc

home page - http://www.videolan.org/developers/libbluray.html

maling list - http://mailman.videolan.org/listinfo/libbluray-devel

source code - http://git.videolan.org/?p=libbluray.git

git clone git://git.videolan.org/libbluray.git

MPC-HTPC

17th August 2010, 16:49

DGMurdockIII,

your question was already raised before. Please see the below quote from tetsuo55, the MPC-HC Project Manager, regarding libbluray:

Yes we have been in contact with the team in the beginning of this project and intend to support it in the future.

So libbluray support will be implemented some day. Hope your question is answered and I can just recommend to use MPC-HC! :)

Snowknight26

17th August 2010, 17:32

It does here on r2257

Never had that problem thou.

Forgot to add that it happens on Windows 7. I'll test it in a VM later to confirm (or refute) my suspicions.

rahzel

17th August 2010, 19:12

Have you tried updating the driver? ATI have made it extremely easy to know what driver is out, they release one once a month and have a year.month naming scheme. Currently the latest is Catalyst 10.7 (year 2010, month July), with 10.8 coming out before the end of the month. ATI may release hotfix drivers that fix specific problems (and based on a different driver version) such as the current 10.7a. Despite what people claim ATI drivers aren't worse than Nvidia drivers in terms of stability. Most games that present problems with ATI mysteriously have the Nvidia logo on them :rolleyes:
Definitely... I've tried every driver released in the past 6 months. I've tried almost everything I can think of. The only thing I haven't tried, is update the BIOS on my video card, because 1) I don't know where to get one, and 2) I'm not comfortable doing it. I've contacted AMD/ATI and Gigabyte, and ATI basically told me to test other components over and over a again and to update them using software that reports your system specs and driver/BIOS revisions. Gigabyte finally told me to RMA the card, but I just want to make sure before I ship it back and pay money when I might not need to. Although, at this point, it seems like the video card is not 100% stable.

Alexander01

17th August 2010, 20:02

Snowknight26

17th August 2010, 21:06

The changes made in r2190 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2190) now make the total duration of certain files display incorrectly, limiting seeking. When the internal MPEG splitter is unchecked in the list but is used nevertheless (be it because no other MPEG splitters exist on the system or for whatever other reason), the file duration is always 3 seconds. When the internal MPEG splitter is checked in the filters list, the duration is correct. Should be an easy fix.

XhmikosR

17th August 2010, 21:57

Great! I hope we will see this integrated soon in new builds of MPC-HC.

It will when Dreamhacker finishes his patch and it's thoroughly tested.

alexins

18th August 2010, 00:55

Media Player Classic HomeCinema (x86/x64), svn 2264 (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-svn-2264.html)

Changes (2250-2264):

removed DisableSpecificWarnings from common.props and common.vsprops files;
Installer: added separate components for mpciconlib and translations;
muxers: applied astyle formatting;
mpcinfo: applied astyle formatting, added VS2008 project and solution file;
excluded DiracSplitter and libdirac from builds (DiracSplitter didn't work for quite some time);
mpcinfo: -fixed warnings was about using functions without any protection from buffer overflows [Patch by Alexx999]; -added MSVC2010 project and solution files;
mpcinfo: fixed typos in mpcinfo.txt;
update korean translation;
Add : E-AC3 support in MPEGSplitter;
Fix : ticket #333;
Add : Optional internal PCM RAW Audio Decoder;
Fix : revert back 2249, MPEGSplitter;
Updated Czech translation;
updated AUTHORS and CHANGELOG;
Installer: hide the license page if it's an upgrade.

Dreamhacker

18th August 2010, 03:24

I just want to announce, I have found the actual reason for the playlist/shader editor errors, and I know how to fix them. :D
After all, it seems the fault was not on sizecbar, but the derived classes from it. Meaning we can still use sizecbar, we just need to fix up a few values in the classes that derive from it. ;)

So, in the next few days I'll probably have a patch ready for those crashes, along with proper implementation of the subtitle options (i.e. adding them to the settings dialog and stuff too).

PS: VS2008 obviously wasn't strict enough when it let coding errors like this pass. :S

SamuriHL

18th August 2010, 03:56

Nice work!

APorter819

18th August 2010, 04:09

I hope this is where I ask the following question. When playing a movie in a mkv container in MPC-HC that has 2 audio files, the first listed audio files plays instead of the audio file marked as default. Is this correct? In order to get the True HD file to play I have to stop the movie to switch the audio as switching on the fly does not work. I have the AC3 file first so that I can stream to another device but would like MPC-HC to pick the audio set as default.

Alexander01

18th August 2010, 05:18

Can someone confirm this:

Is it true that the colors are a little bit deeper/stronger when using the 10 bit RGB option and D3D Fullscreen Mode? I am using the 10 bit RGB option for some time now, but a few days back I also checked the D3D Fullscreen Mode option. I have the feeling the colors are a little bit deeper/stronger with D3D Fullscreen.

Mangix

18th August 2010, 07:26

DGMurdockIII

18th August 2010, 08:20

integrate liba52 in to Media Player Classic Home Cinema

http://liba52.sourceforge.net/

MPC-HTPC

18th August 2010, 09:48

As far as I am aware MPC-HC is (still) using liba52. There was a discussion about liba52 beginning of this year, see the below two quotes:

please replace liba52 and libdca with libavcodec. libavcodec always update and better them both. and add disable jitter correction like ffdshow. thank you.

libavcodec does not support 24 bit decoding for these formats, this in effects mean they are clipping data.
We will gladly switch once 24bit support has been added (its not on their to-do list)

According to these quotes MPC-HC will still be using liba52 for some time. If that was already changed and I missed it, please somebody correct me.
Anyway, if the devs have or will change completely to libavcodec, it was their decision and they did it for a good reason, which means that your demand will not be met by the devs.

tetsuo55

18th August 2010, 10:21

Since posting that it has come to my attention that the biddepth is limited by the chosen API, libavcodec is internally float quality.

If we assume that to be true then there is no reason to use anything but libavcodec (and we intend to switch to that for all codecs eventually)

madshi

18th August 2010, 10:32

libavcodec is internally float quality.
It mostly is, but currently almost all libav audio decoders still forcefully downconvert to 16bit integer - and that without even using any dithering, which is a violation of digital processing laws. Shame on them. You can look at the eac3to "legal stuff\ffmpeg" subfolder to see how eac3to patches libav to get full floating point data out of all the libav audio decoders used by eac3to.

tetsuo55

18th August 2010, 11:37

I read some articles on google to update myself on the information available.

Some facts i found:
Ideally a recording would be RECORDED with the highest possible bitdepth and frequency (32bit float and 192khz)

Ideally a recording would be PLAYED with 8bit more bitdepth and the same frequency as it was recorded. (the extra bitdepth will help with rounding errors that occur once the audio sample goes through any mathematical process like resampling, of the bitdepth ends up higher than what the hardware is physically capable off, extra bits get clipped, not dithered)

The bitdepth of the original recording limits the number of steps in db between the loudest and the softest sound, at 63bit the number of steps available supraces the ability of the average human to make out the differences between the smallest step.
In a realworld sample steps are usually so big that 24bit should already be more than enough to hear all the steps.(was unable to re-find the source)

All of this research completely ignores touch sensory information, frequencies/db not only reach your ears but with enough volume and the right placing also bumps into your skin, some db and frequency can make your skin hair or even your skin itself vibrate to the frequency/loudness thus increasing the amount of information the brain can process about a sound. i know many people claim to feel certain frequencies in their neck that they cannot hear in their ears, but this could all be placebo.

Clearly more scientific research is needed.

The above is all about the PCM stream, some codecs like mp3 have other factors and reasons to benefit from a higher bitdepth decoder that i wont go into.

Since on windows we know for a fact that the audio stream will go through some mathematical formulas it probably is a good idea to ouput it with the highest possible bitdepth so rounding errors are minimized.

In any case i would not recommend outputting anything lower than 24bit, 32bit float might be overkill for out content and the expect level of processing that will occur.

Sources:
http://www.tweakheadz.com/16_vs_24_bit_audio.htm
http://en.wikipedia.org/wiki/Audio_bit_depth
unable to find older ones i used several months ago

madshi

18th August 2010, 11:57

@tetsuo, not sure where you got that 63bit number from. Also the information about rounding makes no sense, because using simple rounding is a violation of digital processing laws. Whenever you reduce bitdepth in either video or audio processing, you must apply dithering, instead of simple rounding. Dithering avoids all the rounding problems, at the cost of a higher noise floor. All expert opinions I've *ever* heard clearly say that a final audio output of more than 24bit is totally overkill, if you use proper dithering. Many many experts even say that 16bit is already better than even high-end hardware can reproduce. Again this applies only if proper dithering was used. Blu-Ray is limited to 24bit because more simply doesn't make any sense. More bits may make sense in the studio, though, where loads of processing still needs to be done (e.g. mixing various audio tracks etc), to have a safety net. But for delivery to end users, 24bit is the max that can be useful.

For best audio quality, every decoder should output the data in its native decoded format. Processing (if any) should be done in floating point. The final output to the audio hardware can usually not be done in floating point (neither audio cards nor receivers accept such a format), so it has to be dithered down to e.g. 24bit integer. This should be done as the very last step in the processing chain. This is exactly what eac3to is doing. Unfortunately most libav decoders round down to 16bit, instead of dithering down to 24bit. That's why eac3to applies several patches to libav.

tetsuo55

18th August 2010, 12:12

The 63bit value is based on the maximum number of differences in loudness(db), in the smallest step a human can recognize being different from the same size other step. This value is based on sea level hight. 3ghz would incidentally be the highest possible frequency sound in our athmosphere, and would require a whopping 6ghz to record, so in theory 63bit/6ghz could record any sound that can occur in our current atmosphere at sea level (vulcanos can bend these rules though addition of gasses and extreme heat)

---

Rouding vs Dithering: That makes sense, but to convince ffmpeg we will need the sources where you got that info from, especially direct access to their test methology and results.

---

24bit: yes you confirm what i thought recording/playing at more than 24bit is more than enough for the stuff we bother to record (One reason is that everying above a certain DB level is deadly, the same is true for frequencies).

---

We agree on the processing part then.

---

Since in the near future the audio renderer(or any filter hijacking the audio stream after the decoder) will be responsible for post processing, we should be outputing 32bit/float to the renderer, and only go lower if the renderer fails to understand 32bit/float
Or can we just always output 24/int regardless? and have the renderer use 32/float if and when it does any math?

jeremy33

18th August 2010, 12:31

Any news on the madFlac problem ?

hoborg

18th August 2010, 12:33

Any news on the madFlac problem ?

Was it not fixed already in madFlac1.9?

jeremy33

18th August 2010, 12:40

Ok I didn't see.

Thanks Madshi.

madshi

18th August 2010, 12:46

Rouding vs Dithering: That makes sense, but to convince ffmpeg we will need the sources where you got that info from, especially direct access to their test methology and results.
That's common knowledge, every audio pro knows that. Some of the ffmpeg guys know that, too, they keep on telling me that ffmpeg will "soon" get new audio APIs.

Look here for a paper about dithering:

www.users.qwest.net/~volt42/cadenzarecording/DitherExplained.pdf

Since in the near future the audio renderer(or any filter hijacking the audio stream after the decoder) will be responsible for post processing, we should be outputing 32bit/float to the renderer, and only go lower if the renderer fails to understand 32bit/float
Or can we just always output 24/int regardless? and have the renderer use 32/float if and when it does any math?
What kind of processing do you plan to do in the audio renderer? Channel mixing or something like that?

Anyway, the best solution would be this:

(1) Every decoder should output exactly the native bitdepth of the decoded audio data, regardless of whether it's floating point or integer.

(2) The audio renderer should accept both integer and floating point. If any processing is needed, it must be done in floating point. Final output must be integer, though, because hardware doesn't accept floating point, AFAIK. If no processing needs to be done by the audio renderer, and the input is native integer, the data should stay untouched and should not be converted to floating point (or even to a higher integer bitdepth) to avoid having to apply dither later.

dbone1026

18th August 2010, 12:52

Hey guys,

I had posted a few days ago about the forced subtitle track flag not being respected by MPC for mkvs - http://forum.doom9.org/showpost.php?p=1426246&postcount=13944

I am using MPC HC v1.3.2212.

I have a question about subtitles that are flagged as forced. I have an mkv where I have two subtitle tracks (IDX/SUB). The first subtitle track is the full English subtitles. This is marked as Default = No and Forced = No. The second subtitle track is the forced subtitles. This is marked as Default = Yes and Forced = Yes.

In MPC HC If I keep "Auto-load subtitles" unchecked no subtitles will show. If I check "Auto-load subtitles" MPC HC just loads the first subtitle track, when I think it should auto load the second subtitle track with is flagged as forced. I am not using any External Filters in MPC HC, just the internal ones. Is this noted behavior, does MPC HC not respect the forced track flag? Thanks

I just wanted to confirm if this is a known issue?

tetsuo55

18th August 2010, 13:05

What kind of processing do you plan to do in the audio renderer? Channel mixing or something like that? reclock esque features.

(1) Every decoder should output exactly the native bitdepth of the decoded audio data, regardless of whether it's floating point or integer.
I'm having trouble googling the source, but i remember tests on audio cd and dts tracks that digitally proved that decoding them with 24bit presision slightly improved the amount of data that could be recovered, especially near the noise floor.

If i can find that and it does prove to be true, then it would be interesting to always use at least 24bit quality when decoding.

madshi

18th August 2010, 13:26

reclock esque features.
Cool, but I hope that will just be an option and not forced on... ;)

I'm having trouble googling the source, but i remember tests on audio cd and dts tracks that digitally proved that decoding them with 24bit presision slightly improved the amount of data that could be recovered, especially near the noise floor.
@tetsuo, no offense, but you're not making much sense here. Look: There are lossy formats and lossless formats. I hope you understand the difference? Lossy formats are usually stored in the frequency domain, while lossless formats are usually simple PCM compression algorithms. Which means that the native bitdepth of a lossy decoder is usually floating point, while the native output of a lossless decoder is usually integer PCM. As I said before, every decoder should output its native bitdepth. Now let's talk about the 2 examples you mentioned:

(1) Audio CDs are not compressed at all. So no decoder is involved. It doesn't make sense to talk about "decoding" here. Audio CDs are 16bit. You can't "decode them with 24bit precision". End of story. Unless you're talking HDCD, but let's not go there.

(2) DTS is a lossy format (exception: DTS-HD Master Audio). Which means that the native decoder output is floating point.

Your post throws Audio CDs and DTS tracks together, while actually they're as much different as they could possibly be. Audio CDs are 16bit integer PCM. Lossy DTS tracks should be decoded to floating point.

tetsuo55

18th August 2010, 13:35

Your post is very clear, that means we're not talking about decoding but dithering.

Dithering a 16bit uncompressed stream to 24 bit brings the audio closer to a native 24bit recorded track in a digital double blind test (for which im totally failing to find the source)

madshi

18th August 2010, 13:42

Dithering is used for *reducing* bitdepth, not for increasing it.

tetsuo55

18th August 2010, 13:44

i guess i totally need to find that source to take this any further.

nevcairiel

18th August 2010, 13:50

Hey guys,

I had posted a few days ago about the forced subtitle track flag not being respected by MPC for mkvs - http://forum.doom9.org/showpost.php?p=1426246&postcount=13944

I just wanted to confirm if this is a known issue?

Sadly, due to the design of the Gabest MKV Splitter, it simply cannot respect those flags. It doesn't decide which subtitles get used, because it simply exposes all streams as a seperate pin, and an external subtitle renderer will have to grab all streams and pick one to play - and the flags are lost on this transition.

The new splitter will respect the flags, once implemented, that is.

dbone1026

18th August 2010, 13:53

Sadly, due to the design of the Gabest MKV Splitter, it simply cannot respect those flags. It doesn't decide which subtitles get used, because it simply exposes all streams as a seperate pin, and an external subtitle renderer will have to grab all streams and pick one to play - and the flags are lost on this transition.

The new splitter will respect the flags, once implemented, that is.

Thanks for the update

XhmikosR

18th August 2010, 14:07

Thanks to heksesang, all known crashes with the MSVC2010 builds should be fixed in r2267 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=2267).
Please everyone try the r2267 MSVC2010 builds from the link in my signature and report back.

tetsuo55

18th August 2010, 14:15

Dithering is used for *reducing* bitdepth, not for increasing it.I'm unable to find anything about it anymore so in conclusion:

-lossy codecs should be decoded with 32bit float accuracy (this is already the case)
-Lossless PCM streams should not be touched in any way
-If any content happens to be 32bit/float it should be dithered down to 24/int

Agreed?
i guess thats what you already do with eac3to

Thanks to heksesang, all known crashes with the MSVC2010 builds should be fixed in r2267 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=2267).
Please everyone try the r2267 MSVC2010 builds from the link in my signature and report back.

That was unexpected, i see he asked microsoft and they gave the solution :D, and how deceptively simple to solve too.

madshi

18th August 2010, 14:20

I'm unable to find anything about it anymore so in conclusion:

-lossy codecs should be decoded with 32bit float accuracy (this is already the case)
32bit float or 64bit float, yes. Currently libav *internally* decodes this way, but still truncates the output to 16bit integer. So no, this is not already the case, for most decoders, with the official ffmpeg SVN.

-Lossless PCM streams should not be touched in any way
Correct. Unless you need to do processing, of course (like channel mixing or ReClock like stuff).

-If any content happens to be 32bit/float it should be dithered down to 24/int
Correct. Float can be 32bit or 64bit, though.

i guess thats what you already do with eac3to
Yes.

GTPVHD

18th August 2010, 14:21

MSVC2010 2267 build crashes on XP SP3 when trying to play anything, MKV, MP4, AVI etc.
MSVC2008 build works without issues.

http://img714.imageshack.us/img714/1462/crash2267.png

Application exception occurred:
Exception number: c000001d (illegal instruction)

XhmikosR

18th August 2010, 14:23

MSVC2008 build works though, right? Try backing up your settings and delete the following reg key
HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\ToolBars

Personally I don't have any crashes and I've tried all the combinations that before caused a crash.

GTPVHD

18th August 2010, 14:27

Same, still crashes after deleting the registry key.

XhmikosR

18th August 2010, 14:29

Then it's something specific on your machine. No one else can reproduce any crashes with r2267 on XP or Windows 7 so far.

MPC-HTPC

18th August 2010, 14:31

I can verify the issues reported by GTPVHD on WinXP SP3. The MSVC 2008 build from r2267 works fine. The MSVC 2010 build crashes, when trying to play a file (I also tried to delete the mentioned Reg-Key).

At least all other issues of the MSVC 2010 build do not occur anymore. Many thanks to heksesang for solving this!!! :)

tetsuo55

18th August 2010, 14:32

GTPVHD, try deleting all the ini and registry settings, and make sure the playlist and shaderlist are docked in their default positions

tetsuo55

18th August 2010, 14:33

32bit float or 64bit float, yes. Currently libav *internally* decodes this way, but still truncates the output to 16bit integer. So no, this is not already the case, for most decoders, with the official ffmpeg SVN.

Correct. Unless you need to do processing, of course (like channel mixing or ReClock like stuff).

Correct. Float can be 32bit or 64bit, though.

Yes.Does your ffmpeg patch make it behave exactly like this?