[FFmpeg-devel] [PATCH 0/1] Trying to fix trac ticket #7359
Nick Ryan
nick.paul.ryan at gmail.com
Wed Sep 26 16:33:00 EEST 2018
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)
More information about the ffmpeg-devel
mailing list