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

[clsid]

Wow, those are some useful fixes. Best and quickest way to get them applied would be to contact Casimir666 (the main dev).

[clsid]

Yes, but you asked jffulcrum a question which was answered in my post. My post was posted twice, and jffulcrum's post was a reply to my post.You assume jffulcrum's problem has the exact same cause, which is not necessarily true.
In all three of the problems I've posted over the past year that no one has responded to, I have already played the file in another player before posting, so I don't need help.It means nobody knows a solution or they simply don't care. The more details you supply, the bigger chance somebody can help.
For a program to be quality, bugs need to have higher priority than new features. I appreciate that all the development is by kind volunteer effort, but fixing bugs and reading bug reports needs to have a better system than "whatever posts happens to be noticed because they are interesting".Now only if people would also submit proper bug reports.

I don't decode DTS, all 5.1 is passed to the receiver intact on the SPDIF by "SPDIFER" open source filter. Vorbis is decoded to PCM, and PCM is handled by "ACFILTER" open source filter. I am not sure how dual audio is suppoed to work, either all the filters are supposed to be loaded at startup for all audio, or else changing audio in Haali is supposed to cause different filters to be loaded, but neither is happening.SPDIF is the cause...
It is not really a bug in MPC or Haali Media Splitter, it is rather more a limitation of DirectShow.
Haali dynamically changes the decoding filter in the filter graph. The benefit of that is that only one decoder will be loaded at a time. Downside is that changing audio will cause MPC's internal switcher to disappear from the graph. Not really a big deal, unless you use it for volume normalization or channel remapping.
MPC's internal splitter simply exposes all audio pins and thus it loads several decoders. The audio switcher connects to all of their output pins and makes sure that only one is active. The audio switcher connects to the audio renderer. If you then switch to a decoder that uses SPDIF, things go wrong.

[Beliyaal]

I might be jumping ahead a bit, but all the problems you found and fixed might be effecting some(or even all) other renderers.
Have you had a chance to look at those?


Some of the fixes are implemented in the VMR9 renderer as the EVR inherits from. I could try to implement all fixes in VMR9 as well. Would it be worth the effort to implement them in any other renderer?

[tetsuo55]

Some of the fixes are implemented in the VMR9 renderer as the EVR inherits from. I could try to implement all fixes in VMR9 as well. Would it be worth the effort to implement them in any other renderer?

Actually all the renderers are usefull to some people.
But if you could completely fix VMR9 i think the other ones would become obsolete (a lot of people are forced to use VMR7 due to problems with VMR9)

For completeness sake it would be "nice" to have them all fixed, i suggest focusing on VMR9 and EVR only for the moment though

[Leak]

Actually all the renderers are usefull to some people.
But if you could completely fix VMR9 i think the other ones would become obsolete (a lot of people are forced to use VMR7 due to problems with VMR9)

For completeness sake it would be "nice" to have them all fixed, i suggest focusing on VMR9 and EVR only for the moment though
I concur. VMR9 is the default renderer for Windows XP (and VMR is the only renderer where DXVA is guaranteed to work) so it's widely used, I think - not to mention that you have to install .NET 3 and regsvr32 a DLL to use EVR on XP... :)

np: Other People's Children - Suicide Common (A Number Of Small Things (Disc 2))

[Casimir666]

Hello everyone, I finally taken the time to setup MPC-HC for development so I can fix a couple of issues that have been irritating me for a long time.
Sound great! All new people who can fix bugs and improve mpc-hc are welcome :-)
Could you send me your patches in PM to have a look on it?



[/INDENT]Why is m_rtTimePerFrame twice the time it should be? Have to divide by 2 on many places?

Do you mean this :


