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

[Robert Krüger]

On Thu, Feb 7, 2013 at 11:13 AM, Robert Krüger <krueger at lesspain.de> wrote:
> 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

A colleague of mine who read this thread said, you might be talking
about the case of non-zero start offsets in which case the api user
has to notice/detect that the specified timebase will not be good
enough for acceptable sync (without your commit). If that is the case
and since this is not really mov-specific the better solution you are
talking about is probably to handle this outside of the muxer in the
transcoding code or in some utility function that selects a suitable
timebase for a given case?