[FFmpeg-devel] [PATCH] Playlist API

[Michael Niedermayer]

On Mon, Aug 03, 2009 at 11:38:20PM -0700, Geza Kovacs wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > 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 ...
> > 
> 
> I think I'll go for option a) then.
> 
> > 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)
> > 
> 
> As of the latest patch I submitted, this isn't actually a limitation of
> my playlist API. As you can see in ff_playlist_set_streams, every time a
> new playlist item is opened then nb_streams in the playlist demuxer is
> set to be that of the child demuxer and all the streams in the playlist
> demuxer are set to point to the same streams as in the child demuxer,
> even if the number or type of streams has changed, hence yes on the API
> level changing the number and types of streams is fully supported.

well ...
this is leading to a problem that is similar to the seeking one
demuxers arent really supposed to change streams, its possible to
add streams (increase nb_streams) but existing streams shouldnt change.
That is the current API ....
Nothing really prevents us from changing the API but simply not following
it is not a good idea ...
and changing could be tricky as well, i dont know, ive not really considered
it ...

We also have plenty of other things depending on this API, like the seeking
code, i mean it takes a stream_index and timestamp in that
stream index but if streams and thus their timebases can change this really
turns the sementics of the seeking code upside down.

and then there is simply transcoding to a new file, a stream changing type
from video to audio or such is likely not supported by the target container
...


> 
> If an application checks if nb_streams (or the types of each stream) has
> changed and adapts accordingly to accommodate the addition or removal of
> streams, then such functionality as you described would indeed work
> as-is with the current API. The only reason you can't do this with
> ffmpeg right now is that ffmpeg doesn't currently check and adjust its
> settings if nb_streams or the types of streams has changed while reading
> packets; it's not an issue with my API; ffmpeg.c just needs another
> patch to handle changing the number and types of streams after it's
> started reading packets (but since that change to ffmpeg.c is rather
> intrusive I'd rather submit it after my playlist API is accepted upstream).

yes, but would this be less work than having ffmpeg check if a stream hit
its end (check per AVStream.duration or some end of stream packet) and then
search for another not ended/new stream

The problem iam simply seeing, independant of the API is, that if
streams can change arbitrarly how could one really refer to a stream ...

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/20090806/07efd2d7/attachment.pgp>