[FFmpeg-devel] commit b02493e47668e66757b72a7163476e590edfea3a force video timebase to be 0.1ms precisse at least.

[Robert Krüger]

On Tue, Feb 5, 2013 at 10:39 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Feb 05, 2013 at 01:30:39PM +0100, Robert Krüger wrote:
>> Hi,
>>
>> the commit message was
>>
>>     The timebases before where only guranteed to be 1/fps precisse
>>     and could cause AV sync errors on low fps
>>
>> Is there a track issue that is fixed by this? Would it be possible to
>> explain how 1/fps as a timebase for the video track would cause AV
>> sync errors?
>
> there was a bug, not sure where it was reported
> the issue basically is that with a 1/25 timebase you can only
> specify each frames timestamp in 1/25 second precission, so you
> cannot avoid av sync errors on that scale if the actual true timestamps
> fall in between the representable points
>
> one can argue about if 1/25 is good enough but consider a 1fps slide
> show, there it does make a difference if everything is offset by
> 0.5sec
>

Thanks for taking the time to respond.

I may be wrong but I thought the timescale in the mdhd header was only
for the track (the media timescale in Quicktime terminology) and if
the video track only has a timescale of the frame rate (if it is an
integer frame rate) was good enough for perfect av sync if the
timescale for the audio track was precise enough for the audio track
(e.g. sample rate), regardless of whether the video timescale is 1 for
1 FPS or 25 for 25 FPS. Of course this is different for the movie
timescale (in the mvhd atom), which is used for edit lists which will
cause av sync issues if it is chosen too small but in this case ist is
the media timescale AFAICS (and the movie timescale seems to be
hardcoded to 1000 which is probably good enough for all practical use
cases). That was why I asked. I simply don't understand in which case
the change can affect av sync for fixed integer frame rate content
compared to setting the media timescale of the track to the frame
rate.

The current code does not really cause any problems here, I was just
trying to understand why it was necessary. Except for being a little
bit less convenient for debugging there is of course no disadvantage
of a higher timescale, at least I cannot see one. I just ran into
problems because it broke our application code because we had not
checked whether avformat_write_header had changed the stream timebase
which resulted in broken files when we had specified 1/25 as the
stream timebase in our muxing code but the packet timestamps were
still based on the 1/25 timebase we had set (our fault, of course, as
that behaviour is documented in the doxy for AVStream.time_base and
muxing.c contains a correct example rescaling the pts's for packets
accordingly).

Regards,

Robert