[mythtv] timestretch: predictive frame skipping (was Re: DVDplayback issues, patch)

Davin McCall davmac at davmac.org
Thu Nov 26 07:15:25 UTC 2009

On 26/11/09 10:18, Mark Spieth wrote:
> Im coming at this from a control systems point of view.
> you have a model which should accurately represent the underlying system.
> the model is necessary since the variables themselves are hidden.

I'm starting to see where you're coming from. However, the 
avsync_adjustment being or not being a multiple of the refresh interval 
won't affect the accuracy of the model.

> it makes no sense to wait for a partial frame and then wait for the 
> next vsync.
> otherwise you would wait for the sub frame and then wait for the rest 
> of the displayed frame.

I'm thinking maybe by frame you mean output frame, i.e refresh interval, 
rather than source frame, but if not:

Yes it does make sense... if the video is behind the audio, this is 
exactly what you want you to do (and is exactly what the current code 
does) in order to speed up the video: it waits for some number of 
refresh intervals N which constitute a partial frame.

If you mean there's no point waiting for a partial refresh interval and 
then waiting for a vsync, I can see your point. However, that's now what 
happens; the VideoSync object accumulates these small delays until they 
are big enough to constitute an entire refresh interval (I know that you 
understand this, I'm just expounding).

> thus effectively nothing happened. thus avsync_adjustment for that 
> pass has no effect and would have to accumulate until it was larger 
> than 1 display period. I suppose this would work too.


> I prefer controlling the quantized adjustments in the controller in 
> question.
> however there is always more than 1 way to skin cats. the effect would 
> probably end up being the same.

I think so. Initially I thought you were saying it wouldn't, and I 
really wanted to know why not - essentially, I wasn't sure if my 
understanding of the way the code functioned (or was meant to function) 
was correct. I think now that it was right all along.

> though the interaction would be more complex and quite possible 
> dependent on the implementation in waitforframe. so that would be a 
> good argument for not relying on fractional waitforframe adjustments.

I don't know about that...

 From a software engineering perspective, I think it would be better to 
separate the A/V sync logic from the video refresh sync altogether. The 
interaction would be simpler, not more complex. Being dependent on the 
implementation in WaitForFrame is a bonus, not a problem (so long as the 
contract for WaitForFrame is satisfied by the implementation, if it's 
not that of course is a bug anyway) - a bonus because it moves handling 
of refresh rate issues into just one place. What if for instance your 
video output had a variable refresh rate, or no refresh rate at all? 
(The software timer falls into this latter category, it "emulates" a 
refresh interval but it really doesn't need to, and making it do so just 
leads to more complex code).

You could improve things further by removing knowledge of the source 
frame rate from the VideoSync implementation, and just have the player 
tell the video sync to wait for an amount of time (source_frame_interval 
+ adjustment). So, AV sync and refresh sync become completely separated.

However, I'm now at the point where I'm confident that I understand what 
you are saying. And, as you mention, there is more than one way to skin 
a cat. Thanks for the discussion, it's been interesting.


More information about the mythtv-dev mailing list