HRESULT CEVRAllocatorPresenter::CreateProposedOutputType(IMFMediaType* pMixerType, IMFMediaType** pType)
{
HRESULT hr;
AM_MEDIA_TYPE* pAMMedia = NULL;
LARGE_INTEGER i64Size;
MFVIDEOFORMAT* VideoFormat;

CheckHR (pMixerType->GetRepresentation (FORMAT_MFVideoFormat, (void**)&pAMMedia));
VideoFormat = (MFVIDEOFORMAT*)pAMMedia->pbFormat;
hr = pfMFCreateVideoMediaType (VideoFormat, &m_pMediaType);

if (VideoFormat->videoInfo.FramesPerSecond.Numerator != 0)
m_rtTimePerFrame = (20000000I64*VideoFormat->videoInfo.FramesPerSecond.Denominator)/VideoFormat->videoInfo.FramesPerSecond.Numerator;

../...


This code works if FramesPerSecond are in "field per second", but it didn't if it's "frames per second" (constant should be 10000000I64 instead of 20000000I64).
Problem :
- MPCVideoDec always set "interleaved" flag in output media type (ffdshow and cyberlink do the same, it's a trick than cannot be changed easily).
EVR automaticaly double the fps in this case, but leave the InterlacedMode to progressive... That the reason some people have noticed a jitter in latest builds.
- Microsoft WindowsMedia DMO decoder didn't set interlaced flag, so my code is wrong.

So yes there is a bug here, another solution should be found to have fps. Did you patch need the exact fps to works? Because until now the only purpose was to display jitter curve.


Is it possible/how to pause sound from EVR? I would need to do this when video is too far behind audio.
The only way i know it to rewrite an audio renderer, and resample sound to follow the video. That's more or less what reclock do.

[tetsuo55]

The only way i know it to rewrite an audio renderer, and resample sound to follow the video. That's more or less what reclock do.

This is interesting, because reclock doesn't work all that great.
I have my display fixed at 60hz, nothing i can do about this, i would like to have the audio resampled to 60hz(or the closest devision) without changing the pitch like reclock does.

[hdboy]

@tetsuox: thanks. i followed your link and did the reg fix, rebooted, but did not help. since i have opposite problem (too dark rather than too high black level), i reversed the setting but still did not help. is there a 0..255->16..235 shader?

[gngn]

DXVA with H.264 videos is broken when playing files that have been encoded different (different ReFrames number) using the ordered chapters .mkv feature. so the first file to start has no playback issues, but when the second/third file is inserted then macroblocking starts. can this be fixed? like reloading the decoder when a new chapter is inserted? but that would then mean a pause in playback of a few seconds .....

[Beliyaal]

Sound great! All new people who can fix bugs and improve mpc-hc are welcome :-)
Could you send me your patches in PM to have a look on it?


I will, after I have implemented everything in VMR9 as well. Do you have a database of sample clips that I could use to make sure that everything is working correctly?


This code works if FramesPerSecond are in "field per second", but it didn't if it's "frames per second" (constant should be 10000000I64 instead of 20000000I64).
Problem :
- MPCVideoDec always set "interleaved" flag in output media type (ffdshow and cyberlink do the same, it's a trick than cannot be changed easily).
EVR automaticaly double the fps in this case, but leave the InterlacedMode to progressive... That the reason some people have noticed a jitter in latest builds.
- Microsoft WindowsMedia DMO decoder didn't set interlaced flag, so my code is wrong.

So yes there is a bug here, another solution should be found to have fps. Did you patch need the exact fps to works? Because until now the only purpose was to display jitter curve.

The only way i know it to rewrite an audio renderer, and resample sound to follow the video. That's more or less what reclock do.
It's mostly for the stats, but it was used in the sync calculation in the EVR code before. Also I used it for setting the subtitle FPS. I guess you could check for the interlaced flag and calculate the frame time correctly?

[Casimir666]

I will, after I have implemented everything in VMR9 as well. Do you have a database of sample clips that I could use to make sure that everything is working correctly?

You could found a lot of sample here :
ftp://samples.mplayerhq.hu

[leeperry]

This is interesting, because reclock doesn't work all that great.
I have my display fixed at 60hz, nothing i can do about this, i would like to have the audio resampled to 60hz(or the closest devision) without changing the pitch like reclock does.
Reclock works perfectly fine, it's just MPC HC that doesn't work well with it(random frame drops, random freezing on seeks, massive frame drops after 45/60' due to poor presenting code apparently).
You can't quite ask for 60Hz w/o changing the pitch...
either you accelerate 23.976fps to 24fps@48Hz/25fps@50Hz, or you live with 24@60 judder :p

if Beliyaal wants to improve Reclock support, I'm sure I can find him some dedicated betatesters :D

[clsid]

@tetsuox: thanks. i followed your link and did the reg fix, rebooted, but did not help. since i have opposite problem (too dark rather than too high black level), i reversed the setting but still did not help. is there a 0..255->16..235 shader?ffdshow has a filter called "levels" that you could use to make that conversion. Of course that would require using ffdshow for decoding/processing, meaning it can't be combined with DXVA.

[tetsuo55]

Reclock works perfectly fine, it's just MPC HC that doesn't work well with it(random frame drops, random freezing on seeks, massive frame drops after 45/60' due to poor presenting code apparently).
You can't quite ask for 60Hz w/o changing the pitch...
either you accelerate 23.976fps to 24fps@48Hz/25fps@50Hz, or you live with 24@60 judder :p

if Beliyaal wants to improve Reclock support, I'm sure I can find him some dedicated betatesters :D

In my case it either says that it cannot work and remains red, or it works and its like i'm watching alvin and the chipmunks

In my book thats broken :D

My problem is:
screen = 60HZ
Media is 23.97, 24, 25 and 30.

So what i need is:
Any > 30, without pitch resampling

[Beliyaal]

Reclock works perfectly fine, it's just MPC HC that doesn't work well with it(random frame drops, random freezing on seeks, massive frame drops after 45/60' due to poor presenting code apparently).
You can't quite ask for 60Hz w/o changing the pitch...
either you accelerate 23.976fps to 24fps@48Hz/25fps@50Hz, or you live with 24@60 judder :p

if Beliyaal wants to improve Reclock support, I'm sure I can find him some dedicated betatesters :D

I have just tried Reclock and it seems to be working really well with the new sync code. Even fixes the unstable DTS clock on ATI cards when you pass spdif through it.

[Beliyaal]

In my case it either says that it cannot work and remains red, or it works and its like i'm watching alvin and the chipmunks

In my book thats broken :D

My problem is:
screen = 60HZ
Media is 23.97, 24, 25 and 30.

So what i need is:
Any > 30, without pitch resampling

At least in the latest beta of Reclock it stretches instead of pitiching the sound. Although this isn't ideal either. If you really want to fix it without changing the sound you will just have to resample the video instead.

I have long been thinking about if it would be possible to do this with motion detection. Maybe if you do the motion detection off line and have it as a separate stream it could be feasible with good quality :)

[leeperry]

I have just tried Reclock and it seems to be working really well with the new sync code. Even fixes the unstable DTS clock on ATI cards when you pass spdif through it.
well it can't get any worse I'd say :D j/k
the biggest problem was random freezing on seeks, it's been reproduced on many different computers in either VMR/EVR or HR..open a bunch of files and seek a lot, it will happen, eventually.

then we got the random drop problem in VMR9/EVR, this is what JohnAd told me about it :

EVR is sensitive to the time taken on the longest frames, the default implementation it is not very compatible with software processing on compressed material as you need to keep well under 40ms per frame peak, this can and should be handled outside the renderer.

and last issue, reproduced by many ppl as well : run a 23.976 movie at 47.952/48.000Hz in custom EVR/VMR9, enable the CTRL+J infos.....wait 45/60' and it will drop frames like crazy.

apparently it's due to the same problem JohnAd told me about....this doesn't happen with HR ;)

[Beliyaal]

well it can't get any worse I'd say :D j/k
the biggest problem was random freezing on seeks, it's been reproduced on many different computers in either VMR/EVR or HR..open a bunch of files and seek a lot, it will happen, eventually.


Will check if I can reproduce.

then we got the random drop problem in VMR9/EVR, this is what JohnAd told me about it :

and last issue, reproduced by many ppl as well : run a 23.976 movie at 47.952/48.000Hz in custom EVR/VMR9, enable the CTRL+J infos.....wait 45/60' and it will drop frames like crazy.

apparently it's due to the same problem JohnAd told me about....this doesn't happen with HR ;)

These problems should be fixed. Processing has been moved to a new thread, and the old code wasn't even able to drop frames, it just said it did but didn't.

Not sure what you mean by wait 45/60?

[shaolin95]

I dont understand this guys. I use EVER Cust under Vista 64 and I dont get any dropped frames unless I skip back and forth and its just in order to resync.

[leeperry]

Will check if I can reproduce.

These problems should be fixed. Processing has been moved to a new thread, and the old code wasn't even able to drop frames, it just said it did but didn't.

Not sure what you mean by wait 45/60?
45/60 mins
it will start nicely at 24.000 in the CTRL+J infos(with 48.000Hz in Reclock), then it will drop frames from time to time(eg. you get a small wave in the jitter infos)....then after 45/60 minutes it will get worse and worse and drop frames constantly, requiring a reseek :eek:

ideally it shouldn't drop frames AT ALL...HR doesn't :)

Apparently using MPC HC in exclusive D3D mode would fix this problem, but this is not convenient for everyday use...plus if you enable the CTRL+J infos you still get big waves from time to time and it's not dead on 24.000

I dearly hope that you'll be able to reproduce the random freezing problem on seeks, as it's really the biggest issue right now with using Reclock in MPC HC :o

:thanks:

[sneaker_ger]

Does anybody else have a problem with playing DVDs using Haali's Renderer? MPC-HC always crashes - it does not matter wether I open DVD files from HDD or from DVD-Drive.

[cca]

Before Beliyaal starts looking into other stuff, like reclock problems, I would suggest to submit the already working code so that more people can beta test it. There are too many variations in hardware and software configurations, so these patches need testing.

[ByeByeBluRay]

Hello everyone, I finally taken the time to setup MPC-HC for development so I can fix a couple of issues that have been irritating me for a long time.

That's some awesome work - what a great contribution :-)

I too would like to add a little - just a few extra commands to the MpcApi interface, but I'm having trouble building the code. I presume I need to revert to the June 2007 version of DirectX, because later ones don't have d3d.h, but now I'm stuck on libavcodec_gcc.lib - where did you get it, or how is it built? And if it's built with gcc, why can't it be built with VS2008?

Thanks

BBBR

[bmnot]

Is there a reason PGS subtitles do not work AT ALL with v952? Was using v908 previously and subs worked fine most of the time. I'd like to use a newer version for the VC1 playback fixes.

[yesgrey]

So what i need is:
Any > 30, without pitch resampling

Well, so you should use this:
http://www.prosoniq.com/main/timefactory-2-windows/

but it's not for real-time...

[hdboy]

feature request: i just found the "full screen monitor" feature, which is very useful for dual monitor htpc setup. what i like to see is a shortcut key for "full screen w/ no monitor change", i.e. go full screen on this monitor, overriding the "full screen monitor" setting.

[ADude]

It is not really a bug in MPC or Haali Media Splitter, it is rather more a limitation of DirectShow.
Haali dynamically changes the decoding filter in the filter graph. The benefit of that is that only one decoder will be loaded at a time. Downside is that changing audio will cause MPC's internal switcher to disappear from the graph. Not really a big deal, unless you use it for volume normalization or channel remapping.
MPC's internal splitter simply exposes all audio pins and thus it loads several decoders. The audio switcher connects to all of their output pins and makes sure that only one is active. The audio switcher connects to the audio renderer. If you then switch to a decoder that uses SPDIF, things go wrong.

Halli Splitter does not change the filter that is loaded when I switch from default Vorbis audio track to the DTS audio track. This is the same whether Internal Audio Switcher is enabled or not.

Is there any other MKV splitter that can handle two audio streams ?

PS I previously had a problem with Haali Splitter, posted a thread in Doom9 and zero replies...

[madshi]

Hello everyone, I finally taken the time to setup MPC-HC for development so I can fix a couple of issues that have been irritating me for a long time.
Awesome!

[INDENT]The sync for the custom EVR was practically nonexistent. Aside from being unable to drop frames when the movie fps is about equal to the screen refresh it also uses a non-robust method for syncing.

I have now fixed the sync to be as perfect as is possible. For example when you run a 23.976 movie in 24 fps instead of stuttering several frames as the Haali renderer does it only stutters once to fix the sync.
Some of the fixes are implemented in the VMR9 renderer as the EVR inherits from. I could try to implement all fixes in VMR9 as well. Would it be worth the effort to implement them in any other renderer?
Would it be possible to fix the Haali renderer, too? Or is the stuttering code inside of the Haali renderer, so that you can't fix it? Generally I like the idea of the Haali renderer. It simply bypasses all the ugly graphics manufacturers' ideas of how video could be "optimized" by not using the usual video pipeline. It's also the only way I can get proper BTB and WTW with my ATI card. So if you could optimize the Haali Renderer, as well, as that would be much appreciated!

Thanks!

* Add support for automatically changing the number of audio output channels based on content. This is because my receiver requires the correct number of channels to use the correct expansion modes to 7.1.
Do you mean for LPCM transport over HDMI? And your change would result in that the receiver correctly detects e.g. 2.0 for stereo content, 5.1 for 5.1 content, 6.1 for 6.1 content and 7.1 for 7.1 content? That would be VERY nice, if possible!

Is it possible/how to pause sound from EVR? I would need to do this when video is too far behind audio.
Too far behind because the decoder isn't fast enough? Or too far behind due to audio and video clocks differing? The first case is very bad and I don't see any good way to solve it. In the 2nd case can't you repeat video frames to match video/audio back together? I'm aware that this will likely cause visible stuttering. But that's the same we get if video comes in too fast, compared to audio, right? I think I'd prefer that over manipulating the audio data...

Another option would be to write an Audio Renderer (as Casimir has suggested). But I'm thinking: It should also be possible to write an intermediate filter which accepts PCM, DTS, AC3 etc and outputs them again. Such an intermediate filter would that manipulate the audio data as needed (while communicating with the video renderer). Should work just fine, too. But manipulating audio data is not pretty. If you do bitstream, you can only repeat/drop full audio frames, which can be very clearly audible (especially during dialog and music). With PCM it's a bit better, but still it's not easy. You can resample (which changes the pitch) or you can try to stretch somehow without changing the pitch (which can introduce artifacts on its own). But I really don't like the general idea of tampering around with audio, after we spent so much money and space on getting lossless audio from Blu-Ray. One tiny video stutter every few minutes would be preferable in my opinion. And it might not even be noticed at all, if it happens to happen in a scene where there's not much motion.

Anyway, this is just my opinion...

[professor_desty_nova]

I have a DVR I use to record from TV, and the media I use to record makes a diference to MPC-HC. If I burn something to a DVD-R, I can seek the video, but if I burn the same thing to a DVD+R I can't seek it. This happens in MPC-HC (1.2.908.0 and the latest 948) and MPC. There is though a difference between the DVD-R and the DVD+R. The DVD-R has a VIDEO_TS folder, but the DVD+R has a VIDEO_TS and a VIDEO_RM folders. Could this be the cause?
Here are samples of the same clip recorded to DVD-R and DVD+R.
http://www.mediafire.com/?nmiymjnuin3
http://www.mediafire.com/?y1ozgzmdy1z
Hope this helps finding the problem.

PS: I can seek the DVD+R in PowerDVD and VLC, but I prefer using MPC-HC/MPC ;).

