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

[David Conrad]

On May 13, 2010, at 7: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?

It's easy enough to create such files, no clue how often they're distributed however.

> Also does the official (qt) player really display that non keyframe or does
> it drop things until the next keyframe?

Yes, it would attempt to decode and display that non-keyframe (and all of its dependencies.) However, during playback it doesn't do anything special with decode timings so it will stutter horribly at the transition (or take longer to open the file if it's at the start.) When transcoding it'll do the right thing and put the non-keyframe where the file says, taking as much decode time as it needs to do so.

> 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, QuickTime should be able to handle even the case where the actual move is a series of images different two hours of non-displayed dependencies. Obviously only when transcoding and taking a ton of CPU though.