[FFmpeg-devel] [PATCH] av_get_delay
nicolas.george at normalesup.org
Wed Jun 29 12:25:26 CEST 2011
Le decadi 10 messidor, an CCXIX, Michael Niedermayer a écrit :
> with the current API audio/video output "muxers" should "present"
> the data to the user at the pts of the given packet.
You mean: according to the system's realtime clock rather than some
device-specific internal clock?
I do not think this is a good idea. To account for the skew in a sound
card's clock, it would require slightly resampling the incoming data, while
most application would be just happy to just sync on the sound card's clock.
> Maybe something along the following lines is clearer:
> the delay is the duration in timebase units of all buffered data.
> buffered in the sense of between what goes into the muxer and what
> is presented to the user or transmitted over the net.
I adapted it that way:
* The delay is the duration, in timebase units, of all buffered data,
* i.e. data that has been submitted to the muxer but not yet presented to
* the user of transmitted over the net.
* The exact meaning of that depends on the muxer.
* It is mostly relevant for live streams, like devices or network
> some value that is not a valid delay would allow distinguishing it from
> valid delays. some error code representing "Not implemented" maybe
Would simply AV_NOPTS_VALUE be ok?
> also the code should consider the buffering required for interleaving
> (by dts for example)
You mean packets that have been submitted to av_interleaved_write_frame but
that lavf has not yet submitted to oformat->write_packet?
I see the concern, and I will think about it to try and come with a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel