[FFmpeg-devel] [HACK] mov edl desync fix

[Baptiste Coudurier]

Reimar D?ffinger wrote:
> On Fri, Jan 09, 2009 at 02:20:51PM -0800, Baptiste Coudurier wrote:
>> Reimar D?ffinger wrote:
>>> I am really certain this is wrong (does FFmpeg even allow negative
>>> timestamps? They mean the thing you might naively assume them to mean
>>> in this case, namely parts that are "before" the start of the track/video).
>>> Nevertheless it works quite nicely...
>>> At the very least the debug message should be changed to print the track
>>> and the exact delay in seconds so it can be fixed manually.
>>> A sample currently is available here:
>>> http://www.doppelbauer.name/desync.mov
>>> but I guess there are also some somewhere on samples @mphq.
>> Well I'd love to get this fixed, and I would not mind such hack after
>> all, but the problems I see here are:
>>
>> - This is valid if only 1 edit list element is present, so this would
>> need to be checked.
> 
> That's simple to do. Also time values of -1 should be ignored it seems,
> since they mean an empty list (sounds weird, since there is also a
> length entry and it is unclear what other values < 0 are supposed to
> mean).

-1 means ignore this track (do not display it for example) for 'length'
time. This is mentioned in specs IIRC. 'showdown2.mov' is a good example
of what it is, dunno if it's still available somewhere, I might still
have it.

> Though it seems more correct to me to also do this for edls with more
> than one part (of course only the time of the first chunk is relevant),
> attached patch would do that.

I prefer not to do so. Edit list is not about hacking dts, it is about
selectionning specific part of the coded track to take into account.
Better applying the hack when it is safe to do so.

>> - The time value refers to the pts not the dts according to specs,
>> typically this value is 1 for there is delay (first pts is 1 and first
>> dts is 0)
> 
> The specification pdf from May 1996 that I have at hand says nothing
> about that. But assuming that were true, the current check for time != 0
> would be wrong already.

The check is correct, and the message too, that's why it says "might".
In some case it does no harm. Latest qt specs are from 2007, and you can
refer to iso media specs also.

> Also, why does the delay (I assume you mean decoder delay) get hard-coded
> into the pts, after all such stuff depends on the decoder implementation,

What do you mean ?
mpeg2 specs mandates 1 video frame time delay for pts, pts - dts == 1 in
video framerate timebase.

> does mov really assume a specific decoder implementation to code pts?

No, pts are stored in the container.
Edit list says start display at pts 1, by default presentation starts at
pts 0.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no