[FFmpeg-devel] [PATCH] Playlist API

Ronald S. Bultje rsbultje
Sat Aug 8 03:35:46 CEST 2009


On Fri, Aug 7, 2009 at 4:23 PM, Michael Niedermayer<michaelni at gmx.at> wrote:
> On Fri, Aug 07, 2009 at 11:52:54AM -0400, Ronald S. Bultje wrote:
>> - you want to be able to represent a AVPlayList as a AVFormatContext
>> under certain conditions, but you want to add the AVFormatContext
>> constraints here: 1 set of metadata covering the whole media; 1 set of
>> streams covering the whole media (this might imply that the demuxer
>> should call decoder functions so that the raw output has the same
>> codec across the whole stream; in case of video + audio, followed by
>> audio-only, it might also include gaps for certain streams).
> ehm, i think that is not such a good idea
> either the AVFormatContexts API can handle it or not but trying to sequeeze
> a square in a round hole does not seem like such a good idea.
> I mean if we can make playlists available through AVFormatContext that would
> be great but if that involved reencoding things to make them be in the same
> codec then that really goes too far ... and it would open a really dark and
> evil box (figuring out which streams are te right ones amongth other things
> like which codec, width/height ... to use)

Well, what I'm thinking of is the kind of "hack" that video editors
commonly do. This is probably not code that would ever land in FFmpeg
trunk, it's more conceptually: it's to be able to put three videos of
different codecs, sizes etc. in a row and play them back and recode
them as a single stream. Look at iMovie or any other movie editor:
they'll add the black bars or do resizing (or both) for you, including
adapting framerate to a common value for all streams so that the
output is a single one.

That representation of the single stream, in the not-yet-transcoded
edit-file (not the output after pressing File -> Export), but where
framerate/size are similar and video is "decoded", could be a
AVFormatContext representation or a AVPlayList, and that's what I was
referring to. I know it's hacky, but I was just thinking aloud in

In alternative paths, I'd prefer having a new object, again, because
we seem to be dragging AVFormatContext into areas that it wasn't
designed for and that seems out-of-scope for it.


More information about the ffmpeg-devel mailing list