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

[Marton Balint]

On Thu, 27 Aug 2020, Jim DeLaHunt wrote:

> 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?

You're suggesting workarounds for the problem. We want no workarounds or 
special considerations, we want it to just work.

Sure, if you promise you won't change system time, and you ensure a smooth 
time transition during leap seconds, then you may use it depending on 
application. But this certainly should not be the default, and certainly 
should not be used because PRFT is needed on the output.

Regards,
Marton