[FFmpeg-devel] [PATCH] Playlist API

[Michael Niedermayer]

On Fri, Jul 31, 2009 at 09:41:54PM -0700, Geza Kovacs wrote:
[...]
> >> +int ff_concatgen_read_seek(AVFormatContext *s,
> >> +                           int stream_index,
> >> +                           int64_t pts,
> >> +                           int flags)
> >> +{
> >> +    PlaylistContext *ctx;
> >> +    AVFormatContext *ic;
> >> +    ctx = s->priv_data;
> >> +    ic = ctx->pelist[ctx->pe_curidx]->ic;
> >> +    return ic->iformat->read_seek(ic, stream_index, pts, flags);
> >> +}
> > 
> > seeking should work over playlist items, not just within a playlist item
> > this doesnt look correct thus ...
> > 
> 
> I don't think automatically switching the current item while seeking is
> desirable - any non-trivial piece of software would probably want to
> have some form of "now playing" notification displayed when switching
> videos or songs, so most software would probably want to manually
> control the switching anyhow and use the seeking API simply for seeking
> within the same playlist item.

playlists pretend to be demuxers and seeking for demuxers really is supposed
to work over the whole media represented by that demuxer. Thats also what
you get when it is transcoded to a new file.

also
ffmpeg -i A B
seeking in A and B should behave the same as far as the containers support
it. Now if A is a playlist that isnt what would happen ...

What that really means is that either
a. seeking should work over the whole media represented by a demuxer
   this might be hard in some cases (where duration of the individual
   elements is not known)

b. the seeking API for demuxers would need to be changed so that ANY
   demuxer could present its timeline in a funny, broken not fully seekable
   way. This of course would need to be discussed with all its justifications
   advantages and disadvanatges and it would need to be approved.
   Theres also alot of considerations about the symmetry between demuxers and
   muxers and such that need to be considered

c. playlist would need to be implemented differently, not pretending to be
   demuxers

Its true, its a little late for this discussion but that doesnt help us
the design has to be discussed, especially as it seems it has some problems
like about changing stream number ...

in that respect, the current code also doesnt support the playlist files
it claims it does because they AFAIK can contain files with different stream
numbers.
A realistic example would be some mp3s (audio only) with some music videos in
avi with video and audio (and possibly even subtitles)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090803/3816a27c/attachment.pgp>