HLS not accurately seeking on TS

[Louis Letourneau]

Summary of the bug:
Seeking accurately in HLS videos doens't work, but it
works fine in other containers (mp4, mkv, etc)

tried with ffmpeg version 3.4.4 and master f85fa100db7d35952

% ./ffmpeg version N-92147-gf85fa100db Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
configuration: --enable-libfreetype --enable-gpl --enable-libx264 --enable-libx265 --enable-nonfree --enable-libfdk-aac --enable-libopus --enable-libpulse --enable-libvpx --enable-openssl --enable-static
libavutil      56. 19.101 / 56. 19.101
libavcodec     58. 32.100 / 58. 32.100
libavformat    58. 18.104 / 58. 18.104
libavdevice    58.  4.105 / 58.  4.105
libavfilter     7. 33.100 /  7. 33.100
libswscale      5.  2.100 /  5.  2.100
libswresample   3.  2.100 /  3.  2.100
libpostproc    55.  2.100 / 55.  2.100

How to reproduce:
Create an HLS video like this

% mkdir a
% ./ffmpeg -y -s 640x480 -f rawvideo -pix_fmt rgb24 -r 25 -i /dev/zero -vf "drawtext=fontfile=/usr/share/fonts/truetype/freefont/FreeMono.ttf: text=%{n}: x=(w-tw)/2: y=h-(2*lh): fontcolor=white: box=1: boxcolor=0x000000FF" -an -vcodec libx264 -preset medium -tune stillimage -crf 24 -pix_fmt yuv420p -shortest -force_key_frames "expr:gte(t,n_forced*5)" -bf 0 -hls_time 5 -hls_list_size 0 -hls_wrap 0 -hls_allow_cache 1 -hls_segment_filename "a/a_%04d.ts" -t 60 a/a.m3u8

And also create it's mp4 counterpart:

% ./ffmpeg -i a/a.m3u8 -codec copy a.mp4

And try to seek in any segment:

F=130;rm -f f.png;./ffmpeg -y -ss `awk "BEGIN {print (${F})/25}"` -i a/a.m3u8 -f image2 -q:v 1 -vframes 1 f.png
./ffplay f.png

Got frame 250 (bad)

F=126;rm -f f.png;./ffmpeg -y -ss `awk "BEGIN {print (${F})/25}"` -i a/a.m3u8 -f image2 -q:v 1 -vframes 1 f.png ; feh f.png

Got frame 250 (bad)

F=125;rm -f f.png;./ffmpeg -y -ss `awk "BEGIN {print (${F})/25}"` -i a/a.m3u8 -f image2 -q:v 1 -vframes 1 f.png
./ffplay f.png

Got frame 125 (good)

F=124;rm -f f.png;./ffmpeg -y -ss `awk "BEGIN {print (${F})/25}"` -i a/a.m3u8 -f image2 -q:v 1 -vframes 1 f.png
./ffplay f.png

Got frame 125 (bad)

Now try the same with the mp4 and you'll always get the exact right frame

F=130;rm -f f.png;./ffmpeg -y -ss `awk "BEGIN {print (${F})/25}"` -i a.mp4 -f image2 -q:v 1 -vframes 1 f.png
./ffplay f.png

Got 130 (good)

F=126;rm -f f.png;./ffmpeg -y -ss `awk "BEGIN {print (${F})/25}"` -i a.mp4 -f image2 -q:v 1 -vframes 1 f.png
./ffplay f.png

Got 126 (good)
etc

it seems to only be seeking on segment boundaries.

[Louis Letourneau]

Work from Nick Ryan solves the issue it seems:
​https://patchwork.ffmpeg.org/patch/10767/

[Balling]

Again the patch is there.

[vectronic]

Patch has been reworked based on comments and resubmitted:

​https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1018

​http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261341.html

[Balling]

Please apply ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220128202320.1711694-1-gustav.grusell@gmail.com/

[SuRGeoNix]

I think this is related with this ​https://trac.ffmpeg.org/ticket/9356

It's been a long time for this one and couple of patches are existing already.

[Balling]

e78d0810d1741535c95e5ae0f198977626b1cdff fixes it, indeed.

ffmpeg -ss 3 -i ​http://vectronic.io/hls_seek_issue/ts/in.m3u8 -t 2 out.mp4

produces not 262 bytes files and to ts does not produce 0 bytes file.
ffmpeg -ss 3 -i ​http://vectronic.io/hls_seek_issue/fmp4/in.m3u8 -t 2 out.mp4

still is bad, since fmp4 requires ​http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261343.html but that is #7359.

THAT MUST BE fixed ASAP too.

[R. Linden]

Any update onto this?

[Balling]

Replying to R. Linden:

Any update onto this?

This one is fixed.

[SuRGeoNix]

I tried the latest from master and I'm still having issues seeking in HLS/TS (loops). Still requires the ​https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1018 patch work properly. I will try to do more testing and give you an update.

[Balling]

The fmp4 issue is also fixed, in 380a518c439d4e5e3cf17b97e4a06259e8048f99

[ThomasC]

Also experiencing this still as of version 6.0 with HLS (TS) streams, but I assume this is the case with later versions too as vectronic's patch seems to resolve this issue but has not been applied upstream afaict?

Here is the my current usage which should seek the stream to zero (first keyframe) but instead seeks to the second keyframe:

av_seek_frame(format_ctx, stream_index, 0LL, AVSEEK_FLAG_BACKWARD);