[mythtv] DVD playback issues, patch

[Davin McCall]

On 23/11/09 17:20, Mark Spieth wrote:
>
> there are a few output sync methods.
> 1 is the timer method which has no hardware basis
> 2 is the various h/w sync methods, of which I use opengl_sync
>
> to my thinking, it doesnt matter as both have the same underlying 
> quantization of output presentation.
>

Ok, I think I know what you mean.

>>
>> refresh interval != frame interval!!
>
> that is correct. audio timestamps vary more finely than video ones 
> which are always quantized to frame interval. this is modified by the 
> playback speed (timestretch).
>
> output rate is always at the refresh interval.
> so we have 2 problems here. massaging the frame rate to coincide with 
> the refresh/output rate and keeping the avsync in check.

Yes, understood (already).

>
> what we see is at the refresh rate but we have no direct knowledge of 
> which frame is actually displayed. we also need to know which frame is 
> shown next. this the output vtimestamp (based on refresh rate) is 
> adjusted to keep the atimestamp within bounds. but since the video is 
> a more coarsely quantised system, we modify our knowledge of the 
> vtimestamp by the amount that the output system would change it. i.e. 
> at the refresh rate.

Sure, but avsync_delay has nothing to do with knowledge of the 
vtimestamp. It's just a value that's passed to the VideoSync object. The 
V.S. object uses it to calculate how many refresh intervals to wait 
between frames (or, if the software mechanism is used, it just uses it 
to determine exactly how long to sleep for). Also, it's cumulative in 
the V.S. object. So if you pass in 1/3 of a refresh interval each time, 
then after three frames it would delay an additional refresh interval.

With the hardware mechanisms (I used DRM but OpenGL works the same way) 
then the mechanism always aligns to the refresh interval anyway so it 
doesn't matter if avsync_delay is not a multiple of the refresh 
interval. With the software (timer) mechanism there's no point trying to 
align to refresh intervals since we have no idea when refresh happens 
anyway.

So, I still don't understand why avsync_delay must be a multiple of the 
refresh interval.

> we cant change when a frame is displayed as that is controlled by the 
> output hardware and is always at the frame rate.

No, it is always at the *refresh* rate. And we *can* change when a frame 
is displayed, to the quantization level determined by the refresh rate.

> better we control dropping, dups than the hardware anyway.

Sure.

>
> we are talking about a control system with estimated variables.
> the better the estimation, the better the result.

But avsync_delay is not an estimation of anything. Other than, perhaps, 
how far ahead/behind the video is from the audio. And in that case the 
best estimation is one that *hasn't* been quantized to the refresh interval.

> hope Ive answered this adequately.

Sorry but no!

Thanks for responding,

Davin