[FFmpeg-devel] codec & streams time bases transcode

Michael Niedermayer michaelni at gmx.at
Fri Aug 3 16:12:17 CEST 2012


On Fri, Aug 03, 2012 at 03:51:08PM +0200, Clément Bœsch wrote:
> On Fri, Aug 03, 2012 at 03:29:02PM +0200, Michael Niedermayer wrote:
> > On Wed, Aug 01, 2012 at 05:27:41PM +0200, Clément Bœsch wrote:
> > > Hi,
> > > 
> > > I'm working on ticket¹ about an issue while transmuxing a MOV. The
> > > original file contains a timecode, which is transmitted through metadata
> > > and thus a timecode track is written as well in the output.
> > > 
> > > Unfortunately, the codec time base received in the MOV muxer is invalid:
> > > 2997/1 instead of 1001/30000 (or something like 2997/100), which make the
> > > timecode init fails (can be workarounded with -r 30000/1001 for example).
> > > 
> > > This happens because of the heuristics around line 3000 in ffmpeg.c where
> > > the codec time base copy is not triggered (it will work if transmuxing to
> > > MXF on the other hand). Reverting 618fb9cc fixes the issue, but will break
> > > some other stuff, so it's not a solution.
> > > 
> > > All of this time base copies and heuristics look pretty fragile to me (and
> > > are actually broken in this case); anyone has any thoughts about what
> > > could be done here, and this is supposed to be fixed?
> > 
> > The stream copy timebase heuristics have the goal to select a timebase
> > that allows efficient representation of the input.
> > 
> > While 1576 is about a input file with timebase 2997 or 2997/100 and
> > you want the output to have a different timebase namely 30000/1001
> > 
> > I would say, its not a failure of the heuristics but rather that you
> > want them to do something they had not been designed to do at all.
> > They could be changed to do that of course ...
> > 
> > also theres another question, should 2997/100 always be replaced by
> > 30000/1001 or not ? if not then when should it ? the question matters
> > for improving the heuristics
> > 
> 
> 2997/100 is fine; I'm using the timebase to compute the frame rate and
> this value will be rounded to 30 (which is assumed to be NTSC,
> 30000/1001). OTOH 2997/1 isn't since it's not a valid frame rate.

I had misunderstood the issue partially then ...


> 
> Indeed maybe I'm wrong using time base for this. The two attached patches
> propose an alternative solution: if the time base looks wrong, fallback on
> the average frame rate for the stream.

> Maybe I should use the average
> frame rate unconditionally all the time?

that would make sense, but may with frames drops fail to be what
its expected to be

patch LGTM

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/20120803/2d2d1f40/attachment.asc>


More information about the ffmpeg-devel mailing list