• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Sound *pause* leads to video stutter

sw4y

Member
Thread Starter
Joined
Jan 12, 2009
Messages
16
Likes
0
Sorry about the title, but I did not find a better one to describe the problem.

I use reclock in combination with ac3filter (24 bit pcm output) in dvbviewer to watch movies in 24p.
At first I hope this setting in ac3filter is right to work best with reclock?

To come to the problem:

Everytime I start a movie, audio & video start and within the first 5-10 seconds audio disappears for about half a second and then comes back (I think it happens when reclock "switches" to cinema adaption).
Because of that the video starts to stutter or stucks and needs some time to play normally again.

I hope it becomes clear what I mean - is there any solution to this?
Are there any settings that make it possible that audio doesn't break anymore?

Btw, thanks for the flood of updates in the last time - I really appreciate that and it's good to see that you keep up the good for for such a great program.

Greetz,

sw4y
 
I use reclock in combination with ac3filter (24 bit pcm output) in dvbviewer to watch movies in 24p.
At first I hope this setting in ac3filter is right to work best with reclock?
ideally you should feed 32float to Reclock to avoid unnecessary conversions, but AC3Filter uses libdts for DTS..and it sounds rather ugly, if I were you I'd try to compare against ffdshow(using libavcodec), the DTS decoding is far less metallic...OTOH AC3Filter is cool for AC3 as it uses liba52, which sounds great in 32float.
Everytime I start a movie, audio & video start and within the first 5-10 seconds audio disappears for about half a second and then comes back (I think it happens when reclock "switches" to cinema adaption).
Because of that the video starts to stutter or stucks and needs some time to play normally again.
yup, that's the resampling adaptation taking place..not much to do about it, it shouldn't make the video stutter or freeze, though...what player/video renderer are you using?
 
Thanks for your very fast support - I will try the 32bit floating!

I am using dvbviewer with evr-custom as renderer (powerdvd 7 as codec).
In reclock I use vsync correction (with evr...) and vsync correction with dxva.
Could that be the problem? Which settings fit best?

Greetz
 
np ;)

ahhh, I don't use any of these, hopefully someone else will know better :eek:

but yes, that sounds like a lot of VSYNC correction, besides I think James recommended to leave it disabled in Reclock for DXVA...OTOH it'd work fine for Jong I think, so really not sure here.

maybe CoreAVC CUDA would be an option? they have a trial for the 1.95 version...DXVA is usually a major pain, especially if you have reception issues..from what I understood, DXVA doesn't handle stream errors well.
 
CUDA would be nice, but I'm using an ATI HD4550...

I'll try it with DXVA turned off, I think my machine should handle that - though I really would like to leave it enabled.
 
Thanks for your very fast support - I will try the 32bit floating!

I am using dvbviewer with evr-custom as renderer (powerdvd 7 as codec).
In reclock I use vsync correction (with evr...) and vsync correction with dxva.

What part of "not recommended" next to the checkbox did you not understand? ;)

And while at it, disable it for evr, too.
 
What part of "not recommended" next to the checkbox did you not understand? ;)

And while at it, disable it for evr, too.

Thanks for your help James - I always tried to understand how reclock works and thaught I'm a little bit into it...
I knew that it was not recommended, but for me "do not use!" would have been better :eek:

I totally disabled DXVA (and Vsync-Correction) and now everything runs totally smooth.
 
Reclock vsync correction works perfectly with VMR9 and EVR and DXVA, even with Aero enabled, if and only if you use D3D exclusive mode or a player that uses triple buffering, like PDVD 7&8 (not tried 9).

I use it all the time, but you need to know what you are doing to set it up!
 
Reclock vsync correction works perfectly with VMR9 and EVR and DXVA, even with Aero enabled, if and only if you use D3D exclusive mode or a player that uses triple buffering, like PDVD 7&8 (not tried 9).

I use it all the time, but you need to know what you are doing to set it up!

In my experience using vsync correction with VMR9 and EVR isn't useful, as both already have one on their own.
 
I don't agree!

They both seek to avoid tearing for sure, but they are both clearly susceptible to synchronised frame rate/fresh rate judder (what Reclock vsync correction is intended to fix).

MPC-HC has recently introduced a whole new renderer, a year in the making, that is likely to be their default renderer soon. It is based on EVR but with an additional vsync correction method that has been termed "Reclock Lite" - it tries to position frame presentation and a fixed point between vsync, like Reclock, but it cannot correct for frame rate differences, even 23.976->24fps - so it works almost perfectly when frame rate and refresh rate are almost identical and replaces extended periods of judder with a single dropped frame when they are different. A lot of effort has gone into this and it is in fact the second effort by a second developer to really fix vsync problem with EVR. It would be strange if there was really no problem to fix. See http://www.ostrogothia.com/?page_id=1216 especially the judder chart shown under the heading "Alternative 3". Much of the rest of this blog makes an interesting read.

It is very clear to me and those involved in developing and testing the "Gothsync" renderer that even EVR is susceptible to synchronised frame rate/fresh rate judder.
 
James,

Here is a sequence of screenshots taken using MPC-HC and its sync renderer (an EVR Custom Presenter) with Reclock vsync turned off and the sync renderers own vsync correction turned off.

They were taken straight after each other with the same clip, just pausing and un-pausing. Ignore the smal burst of big spikes in the middle of each frame. that is where I paused the video instantaneously.

You can see the point of presentation (green line) varies "randomly" on each seek and when it happens to be very close to the vsync you get horrible judder (as in image 4 below). With Reclock keeping the frame rate very close to the refresh rate this synchronised judder can go on for minutes! It can happen after a seek as here, or after a period due to slow clock drift. This is very slow with Reclock doing its stuff, but you can see how if, after the seek, as in "1" they are already very close, this could still happen a few minutes into any movie/video.

EVR_vsync_MPC_2.jpg


Image 1


EVR_vsync_MPC_3.jpg


Image 2


EVR_vsync_MPC_4.jpg


Image 3


EVR_vsync_MPC_5.jpg


Image 4



Exactly the same behaviour is visible with a "standard" EVR renderer, in MPC-HC and, for example, PDVD. They just don't have the pretty graph to show you what is happening. With Reclock vsync correction enabled in D3D mode vsync can be pinned wherever in the refresh cycle you want it (I typically use -16ms), including in DXVA mode.
 
Last edited:
In fact, I had not run this test on W7 so I thought I would do it just to be sure. It took about 15 play/pauses, but after that using the standard EVR renderer (not CP) the vertically scrolling credits to Blade Runner (HD-DVD) juddered like hell. One more pause/play and the problem is gone. :)
 
Back
Top