[leeperry]

Would it be possible to fix the Haali renderer, too? Or is the stuttering code inside of the Haali renderer, so that you can't fix it?
what is wrong with HR ? I use it all the time with Reclock(and so do many friends of mine), it never drops frames and never stutters.
Another option would be to write an Audio Renderer (as Casimir has suggested).
a new Reclock basically ? if that's because you guys are losing A/V sync after a while, doesn't Reclock in "original speed" fix the problem ?
you can't play 24 fps in 60Hz smoothly, but Reclock can still sync the A/V frames AFAIK.

[Mark_A_W]

Does anybody else have a problem with playing DVDs using Haali's Renderer? MPC-HC always crashes - it does not matter wether I open DVD files from HDD or from DVD-Drive.


Are you running Vista?

I get a macrovision error trying to play DVDs with Haali Renderer in Vista. No matter what decoder I use, and I am running anydvd.

It works in XP (I think..).

[madshi]

what is wrong with HR ? I use it all the time with Reclock(and so do many friends of mine), it never drops frames and never stutters.
With ReClock maybe. Beliyaal reported problems when graphics card output refresh rate doesn't 100% match source frame rate. Probably without ReClock.

a new Reclock basically ? if that's because you guys are losing A/V sync after a while, doesn't Reclock in "original speed" fix the problem ?
you can't play 24 fps in 60Hz smoothly, but Reclock can still sync the A/V frames AFAIK.
I'm not a fan of ReClock because it *constantly* manipulates the audio data. I don't consider that a good idea. Plus, ReClock doesn't work very well with bitstream audio (audible artifacts). I'd prefer a solution which keeps its hands of video/audio data as long as possible, and only does something to bring sync back in line when it's really necessary (e.g. sync mismatch > 50ms). And I prefer manipulating video playback instead of audio.

