[FFmpeg-user] How can I force a 360kHz time base?

Paul B Mahol onemda at gmail.com
Sat Feb 27 04:29:17 EET 2021


On Sat, Feb 27, 2021 at 2:56 AM Mark Filipak (ffmpeg) <markfilipak at bog.us>
wrote:

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


You are living proof that universe is finite and human stupidity/ignorance
is not.


> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-user mailing list