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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