My way of thinking comes from that I really try to match audio and video clocks as good as possible. So the clock difference is really minor in my case. As a result the constant audio data manipulation of ReClock is just not needed. Maybe I need a dropped/repeated video frame once or twice in a movie. I'd much prefer that over constant resampling/stretching of the audio data throughout the whole movie...

[leeperry]

With ReClock maybe. Beliyaal reported problems when graphics card output refresh rate doesn't 100% match source frame rate. Probably without ReClock.

I'm not a fan of ReClock because it *constantly* manipulates the audio data. I don't consider that a good idea. Plus, ReClock doesn't work very well with bitstream audio (audible artifacts). I'd prefer a solution which keeps its hands of video/audio data as long as possible, and only does something to bring sync back in line when it's really necessary (e.g. sync mismatch > 50ms). And I prefer manipulating video playback instead of audio.

My way of thinking comes from that I really try to match audio and video clocks as good as possible. So the clock difference is really minor in my case. As a result the constant audio data manipulation of ReClock is just not needed. Maybe I need a dropped/repeated video frame once or twice in a movie. I'd much prefer that over constant resampling/stretching of the audio data throughout the whole movie...
getting smooth playback w/o resampling and w/o changing the playback speed on a Windows PC would require a miracle I think :D

you can still output 47.952Hz and use Reclock in pass-through S/PDIF mode.....or better get a RME soundcard and change the masterclock speed in its drivers(no resampling!)

