On Sat, Feb 27, 2021 at 2:56 AM Mark Filipak (ffmpeg) <markfili...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".
