[FFmpeg-devel] Any suggestion about better handling edit list in mov demuxer.

John Stebbins stebbins
Fri May 14 02:34:14 CEST 2010

On 05/13/2010 04:22 PM, Michael Niedermayer wrote:
> On Wed, May 12, 2010 at 04:25:19PM -0700, Thierry Foucu wrote:
>> On Wed, May 12, 2010 at 8:30 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
>>> On Wed, May 12, 2010 at 10:24:50AM +0200, elupus wrote:
>>>>>    - Adding a flag to AVPacket like DROP_AFTER_DECODER, in which case
>>> the
>>>>>    demuxer could mark which packet will be needed to be dropped after
>>> decoding,
>>>>>    and  av_read_frame will still return them to pass them to the
>>> decoder.
>>>> This i think is the best aproach. It is something that can be used for
>>>> seeking aswell. (and matches very well what we already do in xbmc after
>>>> seeks).
>>> it will not work with audio as audio is simply not encoded with the
>>> same packet rate as video. There would be too much or missing audio.
>>> I thus think a solution that can handle sample accuracy and not just
>>> packet accuracy is needed
>> Agreed, that should the optimal solution. But are we not talking about a
>> maximum lipsync problem of 1 audio frame per chunk? which could be less than
>> 1 video frame duration?
> i dunno about mov but in avi 0.5 second long audio frames are not that
> uncommon thats enough to cause problems i think.
> but lets first awnser a few questions (i dont know much about edit lists)
> it was said that edit lists can ignore keyframes. This alone already looks
> problematic, i mean if we have a 300 frame gop and an edit list starts at the
> last frame then once this edit list becomes "active" we would have to very
> quickly decode 10 seconds of video to show the next frame. This almost
> certainly would cause problems to some players no matter how we implement it
> So do edit lists in actual files really refer to non keyframes?
> Also does the official (qt) player really display that non keyframe or does
> it drop things until the next keyframe?
> Iam trying to understand better how the actually used cases look because
> the generic case is not implementable. (just think of a 2 hour file with
> only 1 keyframe at the very begin)
Yes, I'm relatively certain edit lists can refer to non keyframes.  In
fact, I think I uploaded such a sample recently when reporting another
problem.  Subject was "mov demux fails to seek all streams to beginning
of file".  Uploaded file was
MPlayer/incoming/mov-edit-list-seek/edit-list-seek-problem.mov. That
file, when played by ffmpeg actually shows 5 seconds of video that it
shouldn't. The first video frame starts at time index -5588 (which is a
keyframe).  The video should actually start playing at time index 0. 
The next keyframe is at time indes 4412 (if I'm interpreting things
correctly).  FYI the first audio packet in this file starts at time
index -10.  Audio should also start playing at time index 0 I believe.

More information about the ffmpeg-devel mailing list