quite frankly yesgrey3 has been constantly updating the Reclock resampler, and the latest version in "excellent" mode is both very CPU efficient & very good sounding :)

I personally don't find dropping/duping frames acceptable, and I'm not the only one ;)

Reclock+HR in 48Hz is where HTPC's shine! no dropped frame WHATSOEVER & perfectly butter smooth playback :cool:

[Mark_A_W]

I personally don't find dropping/duping frames acceptable, and I'm not the only one ;)


And I'm another. Reclock sounds BETTER than the other audio renderers on my system due to Kernel streaming (well, it did on XP, but I'm not so sure about Vista).

But thank you for eac3to Madshi - we'd be screwed without it :)

[tetsuo55]

I agree with madshi,

We should focus on aligning the clocks as best as possible.
After the aligning something like reclock can be used to fix any desyncs that are left over.

Like madshi i would prefer that this would only kick in when needed(if there are no artifacts i don't mind if either video or audio are adjusted).

MPC could check the video clock and the audio clock and sync the audio and video stream to those clocks before sending the signals out.

[sneaker_ger]

Are you running Vista?

I get a macrovision error trying to play DVDs with Haali Renderer in Vista. No matter what decoder I use, and I am running anydvd.

It works in XP (I think..).

I'm running Windows XP SP3 and it crashes both on original DVDs and on decrypted/self created ones.

[Beliyaal]

Now I'm stuck on libavcodec_gcc.lib - where did you get it, or how is it built? And if it's built with gcc, why can't it be built with VS2008?


I gave up trying to get MinGW functional. I just changed the project to use VS2008 in release as well as debug. The reason GCC is used is because asm optimization only works there, but because I don't use the internal decoders it doesn't matter for me. Also it's useful to have a slow decoder so you can test when the render is starved :)


Would it be possible to fix the Haali renderer, too? Or is the stuttering code inside of the Haali renderer, so that you can't fix it? Generally I like the idea of the Haali renderer. It simply bypasses all the ugly graphics manufacturers' ideas of how video could be "optimized" by not using the usual video pipeline. It's also the only way I can get proper BTB and WTW with my ATI card. So if you could optimize the Haali Renderer, as well, as that would be much appreciated!

I'm not sure, but i think the source for Haali render is closed, so I wouldn't be able to fix it? I'm not sure what BTB and WTW means, but I might be able to fix it in the VMR9 and EVR renderes.


Do you mean for LPCM transport over HDMI? And your change would result in that the receiver correctly detects e.g. 2.0 for stereo content, 5.1 for 5.1 content, 6.1 for 6.1 content and 7.1 for 7.1 content? That would be VERY nice, if possible!

Yes exactly, I guess that the best bet here is creating a new audio render with WASAPI exclusive mode in Vista, if this doesn't work I would simply change the output mode configured in Windows.


Too far behind because the decoder isn't fast enough? Or too far behind due to audio and video clocks differing? The first case is very bad and I don't see any good way to solve it. In the 2nd case can't you repeat video frames to match video/audio back together? I'm aware that this will likely cause visible stuttering. But that's the same we get if video comes in too fast, compared to audio, right? I think I'd prefer that over manipulating the audio data...

The case where it was a problem was when the decoder wasn't fast enough. I managed to fix this yesterday after much head scratching with EC_STARVING and overriding the GetState method of the OuterEVR (took a while to figure out this was needed).

My way of thinking comes from that I really try to match audio and video clocks as good as possible. So the clock difference is really minor in my case. As a result the constant audio data manipulation of ReClock is just not needed. Maybe I need a dropped/repeated video frame once or twice in a movie. I'd much prefer that over constant resampling/stretching of the audio data throughout the whole movie...
You will be happy to know I feel exactly the same way and will work toward making it as good as possible.

getting smooth playback w/o resampling and w/o changing the playback speed on a Windows PC would require a miracle I think :D

you can still output 47.952Hz and use Reclock in pass-through S/PDIF mode.....or better get a RME soundcard and change the masterclock speed in its drivers(no resampling!)

quite frankly yesgrey3 has been constantly updating the Reclock resampler, and the latest version in "excellent" mode is both very CPU efficient & very good sounding :)

