[FFmpeg-devel] [PATCH] Playlist API

[Geza Kovacs]

-----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.

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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp311sACgkQs6+5LdXBeIJLwgCfYHIpzqKTXZ1xtWRC8c1q9KPM
Cn0An0CqjRQCgT/jq+N+GUg7fqZ6vLwA
=xzH4
-----END PGP SIGNATURE-----