[FFmpeg-devel] [PATCH] Use monotonic clock for measuring rel time.

[Michael Niedermayer]

On Thu, Apr 03, 2014 at 04:00:29PM +0200, Nicolas George wrote:
> Le primidi 11 germinal, an CCXXII, LANGLOIS Olivier PIS -EXT a écrit :
> > This and the fact that many Linux multimedia subsystems are using
> > monotonic clock including ALSA lead me to think that issues in multimedia
> > applications and realtime clock are not that exceptional.
> 
> Such problems are not exceptional, obviously, but as Reimar explained,
> changing to the monotonic clock will only fix some of them. Most of these
> problems are caused by an invalid use of the clock in itself.
> 
> > Every output files that I create have a start ts close to 0. I guess this
> > comment generally apply more to networked outputs (rtp,rtsp, etc?)
> 
> IIRC, ffmpeg can use the input timestamps to adjust the A-V sync, even
> though the timestamps do not reach the output file as is. There are also
> options that can cause ffmpeg to keep the timestamps.
> 
> An obvious example: you can use the drawtext filter to hardburn the
> recording time on the video.
> 
> And do not forget an important point: libavdevice is a library; there are
> certainly programs out there that rely on that behaviour.
> 
> > Are people desiring to use wall clock ts for network streams do so with
> > the switch '-use_wallclock_as_timestamps'?
> 
> This was discussed when the issue of the timestamps from ALSA arose:
> timestamps used for A-V sync need accuracy, and most of all regularity, or
> they may cause audible or visible glitches. The -use_wallclock_as_timestamps
> option is implemented too far from the device and without smoothing.
> 
> > That sounds like a very reasonable request that I am willing to address in
> > the patch. Please just help me to understand how to define 'whenever it
> > makes sense'. I guess that we are talking more about output timestamps.
> 
> I guess the basic question you have to ask is whether the timestamp can
> reach a part of the code where it is collated with timestamps from other
> origin. For example, that does not happen with a timestamp that is just used
> with a subtraction to benchmark a piece of code.
> 
> Timestamps from capture devices, OTOH, can be very important. In fact, a
> documented way of knowing their reference is currently sorely missing from
> the API.

btw, it should be relatively easy to convert between different
clocks

something like

for(deta = bignum; delta > C; ) {
    a1 = get_clock1();
    b1 = get_clock2();
    a2 = get_clock1();
    delta = a2 - a1;
}
here we now know that b1 is pretty close to (a1+a2)/2
and can use it to offset clock values from one clock to another
that are close to where we meassured this

or something like:

while(offmax - offmin > C) {
    a = clock1();
    offmin = FFMAX(b - a);
    b = clock2();
    offmax = FFMIN(b - a);
}


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- 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/20140405/63b7ef21/attachment.asc>