Hello, With reference to:
https://trac.ffmpeg.org/ticket/7359 I believe another way this issue manifests itself is using ffplay and trying to seek forward 10 seconds with the right arrow key: playback freezes. I have dug into this and developed a hack which seems to resolve the issue, BUT I have no idea if this is a valid, correct fix. I have a local m3u8 file which was showing this problem and I can now programmatically seek to the correct point. I can also seek correctly via ffplay and ffmpeg. I have also tried the URL from the trak ticket and this now works as well. All current fate samples tests pass. I submit the patch here for anyone that knows more about the codebase. I am happy to rework etc. as required. At the very least it might help anyone experiencing this problem in the meantime if they wish to run a patched ffmpeg version. Within hls.c when hls_read_seek() is called it resets the stream position as follows: /* Reset the pos, to let the mpegts demuxer know we've seeked. */ pls->pb.pos = 0; There is support for this in the mpegts handle_packets() code to check if the position has been reset and clear out any PES packets: if (avio_tell(s->pb) != ts->last_pos) { int i; av_log(ts->stream, AV_LOG_TRACE, "Skipping after seek\n"); /* seek detected, flush pes buffer */ I have basically tried to do the same ‘reset’ logic within mov.c mov_read_packet() and force a search for the next mov root. Regards, Nick Nick Ryan (1): Trying to fix trac ticket #7359 libavformat/mov.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) -- 2.17.1 (Apple Git-112) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
