On Fri, 27 Jan 2012, Martin Storsjö wrote:
On Sat, 21 Jan 2012, Anton Khirnov wrote:
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.
So, should it be one function for setting buf_end = buf_ptr = buffer, e.g.
ffio_clear_buffer(), and another one for setting pos to 0? Or should it do
both of them, e.g. ffio_clear_restart_buffer()? Also, perhaps they should be
public? They're useful for anyone who uses custom avio to push data into a
demuxer.
10:55 <wbs> elenril: http://patches.libav.org/patch/15548/ - missing your
suggestion on how to factorize stuff to move forward
10:55 <wbs> elenril: or perhaps I should just apply it and let you
factorize it afterwards? ;-)
10:57 <elenril> ok, go ahead
So, pushing this for now since it fixes a real bug, letting Anton
factorize it afterwards in the way he prefers.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
