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

[Nicolas George]

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140403/9002c5be/attachment.asc>