Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018] - Page 125

Zachs · 20th June 2015, 12:50

Btw set video specifier to "p23" and it'll do exactly what you said. Then in your calculator, use the perfect value of 23.976.

huhn · 20th June 2015, 13:05

Quote:

Originally Posted by Zachs

This changes the audio clock in case you haven't noticed. That's why I told you there's no resampling.

and changing the audio clock is save to do? changing the video clock is not 100% save.

i mean it can change the audio clock by a lot like 50 % so the soundcard get not 192000 sample a sec it gets 288000 sample a sec. or how does changing the audio clock works?

Quote:

Originally Posted by Zachs

Btw set video specifier to "p23" and it'll do exactly what you said. Then in your calculator, use the perfect value of 23.976.

i see. didn't get that out of your "show usage tips". at least it makes now sense why it worked.

Zachs · 20th June 2015, 13:10

Yes the audio card simply plays treats it like a stream with higher number of samples per second. There's a maximum of how much it'll take but for the use case of rate tuner, it's more than enough. It'll probably not work with bitstreaming audio though but I've tested with LPCM via HDMI and it works fine.

huhn · 20th June 2015, 13:14

are you sure the windows mixer is not resampling it to something "usable".

if not the soudncard is running not within it's specs.

Zachs · 20th June 2015, 13:21

Well that might be the case but unless you can notice a difference in sound quality I wouldn't be too worried about it. For cards that can support higher sample rates, I'm pretty sure it doesn't. At least according to what I could find on the internet...

EDIT: Oh BTW, I use MPC Audio Renderer with WASAPI exclusive mode output so I don't think windows mixer has any say in this at all.

huhn · 20th June 2015, 13:49

Quote:

Originally Posted by Zachs

Well that might be the case but unless you can notice a difference in sound quality I wouldn't be too worried about it. For cards that can support higher sample rates, I'm pretty sure it doesn't. At least according to what I could find on the internet...

i don't have a good feeling about this you should at least warn them. i don't think the soundcard spec are for fun.

Quote:

EDIT: Oh BTW, I use MPC Audio Renderer with WASAPI exclusive mode output so I don't think windows mixer has any say in this at all.

that has it own mixer (from windows i mean it is windows audio session...).

Zachs · 20th June 2015, 14:00

Yes as with every other feature in MPDN, it goes without saying you should always do your own testing.
Heck you could even write your own audio renderer and it may break it completely, or it may be like reclock where it resamples it with rather high quality interpolators.
Too many different ways you can use MPDN and too many different hardware / driver out there too.

No. WASAPI exclusive mode does not have a mixer from Windows. I'm not sure what MPC Audio Renderer is using as its resampler but I would suspect it's probably libresample.

huhn · 20th June 2015, 14:24

wasapi has an share mode which needs an mixer why should they remove the whole mixer in exclusive mode. the only thing that change is that it may not be used if possible if the bit deep is to high it still has to change that same of speaker layout so i guess same for sample rate.

it's not about working software is more about breaking hardware.
by overclocking you can brake hardware. can over/under clocking the audio clock brake hardware? if it is resample by what ever program it is still running in specs and there is nothing to panic about but if not it may brake something.

Zachs · 20th June 2015, 14:31

Care to cite your source? From MSDN literature, even shared mode doesn't have that. You need to resampling yourself. Are you saying this is wrong?

Yes all I'm saying is direct sound may simply ask the sound card to sample at a higher rate but that rate has to be within specs of course. Changing the sample rare is essentially changing the 'clock'. I certainly didn't mean over / under clocking the sound card.

Edit: I need to mention that different audio renderer will do it differently, and I was talking about direct sound before the conversation went to wasapi. In the direct sound renderer, as far as I can find out is that if a sample rate is supported by the sound card, it'll use it. Otherwise it'll get transparently resampled. Either way, the rate tuner doesn't do resampling.