I personally don't find dropping/duping frames acceptable, and I'm not the only one ;)

Reclock+HR in 48Hz is where HTPC's shine! no dropped frame WHATSOEVER & perfectly butter smooth playback :cool:
Even in "Original speed" mode when rendering spdif data it will drop and add audio frames and slightly change the speed of the audio. If it didn't it would be perfect, unfortunately it's not open source so I can't go in and fix the issues or add WASAPI exclusive mode. It also fails to reliably detect my refresh rate. The only feature that I need from it is it's ability to fix the broken ATI DTS passthrough clock and possibly 25->24 fps movie conversion. Reclock seems to cause many other issues so it might be good to have a new audio render that only does the least amount of damage to the sound.

Some more updates:
* Managed to fix pausing of the graph with EC_STARVING as mentioned above.
* VMR9 renderer doesn't handle sync itself so it's more work to add the other fixes than I originally though. It should be possible however as the Haali renderer seems to handle it itself. Will look at this later.
* Fixed rtTimePerFrame detection by using the VMR9 method as the Media Foundation api seems to be broken and it doesn't correctly report the interlace flags.
* There is still some issues that I have found that I want to fix before submitting code.
* Found the Reclock deadlock and implemented a workaround.

[madshi]

getting smooth playback w/o resampling and w/o changing the playback speed on a Windows PC would require a miracle I think :D
I'm not sure about that. We have HDMI output now which combines video + audio. I'd imagine that the audio and video clock are now related somewhat, because the audio is sent over HDMI in between the pictures. I don't know for sure how the audio clock is created by those HDMI enabled audio devices, though...

quite frankly yesgrey3 has been constantly updating the Reclock resampler, and the latest version in "excellent" mode is both very CPU efficient & very good sounding :)
Resampling audio is similar to not having 1:1 pixel mapping, regardless of how good a resampler you're using.

I personally don't find dropping/duping frames acceptable, and I'm not the only one ;)
I don't like it, either, but if there's only one or two frame drops/duplicates per movie then I like that a lot better than having all audio manipulated *all the time*.

Reclock+HR in 48Hz is where HTPC's shine! no dropped frame WHATSOEVER & perfectly butter smooth playback :cool:
You're drooling over how good video is then. That's fine. But your audio is being resampled all the time. Maybe you're not bothered by that, but I am.

And I'm another. Reclock sounds BETTER than the other audio renderers on my system due to Kernel streaming (well, it did on XP, but I'm not so sure about Vista).
Now that you mention it, I'd *love* to have an audio renderer which works like any other audio renderer, but uses kernel streaming. Something like ReClock, but without all the audio manipulation stuff...

