[FFmpeg-devel] [PATCH 1/2] Only add frame_delay to video_clock after the picture was actually queued

Michael Niedermayer michaelni at gmx.at
Sun Jul 31 11:29:18 CEST 2011

On Fri, Jul 22, 2011 at 08:59:35PM +0200, Marton Balint wrote:
> Video_refresh expects video_clock to contain the pts of the next frame which is
> not yet in the queue.

I assume you talk about:
next_target= vp->target_clock + is->video_clock - vp->pts; //FIXME pass durations cleanly

why not pass the durations cleanly instead? Is there some problem that
makes this option non trivial?

It seems more robust to me than moving the video_clock write around
which is likely affected by race conditions

anyway, sorry for my late awnser & thanks for looking into imroving

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110731/5bc28a14/attachment.asc>

More information about the ffmpeg-devel mailing list