Edit 2: reading your reply again I think you're confusing what I'm saying. You kept saying mixer. The issue here is whether it resamples, not whether the mixer is in use. Obviously when in shared mode it is. But why would it need the mixer in Exclusive mode? And no, the mixer being present doesn't mean you don't need to resample. They are completely orthogonal.

huhn · 20th June 2015, 15:14

Quote:

Originally Posted by Zachs

Care to cite your source? From MSDN literature, even shared mode doesn't have that. You need to resampling yourself. Are you saying this is wrong?

Yes all I'm saying is direct sound may simply ask the sound card to sample at a higher rate but that rate has to be within specs of course. Changing the sample rare is essentially changing the 'clock'. I certainly didn't mean over / under clocking the sound card.

isn't the mixer software based since windows vista?
so the soundcard doesn't need to resample at all so the soundcard doesn't get out of spec values. i don't see how this can't be the same with WASAPI. you can set the output that is used in share mode so every program is forced to output that format so it may has to down mix and resample before sending it to wasapi or wasapi is using a mixer which is more likely.

but can wasapi exclusive just send out of spec sample rates to the soundcard driver/card that sounds dangerous.

Quote:

Edit: I need to mention that different audio renderer will do it differently, and I was talking about direct sound before the conversation went to wasapi. In the direct sound renderer, as far as I can find out is that if a sample rate is supported by the sound card, it'll use it. Otherwise it'll get transparently resampled. Either way, the rate tuner doesn't do resampling.

so with direct sound the soundcard gets only data that is part of it's spec so nothing to bother about.

so the only change you can make is adding a resampler yourself so you have more control over the quality.

huhn · 20th June 2015, 15:16

Quote:

Originally Posted by Zachs

Edit 2: reading your reply again I think you're confusing what I'm saying. You kept saying mixer. The issue here is whether it resamples, not whether the mixer is in use. Obviously when in shared mode it is. But why would it need the mixer in Exclusive mode? And no, the mixer being present doesn't mean you don't need to resample. They are completely orthogonal.

ok let's say any post processing of any kind that is need for what ever reason.

Zachs · 21st June 2015, 05:03

I'm not sure I understand what you're trying to say...

madshi · 21st June 2015, 06:56

