[FFmpeg-devel] [PATCH] av_get_delay
michaelni at gmx.at
Thu Jun 30 05:55:35 CEST 2011
On Wed, Jun 29, 2011 at 07:06:09PM +0200, Nicolas George wrote:
> Le primidi 11 messidor, an CCXIX, Michael Niedermayer a écrit :
> > i didnt say that.
> Sorry I misunderstood.
> > This doesnt seem to work very well for example when you have:
> > a slideshow with commentary, the delay from the video stream could
> > make quite big jumps an be constant between them. It might be
> > better to add the remaining duration of the currently displayed frame
> > in there or something
> What about something like that then:
> * Get the delay for the selected stream, in time_base units.
> * The exact meaning of that delay depends on the format.
> * For real-time muxers, data submitted to the muxer more than delay ago
> * should have been output (e.g. presented to the user), while data
> * submitted less than delay ago should be still somewhere in the muxer or
> * some hardware buffer.
> * Note that packets interleaving may introduce an additional delay.
> * If the format does not support delay measurement, the return value is
> * AV_NOPTS_VALUE.
> int64_t av_get_output_delay(AVFormatContext *s, int stream);
> Anyway, for this last part, unless I am mistaken, there is a strict
> delay_total = delay_interleave + delay_output
> The original patch gives delay_output, and is useful by itself. Maybe the
> delay_interleave part can wait until someone actually needs it and therefore
> can test it for usability.
hmm, iam unsure
does anyone else have an oppinion?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel