[FFmpeg-user] repeat a frame

[Jim DeLaHunt]

On 2021-03-03 14:57, Mark Filipak (ffmpeg) wrote:
> With TB = 1/(720000 ticks/s), for a 24.976fps output,
> deltaPTS = (1001/24000 frames/s)/(1/(720000 ticks/s)) = 30030 ticks/frame
>
> If working time_base (from the AVRational) has an effective resolution 
> of int32 (i.e. ±2147483647 ticks), then frames past 0:49:42 will be 
> dropped.


I see what you are getting at, but you are using the wrong terminology 
for this software product, so your statements sound garbled.

Remember that, in FFmpeg, the time_base is the time difference between 
frames, in seconds. It is an attribute of the stream, so its value does 
not change regardless of the length of the stream (unless something 
changes the time_base, creating a second stream derived from the first). 
Time_base is type AVRational, which is a rational number, not an 
integer, not a float.

Instead of "working time_base", i think you mean "time offset". This is 
the number of seconds since the zero time. FFmpeg can get a lot done 
without calculating the time offset.

Time offset = time_base * Presentation Timestamp (PTS).  Thus, PTS = 
time offset / time_base.

FFmpeg uses PTS values, related to the constant time_base, a lot.


> If working time_base has an effective resolution of uint32 (i.e. 
> 4294967295 ticks), then frames past 1:39:26 will be dropped.
When it comes to integers, "resolution" is not the right term to use. 
"Maximum value" and "minimum value" are the most comment. "range" or 
"capacity" might also be used.  The number of bits in the integer is the 
"size".

The AVRational value is stored as an integer numerator and an integer 
denominator. The ranges of those integers are sufficient to store 1 and 
72,000. Beyond that, for this discussion it doesn't matter what their 
maximum values are.


> I think that the successful transcode of a 2:21:19 video confirms that 
> the working time_base is sufficient. I suspect it's a float but of 
> course I don't know that and I don't know its resolution.

As we have discussed, PTS is stored as an int64_t, a signed integer with 
a size of 64 bits. The maximum value of an int64_t is (2^63)-1, about 9 
billion billion (9.2 * 10^18). FFmpeg may reserve a few of the maximum 
and minimum values to indicate special conditions, but 9 billion billion 
will do.

The time offset is calculated from an int64_t * (integer / integer). 
FFmpeg code can choose to store the result exactly as a rational number 
(assuming a numerator with a high enough maximum value), or 
approximately as an integer or a high-precision float, as the 
circumstances demand.

With a time_base of 1/720,000 secs, a near-maximum PTS of 9 billion 
billion indicates a near-maximum time offset of a little over 396,000 
years.

Most of your films will likely be shorter than that.

Best regards,
      —Jim DeLaHunt