[FFmpeg-devel] [PATCH] Playlist API

Michael Niedermayer michaelni
Sat Aug 1 18:43:48 CEST 2009

On Fri, Jul 31, 2009 at 09:41:54PM -0700, Geza Kovacs wrote:
> 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
> 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.

all codecs require pts >= dts, that follows from the definition,
dts being the time when a frame is decoded, pts the one when it is
presented to the user (decoding must happen before presentation)

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

transcoding several concatenated files to a
new file. The new file should behave like the original concatenated list,
anything else would be quite confusing because the result would just not be
what the source was ...

IMHO seeking should work accross the whole concatented list and its individual
elements should be presented as AVChapters, this achives above, if you have a
better idea that is welcome of course

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

i meant one video that uses 3 concatenated mp3s as audio, like a music

a seperate thing would be concatenating videos that each have several audio
streams (that is for different languages) but some languages only for one
of the 2

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- 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/20090801/b2984969/attachment.pgp>

More information about the ffmpeg-devel mailing list