[FFmpeg-devel] Patch to add support for handling multiple edit lists in MOV files

[Baptiste Coudurier]

Hi,

On 2/18/2009 1:41 PM, Krishna Gadepalli wrote:
> I have attached a patch to add support for multiple edit list in MOV
> files. I ported this over from Xine (demux_qt.c)It seems to fix the
> av sync issue in menace00.mov and bedroses.mov (hard to see this one)
> in http://samples.mplayerhq.hu/mov/editlist I cant see (or rather
> hear) the av sync issue with the other samples in that directory.
> 
> This patch removes the time_offset code which addressed only the
> single edit-list case - since it handles that case also.
> 
> Any feedback is appreciated...

Comments:

Code uses 2 spaces indentation while FFmpeg codingstyle uses 4 spaces.

Isn't it possible to "adjust" timestamps in mov_build_index directly
before adding the AVIndex entry ?

I don't think this is 100% correct. Let me explain. The way I understand
edit lists and the way quicktime seems to handle them, is basically a
way to extract specific part of stream to "display".

Let me take 2 concrete examples:

First is H.264 track which has first pts set to 1 (by pts I mean cts ==
1, dts == 0 in quicktime/mp4), and first edit list entry having time set
to 1. Second track is AAC audio track with no edit list.

Based on the way quicktime displays it, first H.264 frame is displayed
straight when opening the file, along with corresponding audio. When you
offset even more the video track, the corresponding video frame is
displayed straight while audio track still start at the beginning.

This means that first pts _and_ dts must be adjusted to honor the
_offset_ declared in first edit list entry to match the audio track and
keep A/V sync. I believe this is a hack because timestamps should not be
adjusted, but the extraction should happen at higher level in FFmpeg or
application, even more when edit list entry time can "cut" or "trim" an
audio frame within encoded samples.
.
The previous code from Reimar did this correctly by offsetting the first
dts and pts, this hack was right when edit list contain only one entry,
this is why it was applied

Second example is "showdown2.mov" which contains 2 video tracks and one
audio track:

audio track (aac):
edit list entry duration   5000 time -1
edit list entry duration 532413 time 315

video track 0 (svq3):
edit list entry duration   5000 time -1
edit list entry duration 534771 time 6230

video track 1 (gif):
edit list entry duration   5000 time 0
edit list entry duration 534771 time -1
edit list entry duration   2500 time 1200

So basically audio and video track 0 dts/pts start at 5000, data to
display must be extracted at specified time (IIRC aac offset in track is
within a frame), gif must be displayed for 5000, then gif track is
disabled for the duration of svq3 and audio track then reenabled for
2500 at position 1200, while others are disabled.

This is _really_ complicated IMHO.

I believe your patch might still be ok if it would correctly offset
timestamps.

Currently for case 1 first pts and are 1 and 0 while they should be 0
and -1, and for case 2 first dts and pts are still 0 while they should
be 5000 rescaled to track time scale.

I hope this helps.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org