[FFmpeg-devel] Forward frame wall clock time from avdevice to HLS muxer

[Jim DeLaHunt]

On 2020-08-27 13:05, Marton Balint wrote:

>
> On Thu, 27 Aug 2020, Nicolas George wrote:
>
>> Marton Balint (12020-08-27):
>>> +1, this seems like the right thing. PTS is not really suitable, as 
>>> that is
>>> based (or at least should be based) on monotonic clock, not realtime 
>>> clock.
>>
>> PTS are based on what we decide they are based.
>
> Realtime clock is not suitable for multimedia PTS source because it is 
> affected by system time changes and leap seconds.


I don't get it, Marton. Why such a firm rejection of real-time clock as 
PTS source?  It seems to me that system time changes and leap seconds 
aren't difficult problems.

1. System time changes may just not occur. Some recordings may last 
days, and system clocks my drift over days, I get that. But some 
recordings last hours or even minutes. (My client's recordings last 
0.01-4 hours.)

2. You can program the recording system to not update its system clock 
while recording. I imagine one could build a system which can survive a 
few minutes or hours without updating their system clock.

3. You can use an accurate realtime clock. My client's application could 
draw real time from a GPS source, which should be pretty resistant to 
clock drift.

4. Leap seconds can only happen at 24:00 UTC on June 30 or December 31.  
If you don't happen to be recording then, no problem. If you happen to 
be recording then, then see #5 and #6 below.

5. You can work around any leap seconds or system time clock changes 
which do occur by generating PTS values which aren't quitte accurate, 
but which amortise the error over a few frames. For instance, if the PTS 
normally increments by 3003 ticks per frame (90 kHz clock, 30/1.001 
frames per second), and the system clock repeats the 23:59:59 second 
twice, then you have an error of 3003 ticks. Amortise that over n 
frames, and for each frame increment by 3003 - (3003/n) ticks. For n=10, 
that would be an increment of 2702.7 ticks. For some applications that 
might be an acceptable way to bury the error.

6. Another way to work around any leap seconds or system time clock 
changes which do occur is to keep track of events where the clock does 
not increment by the expected amount each frame (e.g. 3003 ticks in the 
case above). Make a log of the indicated realtime clock value for the 
frame, the indicated realtime clock value for the previous frame, the 
difference from expected, and continue to update the PTS by the expected 
number of ticks. For some applications that might be an acceptable way 
to bury the error.

What am I missing? Why, despite these workarounds, is a realtime clock 
not suitable as a PTS source?

         —Jim DeLaHunt, software engineer, Vancouver, Canada