I'm not sure what effect changing the audio clock has. It could be as innocent as just changing the setting of the clock chip slightly, with no further processing becoming active. But then, at some point the audio data will have to run through a DAC, and the DAC's clock will usually be set by the receiver. The big question is if this DAC's clock will be chained to the source's audio clock or not. Probably not. But that's already a problem even without changing the audio rate. The DAC will have to handle mismatching clocks to some extent. It's possible that changing the audio clock could result in more "adjustments" being done by the DAC in the receiver. This is all extremely hard to know/judge for us normal humans. Could be a great solution, or not, depending on how all the devices in the chain handle it. In theory, one receiver could produce exactly the same audio quality. Another receiver might produce higher jitter or something. Really hard to say. Testing this with bitstreaming might be a good idea. If it works with bitstreaming (which I don't think is impossible) without any audio quality issues then chances are good it will also work well with PCM. For bitstreaming testing I would recommend to use AC3 because that has the longest frame duration, so bitstreaming issues would be most noticeable. Another test would be to put this to the extreme and test rather high rate change values (like a factor of 1.5x or even 2.0x). At some point either the audio pitch has to noticeably change (indicating that either resampling is done or the audio clock is really adjusted by the receiver), or noticeable audio artifacts must show up.

Zachs · 21st June 2015, 07:08

Yes like I said earlier, everything comes down to how your hardware and/or driver and/or audio renderer handle it. It's no different from MPDN's high bitdepth output, as most madvr users have only just recently found out.

Wasapi allows the audio endpoint to request specific rates from the audio card. But like the graphics card and display resolution, not every hardware works the same. Some may need resampling, some may not. But just as the 10bit output, you really need to test it yourself. To get consistent behaviour across all hardware, the only solution would be to always resample it in software, which I had planned to do for some time now.

Zachs · 21st June 2015, 07:16

p.s. I personally use this in my setup because I just can't get my nvidia card to get close enough to the refresh rate I want. So far I haven't noticed any difference at all with the audio. So subjectively speaking it works great for me. When I get some time, I'll have a look into the MPC audio renderer code to see exactly what it does. There's no way to find out what the direct sound renderer actually does though...

From visual protective standpoint, this is definitely way better than fluid motion as it basically gives you stutter free viewing experience and your display can run at its natively supported frequency with all the advanced FRC features it offers. If you don't notice any difference in audio, I'd say this is definitely the recommended way to play video.

foxyshadis · 21st June 2015, 10:49

I've got to say, the insanely fast changes to the installer was surprising and gratifying. This is the most responsive development project I've ever come across, not only for this, but everything about it. Thanks, Zachs and Belphemur and Shiandow!

huhn · 21st June 2015, 10:51

i just wanted to test for audio differences.

but i run into my general audio issues again this time way worse than usually.
the first thing that changed is that the fullness is not the problem it is now staying at stable 90%.
but now i see the ref clock changing when i hear an audio issue and some times a frame is delayed at the same time. the refclk deviations is skyrocketing after that. i even saw numbers like 0.35 % after 60 sec playback.
that's without rate tuner. but i got this issue with it too.

of cause i don't have that issue with madVR.

kerimcem · 21st June 2015, 14:11

mpdn+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files = image gets stuck..

mpc+madvr+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files =no problem......

Belphemur · 21st June 2015, 19:29

Quote:

Originally Posted by kerimcem

mpdn+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files = image gets stuck..

mpc+madvr+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files =no problem......

Could you provide the media file you used ?

Shiandow · 23rd June 2015, 23:55

@all. There's been a lot of development these last few days not just by me but by the other developers as well. In fact, I think the next update might be one of the biggest yet! Anyway, here are some of the changes I've made that you can expect in the next version of the MPDN extensions:

ScriptGroup now has a new dialog similar to the ScriptChain dialog. This avoids the need for two separate dialogs. These changes to the Script Group are unfortunately not compatible with the older config files, those might need to be reset.

SuperRes has been improved (or changed, anyway). Most of the parameters have become obsolete, the only remaining parameters are "passes", "strength" and "softness". The new algorithm is more consistent when combined with different prescalers, so there's no longer a need to save the parameters separately for each prescaler (the old behaviour can be mimicked by making a script group with multiple copies of SuperRes). And since there's an increasing number of possible prescalers the list of prescalers can now be modified freely. The new algorithm is capable of creating incredibly sharp images without increasing ringing and aliasing. That said it's not capable of removing ringing and aliasing either so using a good prescaler is essential (but more on that later).

SuperChromaRes has been improved similarly, with an additional "bilateral prescaler" option. Enabling this option makes SuperChromaRes use it's own chroma upscaling method which uses the luma to guide the chroma upscaling.

Hylian's excellent Super-xBR algorithm has also been ported to MPDN. It's already shown great promise in the MadVR thread but used as a prescaler for SuperRes makes it possible to get images that are sharper than I've ever seen with remarkably low aliasing and ringing. And Super-xBR doesn't seem to have reached it's peak yet so I'm excited to see how much more it can be improved!

The new SuperRes, SuperChromaRes and Super-xBR scripts are still experimental so feedback would be highly appreciated!

20th June 2015, 13:21	#2485 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	Well that might be the case but unless you can notice a difference in sound quality I wouldn't be too worried about it. For cards that can support higher sample rates, I'm pretty sure it doesn't. At least according to what I could find on the internet... EDIT: Oh BTW, I use MPC Audio Renderer with WASAPI exclusive mode output so I don't think windows mixer has any say in this at all. Last edited by Zachs; 20th June 2015 at 13:28.

20th June 2015, 14:31	#2489 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	Care to cite your source? From MSDN literature, even shared mode doesn't have that. You need to resampling yourself. Are you saying this is wrong? Yes all I'm saying is direct sound may simply ask the sound card to sample at a higher rate but that rate has to be within specs of course. Changing the sample rare is essentially changing the 'clock'. I certainly didn't mean over / under clocking the sound card. Edit: I need to mention that different audio renderer will do it differently, and I was talking about direct sound before the conversation went to wasapi. In the direct sound renderer, as far as I can find out is that if a sample rate is supported by the sound card, it'll use it. Otherwise it'll get transparently resampled. Either way, the rate tuner doesn't do resampling. Edit 2: reading your reply again I think you're confusing what I'm saying. You kept saying mixer. The issue here is whether it resamples, not whether the mixer is in use. Obviously when in shared mode it is. But why would it need the mixer in Exclusive mode? And no, the mixer being present doesn't mean you don't need to resample. They are completely orthogonal. Last edited by Zachs; 20th June 2015 at 14:45.

21st June 2015, 07:16	#2495 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	p.s. I personally use this in my setup because I just can't get my nvidia card to get close enough to the refresh rate I want. So far I haven't noticed any difference at all with the audio. So subjectively speaking it works great for me. When I get some time, I'll have a look into the MPC audio renderer code to see exactly what it does. There's no way to find out what the direct sound renderer actually does though... From visual protective standpoint, this is definitely way better than fluid motion as it basically gives you stutter free viewing experience and your display can run at its natively supported frequency with all the advanced FRC features it offers. If you don't notice any difference in audio, I'd say this is definitely the recommended way to play video. Last edited by Zachs; 21st June 2015 at 07:21.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

20th June 2015, 12:50	#2481 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	Btw set video specifier to "p23" and it'll do exactly what you said. Then in your calculator, use the perfect value of 23.976.

20th June 2015, 13:10	#2483 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	Yes the audio card simply plays treats it like a stream with higher number of samples per second. There's a maximum of how much it'll take but for the use case of rate tuner, it's more than enough. It'll probably not work with bitstreaming audio though but I've tested with LPCM via HDMI and it works fine.

20th June 2015, 13:14	#2484 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 8,623	are you sure the windows mixer is not resampling it to something "usable". if not the soudncard is running not within it's specs.

20th June 2015, 14:00	#2487 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	Yes as with every other feature in MPDN, it goes without saying you should always do your own testing. Heck you could even write your own audio renderer and it may break it completely, or it may be like reclock where it resamples it with rather high quality interpolators. Too many different ways you can use MPDN and too many different hardware / driver out there too. No. WASAPI exclusive mode does not have a mixer from Windows. I'm not sure what MPC Audio Renderer is using as its resampler but I would suspect it's probably libresample.

20th June 2015, 14:24	#2488 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 8,623	wasapi has an share mode which needs an mixer why should they remove the whole mixer in exclusive mode. the only thing that change is that it may not be used if possible if the bit deep is to high it still has to change that same of speaker layout so i guess same for sample rate. it's not about working software is more about breaking hardware. by overclocking you can brake hardware. can over/under clocking the audio clock brake hardware? if it is resample by what ever program it is still running in specs and there is nothing to panic about but if not it may brake something.

21st June 2015, 05:03	#2492 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	I'm not sure I understand what you're trying to say...

21st June 2015, 06:56	#2493 \| Link
madshi Registered Developer Join Date: Sep 2006 Posts: 9,140	I'm not sure what effect changing the audio clock has. It could be as innocent as just changing the setting of the clock chip slightly, with no further processing becoming active. But then, at some point the audio data will have to run through a DAC, and the DAC's clock will usually be set by the receiver. The big question is if this DAC's clock will be chained to the source's audio clock or not. Probably not. But that's already a problem even without changing the audio rate. The DAC will have to handle mismatching clocks to some extent. It's possible that changing the audio clock could result in more "adjustments" being done by the DAC in the receiver. This is all extremely hard to know/judge for us normal humans. Could be a great solution, or not, depending on how all the devices in the chain handle it. In theory, one receiver could produce exactly the same audio quality. Another receiver might produce higher jitter or something. Really hard to say. Testing this with bitstreaming might be a good idea. If it works with bitstreaming (which I don't think is impossible) without any audio quality issues then chances are good it will also work well with PCM. For bitstreaming testing I would recommend to use AC3 because that has the longest frame duration, so bitstreaming issues would be most noticeable. Another test would be to put this to the extreme and test rather high rate change values (like a factor of 1.5x or even 2.0x). At some point either the audio pitch has to noticeably change (indicating that either resampling is done or the audio clock is really adjusted by the receiver), or noticeable audio artifacts must show up.

21st June 2015, 07:08	#2494 \| Link
Zachs Suptitle, MediaPlayer.NET Join Date: Nov 2001 Posts: 1,721	Yes like I said earlier, everything comes down to how your hardware and/or driver and/or audio renderer handle it. It's no different from MPDN's high bitdepth output, as most madvr users have only just recently found out. Wasapi allows the audio endpoint to request specific rates from the audio card. But like the graphics card and display resolution, not every hardware works the same. Some may need resampling, some may not. But just as the 10bit output, you really need to test it yourself. To get consistent behaviour across all hardware, the only solution would be to always resample it in software, which I had planned to do for some time now.

21st June 2015, 10:49	#2496 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,567	I've got to say, the insanely fast changes to the installer was surprising and gratifying. This is the most responsive development project I've ever come across, not only for this, but everything about it. Thanks, Zachs and Belphemur and Shiandow!

21st June 2015, 10:51	#2497 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 8,623	i just wanted to test for audio differences. but i run into my general audio issues again this time way worse than usually. the first thing that changed is that the fullness is not the problem it is now staying at stable 90%. but now i see the ref clock changing when i hear an audio issue and some times a frame is delayed at the same time. the refclk deviations is skyrocketing after that. i even saw numbers like 0.35 % after 60 sec playback. that's without rate tuner. but i got this issue with it too. of cause i don't have that issue with madVR.

21st June 2015, 14:11	#2498 \| Link
kerimcem Registered User Join Date: Aug 2011 Posts: 85	mpdn+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files = image gets stuck.. mpc+madvr+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files =no problem......

23rd June 2015, 23:55	#2500 \| Link
Shiandow Registered User Join Date: Dec 2013 Posts: 753	@all. There's been a lot of development these last few days not just by me but by the other developers as well. In fact, I think the next update might be one of the biggest yet! Anyway, here are some of the changes I've made that you can expect in the next version of the MPDN extensions: ScriptGroup now has a new dialog similar to the ScriptChain dialog. This avoids the need for two separate dialogs. These changes to the Script Group are unfortunately not compatible with the older config files, those might need to be reset. SuperRes has been improved (or changed, anyway). Most of the parameters have become obsolete, the only remaining parameters are "passes", "strength" and "softness". The new algorithm is more consistent when combined with different prescalers, so there's no longer a need to save the parameters separately for each prescaler (the old behaviour can be mimicked by making a script group with multiple copies of SuperRes). And since there's an increasing number of possible prescalers the list of prescalers can now be modified freely. The new algorithm is capable of creating incredibly sharp images without increasing ringing and aliasing. That said it's not capable of removing ringing and aliasing either so using a good prescaler is essential (but more on that later). SuperChromaRes has been improved similarly, with an additional "bilateral prescaler" option. Enabling this option makes SuperChromaRes use it's own chroma upscaling method which uses the luma to guide the chroma upscaling. Hylian's excellent Super-xBR algorithm has also been ported to MPDN. It's already shown great promise in the MadVR thread but used as a prescaler for SuperRes makes it possible to get images that are sharper than I've ever seen with remarkably low aliasing and ringing. And Super-xBR doesn't seem to have reached it's peak yet so I'm excited to see how much more it can be improved! The new SuperRes, SuperChromaRes and Super-xBR scripts are still experimental so feedback would be highly appreciated!