[THX-UltraII]

How does a dedicated HTPC with top notch hard- and software (software MPC HC edition, ReClock, Core AVC 1.8.5, Haali splitter) compares to the WD HD TV device if we ONLY look at the sound and picture QUALITY? (so NOT look at price, design, comfort, compatibility etc).

Which one has the best picture and audio quality?

[madshi]

I'm not sure, but the source for Haali render is closed, so I wouldn't be able to fix it? I'm not sure what BTB and WTW means, but I might be able to fix it in the VMR9 and EVR renderes.
If the problem is inside the Haali Renderer then you can't fix it. I thought maybe it's in the MPC code calling the Haali Renderer. Well, seemingly not.

BTB and WTW means "blacker than black" and "whiter than white". With RGB video there are two different "levels", either "PC levels" or "video levels". When using PC levels, black is RGB "0, 0, 0" and white is "255, 255, 255". With video levels, black is "16, 16, 16" and white is "235, 235, 235", IIRC. The values below 16 are BTB. Now ATI is doing some ugly stuff in their drivers. With VMR9 and EVR regardless of what I do, all values below "16, 16, 16" are clipped by the ATI driver. Which is already bad in itself. But it's also bad because it means that the ATI driver internally stretches the YCbCr data coming from the decoder to PC levels and then later converts PC levels to video levels. Doing that can introduce banding problems. The Haali Renderer bypasses all this ATI driver sh*t by pretending to not display video but by displaying games (I think). So ATI isn't tempted to do violence to the "video" data, anymore. The nice thing about the Haali Renderer is that is bypasses all these ugly video manipulations (face color "improvements", non-defeatable noise "reduction" and detail "enhancement", color "correction", etc etc etc) which otherwise are hard or even impossible to turn off. That isn't limited to ATI, NVidia and Intel also have similar problems, but not as bad as ATI, I think.

Yes exactly, I guess that the best bet here is creating a new audio render with WASAPI exclusive mode in Vista, if this doesn't work it would simply change the output mode configured in Windows.
That would be VERY nice. I had already thought about this problem, too, and wondered about how to fix it. I was thinking about changing output modes in the OS settings programmatically. But if you can do it inside of the audio renderer, that would be of course much better. BTW, how much time do you have for working on MPC? I'm asking because writing an audio renderer is probably quite complex, from what I've seen in the MSDN documentation, because the audio renderer is the one responsible for the clock of the whole DirectShow graph. Of course writing an audio renderer gives you the most control you can get, so it is tempting... :)

You will be happy to know I feel exactly the same way and will work toward making it as good as possible.
I am! I'm also happy to see that you seem to be working on exactly the "right things", from my point of view, to make MPC HC the ultimate home cinema playback solution... :)

[_xxl]

I gave up trying to get MinGW functional. I just changed the project to use VS2008 in release as well as debug. The reason GCC is used is because asm optimization only works there, but because I don't use the internal decoders it doesn't matter for me. Also it's useful to have a slow decoder so you can test when the render is starved.
You could download MinGW GCC from here:
http://www.zshare.net/download/508393404da13508/
or here:
http://forum.doom9.org/showthread.php?t=123537

[Beliyaal]

If the problem is inside the Haali Renderer then you can't fix it. I thought maybe it's in the MPC code calling the Haali Renderer. Well, seemingly not.

BTB and WTW means "blacker than black" and "whiter than white". With RGB video there are two different "levels", either "PC levels" or "video levels". When using PC levels, black is RGB "0, 0, 0" and white is "255, 255, 255". With video levels, black is "16, 16, 16" and white is "235, 235, 235", IIRC. The values below 16 are BTB. Now ATI is doing some ugly stuff in their drivers. With VMR9 and EVR regardless of what I do, all values below "16, 16, 16" are clipped by the ATI driver. Which is already bad in itself. But it's also bad because it means that the ATI driver internally stretches the YCbCr data coming from the decoder to PC levels and then later converts PC levels to video levels. Doing that can introduce banding problems. The Haali Renderer bypasses all this ATI driver sh*t by pretending to not display video but by displaying games (I think). So ATI isn't tempted to do violence to the "video" data, anymore. The nice thing about the Haali Renderer is that is bypasses all these ugly video manipulations (face color "improvements", non-defeatable noise "reduction" and detail "enhancement", color "correction", etc etc etc) which otherwise are hard or even impossible to turn off. That isn't limited to ATI, NVidia and Intel also have similar problems, but not as bad as ATI, I think.

This must be the D3DPRESENTFLAG_VIDEO flag. We should be able to add an option to turn this flag off, this should have the same effect as the Haali renderer.

BTW, how much time do you have for working on MPC? I'm asking because writing an audio renderer is probably quite complex, from what I've seen in the MSDN documentation, because the audio renderer is the one responsible for the clock of the whole DirectShow graph. Of course writing an audio renderer gives you the most control you can get, so it is tempting... :)

