[FFmpeg-devel] [PATCH] Playlist API
Thu Jul 16 02:59:02 CEST 2009
> Iam not against an API to work with playlists programmatically, that surely
> could be usefull, but i dont feel this is the right part to start reviewing.
> The way i see it, and iam of course open to suggestions and comments ...
> * There are many applications using libav*, the less modifications they need
> to support a new feature, the better.
> From this it follows that a play list protocol&demuxer should ideally build
> its playlist from the string provided by the user.
> That way, something like ffmpeg -i localfile.mpg,http://www.a.com/xyz.avi
> could work with minimal changes to ffmpeg.c
> That of course does not preclude a API to manipulate playlists from C, but
> that seems secodary to me because its design might be affected by the
> other requirements ...
I already had that implemented using multiple input files and a "-conc"
flag, but I've added your suggested interface as well. In the patch,
there are thus 3 ways to input playlists (the first 2 are implemented
with a patch against ffmpeg.c, the third will work on anything using
1. ffmpeg -i file1.avi,file2.mp4,file3.avi
2. ffmpeg -conc -i file1.avi -i file2.mp4 -i file3.mp4
3. ffmpeg -i playlist.m3u (pls and xspf formats also implemented in patch)
> * We like to be able to transcode playlists, so that a avi+mpg can be
> reencoded, into lets say a .mov.
> Not only that but we also like the new .mov and the previous playlist
> to represent their data to the user similarly so that applications dont
> need to have 2 ways to extract things like (song)title for each part.
> The obvious choice here would be the AVChapters of the .mov as well as
> the AVChapters of the playlist demuxer ...
Also already implemented, see concatgen.c in the patch for how this is done.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 44128 bytes
Desc: not available
More information about the ffmpeg-devel