[FFmpeg-devel] Any suggestion about better handling edit list in mov demuxer.
Wed May 26 21:47:38 CEST 2010
On Thu, May 13, 2010 at 08:24:00PM -0400, David Conrad wrote:
> 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.
what about, if our mov demuxer simply exports the edit lists?
that way our mov muxer could store files with edit lists
The code we would need to handle edit lists in an user app is pretty
much the same that we would need to seek to chapters.
In that sense i also think we maybe should try to use the same API
as we use for chapters. (of course we would need to distingiish real
chapters from edit lists.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel