On 2021-02-26 20:32, Jim DeLaHunt wrote:
On 2021-02-26 16:53, Mark Filipak (ffmpeg) wrote:
…What I'm suggesting is that ffmpeg convert to a single, 360000Hz time base for all videos, for
all time. Then, rounding errors would be *zero*. PTSs would be exact. …
As I told you back on 23. February, ffmpeg uses a timebase that is a rational number, and is an
attribute of the video stream, and can take various values. The timebase could be 1/360000, or 1/24,
or 1001/24000. This already allows integer Presentation TImestamp (PTS) values to represent time
values with zero rounding errors. You dismissed that as "The Matrix", but this is in fact the data
structure which FFmpeg already uses.
Yes, an encoded video can have any time base, as you point out. The encoder will make that time base
whatever is required by the stream (example: MPEG-2 expects 90000Hz). That is not the time base I'm
addressing. I'm concerned with the internal time base in the filter pipeline that's used to resolve
frame ordering, both video and audio.
Of course, to achieve zero rounding errors, the input video, and the user writing the FFmpeg command
line, and FFmpeg itself, must all make wise choices so that the timebase is set to a rational number
which suits the data.
All time bases that are not whole multiples of the frame rate will result in PTS rounding.
Currently, the ffmpeg internal time base appears to be 1kHz. So, every frame rate that, when divided
into 1000, doesn't produce a whole number will result in rounded (or truncated) PTSs.
I don't think it is wise for FFmpeg to switch from its present flexible data structure to a
constant, 1/360000 value for timebase. The examples you present do not make the case for such a change.
It doesn't have to be constant. It doesn't have to be 360000Hz. What I'm suggesting is that if it
*is* 360000Hz, that would make a single time base that works for everything. I'm not suggesting that
it be non-modifiable.
I hoped that setting 'settb=expr=1/360000' would produce what I want, but it didn't because ffmpeg's
inherent 1 millisecond time base resolution superseded it. No matter what 'settb' is specified, the
PTS resolution is going to be 1 millisecond.
If you can establish that FFmpeg is imposing a 1/1000 timebase on a video with a 1001/24000
timebase, leading to rounding errors, that is evidence of a bug in FFmpeg's timebase calculation or
something. It is not evidence of the timebase data structure being inadequate.
Technically, it's not a bug. It's a design flaw. The current ffmpeg operates as designed. It's the
design that's flawed.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
