On Sat, 21 Jan 2012 17:14:49 +0200 (EET), Martin Storsjö <[email protected]> wrote: > On Sat, 21 Jan 2012, Anton Khirnov wrote: > > > > > On Sat, 21 Jan 2012 14:09:07 +0200, Martin Storsjö <[email protected]> wrote: > >> This avoids reading any old data in the AVIOContext buffer after > >> the seek, and indicates to the mpegts demuxer that we've seeked, > >> avoiding continuity check errors. > >> --- > >> libavformat/applehttp.c | 4 ++++ > >> 1 files changed, 4 insertions(+), 0 deletions(-) > >> > >> diff --git a/libavformat/applehttp.c b/libavformat/applehttp.c > >> index 38023f6..3ee233f 100644 > >> --- a/libavformat/applehttp.c > >> +++ b/libavformat/applehttp.c > >> @@ -700,6 +700,10 @@ static int applehttp_read_seek(AVFormatContext *s, > >> int stream_index, > >> av_free_packet(&var->pkt); > >> reset_packet(&var->pkt); > >> var->pb.eof_reached = 0; > >> + /* Clear any buffered data */ > >> + var->pb.buf_end = var->pb.buf_ptr = var->pb.buffer; > >> + /* Reset the pos, to let the mpegts demuxer know we've seeked. */ > >> + var->pb.pos = 0; > >> > >> /* Locate the segment that contains the target timestamp */ > >> for (j = 0; j < var->n_segments; j++) { > >> -- > >> 1.7.3.1 > >> > > > > Manipulating AVIOContext internals like this from a demuxer makes me > > uneasy. Maybe this should be a separate avio function. > > Perhaps it should. Note though, this is not the demuxer's normal input > AVIOContext - this is the custom AVIOContext that the applehttp demuxer > provides as input to the mpegts demuxer, so it's a bit more ok to meddle > in its internals than for a normal demuxer. But perhaps it still should be > a separate function? >
Yes, I think it should if it's not too much trouble. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