Not sure, but I guess that I could spend at least a weekend trying. I have written a whole software sound mixer/engine with 3D and reverb etc support for a game engine (PC, PS3 and Xbox 360) before, so I think I can manage. :)

[Beliyaal]

You could download MinGW GCC from here:
http://www.zshare.net/download/508393404da13508/
or here:
http://forum.doom9.org/showthread.php?t=123537

I got that far, but couldn't get it to build successfully. Something about make toolchain I think. When I have time later I will try to figure it out, and also I'm thinking about integrating the gcc build process from Visual Studio.

A step by step guide of how to setup the build environment with the various libraries etc for building would be great for reducing the barrier of entry for contributing to MCP-HC!

[boyumeow]

@Beliyaal

U could try http://sourceforge.net/project/showfiles.php?group_id=200665 for latest MinGW GCC 4.3.2 tdm. Glad U have decided to help out MPC-HC team. Thanks.

[madshi]

This must be the D3DPRESENTFLAG_VIDEO flag. We should be able to add an option to turn this flag off, this should have the same effect as the Haali renderer.
To be honest, I've never looked in detail at how renderers work, so I can't really say much about it. But I guess if you use EVR or VMR, the graphics driver will know that it's video regardless of whether the D3DPRESENTFLAG_VIDEO flag is set or not. So I'd guess that all the bad driver manipulations probably depend on whether EVR/VMR is used and not on the D3DPRESENTFLAG_VIDEO flag. Haali uses neither EVR nor VMR, so the graphics driver thinks a game is being played...

Not sure, but I guess that I could spend at least a weekend trying. I have written a whole software sound mixer/engine with 3D and reverb etc support for a game engine (PC, PS3 and Xbox 360) before, so I think I can manage. :)
Cool. Well, we will take whatever you can give us, of course... :)

[clsid]

I too would like to add a little - just a few extra commands to the MpcApi interface, but I'm having trouble building the code. I presume I need to revert to the June 2007 version of DirectX, because later ones don't have d3d.h, but now I'm stuck on libavcodec_gcc.lib - where did you get it, or how is it built? And if it's built with gcc, why can't it be built with VS2008?VS2008 does not support the inline assembly that libavcodec contains. You need to build it with MinGW GCC to get decent decoding performance. You can find an easy to use installer for MinGW in the first post of the large ffdshow topic.

[clsid]

Halli Splitter does not change the filter that is loaded when I switch from default Vorbis audio track to the DTS audio track. This is the same whether Internal Audio Switcher is enabled or not.

Is there any other MKV splitter that can handle two audio streams ?

PS I previously had a problem with Haali Splitter, posted a thread in Doom9 and zero replies...
It probably does not work due to SPDIFER. Have you tried without it?

[Beliyaal]

To be honest, I've never looked in detail at how renderers work, so I can't really say much about it. But I guess if you use EVR or VMR, the graphics driver will know that it's video regardless of whether the D3DPRESENTFLAG_VIDEO flag is set or not. So I'd guess that all the bad driver manipulations probably depend on whether EVR/VMR is used and not on the D3DPRESENTFLAG_VIDEO flag. Haali uses neither EVR nor VMR, so the graphics driver thinks a game is being played...

I have investigated this now and in ATI drivers > 8.10 the video controls works ONLY when rendering with DXVA. I might be wrong but Haali renderer does not support DXVA? In that case you shouldn't have any problems if you use newest ATI drivers and disable the DXVA codecs. Also as you said the D3DPRESENTFLAG_VIDEO doesn't have any effect. It might in older ATI drivers though that works through the presented surface instead of in the DXVA decoder.

[tetsuo55]

I have investigated this now and in ATI drivers > 8.10 the video controls works ONLY when rendering with DXVA. I might be wrong but Haali renderer does not support DXVA? In that case you shouldn't have any problems if you use newest ATI drivers and disable the DXVA codecs. Also as you said the D3DPRESENTFLAG_VIDEO doesn't have any effect. It might in older ATI drivers though that works through the presented surface instead of in the DXVA decoder.

Does adding the presentflag to all renderers cause consistent behaviour regardless of DXVA? (Currently all renderers behave differently)

[STaRGaZeR]

I have investigated this now and in ATI drivers > 8.10 the video controls works ONLY when rendering with DXVA. I might be wrong but Haali renderer does not support DXVA? In that case you shouldn't have any problems if you use newest ATI drivers and disable the DXVA codecs. Also as you said the D3DPRESENTFLAG_VIDEO doesn't have any effect. It might in older ATI drivers though that works through the presented surface instead of in the DXVA decoder.

In my experience the video controls only work when you feed the renderer with the NV12 colorspace. Of course it works with DXVA, because DXVA needs NV12 to work. I don't know about Haali's renderer, but with EVR is like that. That's also the reason why Microsoft's decoders output NV12.