[FFmpeg-devel] [PATCH 0/2] fix for seeking in HLS with FMP4 media

[vectronic]

I am again updating and resubmitting a patch which fixes the following ticket:

https://trac.ffmpeg.org/ticket/7359

This fix has been tested and recommended by several people now and I have been using it in production successfully since I submitted it 6 years ago...

The main patch in the series fixes HLS seeking when the HLS package consists of fmp4 files. It mirrors behaviour from mpegts.c in mov.c.

The issue can be demonstrated as follows:

ffmpeg -ss 9 -i http://vectronic.io/hls_seek_issue/fmp4/in.m3u8 -t 3 out.mp4

This produces a zero duration output file.

With the patch applied, the example produces a 3 second output file as expected.

------

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 corresponding 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 */

This behaviour needed to be mirrored in the mov demuxer. In mov.c it now detects if the pos has been reset in mov_read_packet(). It clears fragments and indexes and searches for the next root i.e. the next fragment via mov_switch_root().

The second patch in the series simply improves a comment about this behaviour in hls.c


vectronic (2):
  avformat/mov: if pos has been reset, clear fragments and indexes and
    search for next root
  avformat/hls: improve comment

 libavformat/hls.c |  2 +-
 libavformat/mov.c | 39 ++++++++++++++++++++++++++++++++++++---
 2 files changed, 37 insertions(+), 4 deletions(-)

-- 
2.39.5 (Apple Git-154)