[FFmpeg-devel] codec & streams time bases transcode

[Clément Bœsch]

On Fri, Aug 03, 2012 at 04:12:17PM +0200, Michael Niedermayer wrote:
> 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
> 

Pushed.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120808/dc076904/attachment.asc>