davmac at davmac
Nov 25, 2009, 11:15 PM
Post #4 of 4
(827 views)
Permalink
|
|
Re: timestretch: predictive frame skipping (was Re: DVDplayback issues, patch)
[In reply to]
|
|
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.
Exactly.
> 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.
Davin
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
