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

[Michael Niedermayer]

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.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130207/b97bf281/attachment.asc>