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

[Robert Krüger]

On Thu, Feb 7, 2013 at 6:09 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Feb 07, 2013 at 02:08:05PM +0100, Robert Krüger wrote:
>> 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
>
> yes, thats what i meant, if you have for example a 25fps + 24fps video
> and you start from a point other than its first frame than the
> timebases need to be more precisse
>
>
>> 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?
>
> Its all a bit tricky, the outside code might not know that it will
> need more precisse timebases before it actually sees a frame that it
> cant represent in the timebase it choose.
> And the timebases for muxers are choosen by the muxers, for example
> mpeg-ps always uses 90khz as thats what mpeg-ps needs.
>

Thanks a lot for the explanations!