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

[Robert Krüger]

On Wed, Feb 6, 2013 at 6:49 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Feb 06, 2013 at 12:20:22PM +0100, Robert Krüger wrote:
>> 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.
>
> A better solution is welcome if you know one, but when you add into
> the "equation" that some major players do not support edit lists
> it gets tricky to achive AV sync by shifting the audio.

this is a misunderstanding. I did not suggest using edit list for
achieving av sync (in fact I try to avoid them for the reasons you
outlined). My point was that AFAIK only _if_ someone uses edit lists
to achieve av sync, a large enough timescale (but in that case movie
timescale) can become an issue of concern but that is not what the
commit changed.

>
> Also if you consider 2 video streams, lets say 25fps and 30fps
> instead of limiting yourself to 1 video stream things dontg get easier.
> simply working with timebases that are finegrained enough seemed the
> simplest solution to me but iam surely not unhappy if someone
> implements a better solution

Again a misunderstanding, I think. I simply still do not understand
what the commit solves. Take your example of a mov with 2 video
streams, one (let's say track 0) 25 FPS, the other (let's say track 1)
30 FPS and let's add an audio stream with 48 kHz sample rate.

Before the commit one would typically have had:

track 0: media timescale 25 (AVStream.time_base 1/25)
track 1: media timescale 30 (AVStream.time_base 1/30)
track 2: media timescale 48000 (AVStream.time_base 1/48000)

Movie timescale would have been 1000 (i.e. edit-list entry duration or
container duration would have had a precision of milliseconds)

Any demuxer could produce accurate packet timestamps to achieve
perfect sync for all three streams with any precision it wants to use.

After the commit:

track 0: media timescale 25 (AVStream.time_base 1/12800)
track 1: media timescale 30 (AVStream.time_base 1/15360)
track 2: media timescale 48000 (AVStream.time_base 1/48000) (unchanged)

Movie timescale is 1000 (unchanged)

Which is of course just as good but I still fail to see where it makes
anything better in terms of av sync unless you want to protect API
users from shooting themselves in the foot by specifying a timebase
which is not at all suitable for the stream but that is not your
reason for the change, or is it?

On the other hand, you restrict the API user in choosing the timebase
and thus the maximum recording time before 32bit overflow happens.
This is a very far-fetched argument, I admit because I doubt many
applications (even surveillance cameras) need more than the 93 hours a
timescale of 12800 allows.

Sorry for being a pain in the ass but I just want to understand why.
Again, technically the code works fine (IMHO before and after the
change) and if you don't want to spend more time explaining this, I
understand. If I want to be able to specify other timebases I can of
course always revert the change locally. I just wanted to make sure I
am not missing something.

Regards and thanks for your time.

Robert