[mythtv] DVD playback issues, patch

John P Poet jppoet at gmail.com
Wed Nov 25 01:36:21 UTC 2009


On Mon, Nov 23, 2009 at 10:23 PM, Davin McCall <davmac at davmac.org> wrote:
> 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

I am finding this conversation interesting.

I have been wondering why timestretch playback is not smoother than it
is.  My system (using software decoder) can playback anything I throw
at it, including 1080i H.264 material with yadif (2x) deinterlacing.
As soon as I bump up the speed even one notch (1.05x), my log file
starts filling up with:

NVP(0): Video is 3.67133 frames behind audio (too slow), dropping
frame to catch up.

...and that happens even when doing this with "simple" 720p mpeg2.  My
system should be able to decode 100 frames per second pretty easily.

So, the video being +3 frames behind the audio does not make sense.
There is no excuse for my system no being able to "keep up", unless it
is not being allowed to.  I assume the problem is that there can only
be one-frame-per-refresh, and the refresh is 60Hz.  I don't know what
the solution is, but I would love it if Davin or Mark could come up
with it ;-)


John
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


More information about the mythtv-dev mailing list