[FFmpeg-devel] [PATCH] Playlist API

Geza Kovacs gkovacs
Sat Aug 1 06:41:54 CEST 2009

Hash: SHA1

I believe this updated patch, where I'm using a list of AVFormatContext
rather than PlayElem and using a single durations list rather than
per-stream time offsets should address most of issues you pointed out.

>> +            pkt->dts += time_offset;
>> +            if (!ic->streams[pkt->stream_index]->codec->has_b_frames)
>> +                pkt->pts = pkt->dts + 1;
> whatever that is, it is wrong

pkt->dts is offset to ensure that timestamps reflect the actual time the
packet it relative to the concatenated stream, rather than resetting
timestamps to 0 for every new playlist item, so that streams are
appended onto the ends of each other, rather than overlapping (ie if you
don't modify pkt->dts, if you have video 1 with length 5 seconds and
concatenate it with video 2 with length 10 seconds, you only get a video
of length 10 seconds with all 5 seconds of video 1 and the last 5
seconds of video 2).

As for pkt->pts, certain codecs, require that it be greater than the
value of dts, hence it's set to pkt->dts+1, except when using b-frames
in which case it's not modified.

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

>> +    // alternative interface for concat - specify -i item1,item2,item3
> why 2 interfaces?

I've removed the first interface (-conc -i file1 -i file2) in this
patch, since you seem to prefer the comma-separated list approach (-i
file1,file2), hence only 1 interface is present now.

> also does mixing concateated inputs and non concatenate inputs work?
> that is if we want to combine a single moview with 3 concatenated mp3s

Since you're talking about mixing concatenated and non concatenated
inputs, I'm assume you meant "m3u" not "mp3"? (If you really did mean
mp3, I don't think concatenating audio-video files with pure audio files
is a good idea, since there wouldn't be anything to display except a
blank screen while the audio is playing and the video stream has run
out, which I'm fairly certain isn't the intent of the user). Anyhow, yes
something like this, which chains concat/playlist demuxers, does
currently work:

ffmpeg -i playlist.m3u,file5.mp4,file6.avi output.avi

(Where playlist.m3u is contains files 1-4 of the overall playlist, and
output.avi would be the concatenated output of all 6 item.)
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-concat.diff
Type: text/x-patch
Size: 39853 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090731/437bc5a8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-concat.diff.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090731/437bc5a8/attachment.pgp>

More information about the ffmpeg-devel mailing list