#5853 closed defect (invalid)
M3U8 seeking is off or frame count is off
Reported by: | Louis Letourneau | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | hls |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
There are 2 mutually exclusive (but seem to be related) bugs
1- When seeking, the position seeked to is off by many frames.
2- When counting frames with ffprobe the number given is higher than expected
How to reproduce:
From master/HEAD:
% rm -f dude.png ; ./ffmpeg -y -ss 0 -vsync 0 -i https://s3.amazonaws.com/slffmpegdebug/seekProb/seekProb.m3u8 -f image2 -q:v 1 -vframes 1 dude.png ; feh dude.png ffmpeg version N-81699-g590f025 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010 configuration: --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-openssl --enable-static libavutil 55. 29.100 / 55. 29.100 libavcodec 57. 57.100 / 57. 57.100 libavformat 57. 49.100 / 57. 49.100 libavdevice 57. 0.102 / 57. 0.102 libavfilter 6. 62.100 / 6. 62.100 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc 54. 0.100 / 54. 0.100 https://s3.amazonaws.com/slffmpegdebug/seekProb/seekProb.m3u8: could not seek to position 1.400 Input #0, hls,applehttp, from 'https://s3.amazonaws.com/slffmpegdebug/seekProb/seekProb.m3u8': Duration: 00:01:05.07, start: 1.400000, bitrate: 0 kb/s Program 0 Metadata: variant_bitrate : 0 Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc Metadata: variant_bitrate : 0 Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 0 [image2 @ 0x26f12a0] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. Output #0, image2, to 'dude.png': Metadata: encoder : Lavf57.49.100 Stream #0:0: Video: png, rgb24, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc Metadata: variant_bitrate : 0 encoder : Lavc57.57.100 png Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> png (native)) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:05.07 bitrate=N/A speed= 11x video:570kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
I did notice the message could not seek to position 1.400
although I asked 0.
In any case it doesn't give the same image as
(notice the absence of -ss 0)
% rm -f dude.png ; ./ffmpeg -y -vsync 0 -i https://s3.amazonaws.com/slffmpegdebug/seekProb/seekProb.m3u8 -f image2 -q:v 1 -vframes 1 dude.png ; feh dude.png ffmpeg version N-81699-g590f025 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010 configuration: --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-openssl --enable-static libavutil 55. 29.100 / 55. 29.100 libavcodec 57. 57.100 / 57. 57.100 libavformat 57. 49.100 / 57. 49.100 libavdevice 57. 0.102 / 57. 0.102 libavfilter 6. 62.100 / 6. 62.100 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, hls,applehttp, from 'https://s3.amazonaws.com/slffmpegdebug/seekProb/seekProb.m3u8': Duration: 00:01:05.07, start: 1.400000, bitrate: 0 kb/s Program 0 Metadata: variant_bitrate : 0 Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc Metadata: variant_bitrate : 0 Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 0 [image2 @ 0x27d9800] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. Output #0, image2, to 'dude.png': Metadata: encoder : Lavf57.49.100 Stream #0:0: Video: png, rgb24, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc Metadata: variant_bitrate : 0 encoder : Lavc57.57.100 png Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> png (native)) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.06 bitrate=N/A speed=0.542x video:563kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
In the 3.1 branch. This commit 309fa24f361 (found with bisect) doesn't have the seeking problem, but it has a frame count problem.
From master/HEAD
% ./ffprobe -show_entries stream=nb_read_frames -count_frames -pretty /data/sportlogiq/videos/2708/2708-1.m3u8 ffprobe version N-81699-g590f025 Copyright (c) 2007-2016 the FFmpeg developers built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010 configuration: --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-openssl --enable-static libavutil 55. 29.100 / 55. 29.100 libavcodec 57. 57.100 / 57. 57.100 libavformat 57. 49.100 / 57. 49.100 libavdevice 57. 0.102 / 57. 0.102 libavfilter 6. 62.100 / 6. 62.100 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, hls,applehttp, from '/data/sportlogiq/videos/2708/2708-1.m3u8': Duration: 00:37:20.01, start: 1.400000, bitrate: 0 kb/s Program 0 Metadata: variant_bitrate : 0 Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc Metadata: variant_bitrate : 0 Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 0 [PROGRAM] [STREAM] nb_read_frames=67133 [/STREAM] [STREAM] nb_read_frames=105002 [/STREAM] [/PROGRAM] [STREAM] nb_read_frames=67133 [/STREAM] [STREAM] nb_read_frames=105002 [/STREAM] % git checkout 309fa24f361 % make clean ; make distclean ; ./configure --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-openssl --enable-static && make -j5 % ./ffprobe -show_entries stream=nb_read_frames -count_frames -pretty /data/sportlogiq/videos/2708/2708-1.m3u8 ffprobe version n3.1.1-25-g309fa24 Copyright (c) 2007-2016 the FFmpeg developers built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010 configuration: --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-openssl --enable-static libavutil 55. 28.100 / 55. 28.100 libavcodec 57. 48.101 / 57. 48.101 libavformat 57. 41.100 / 57. 41.100 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 47.100 / 6. 47.100 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc 54. 0.100 / 54. 0.100 [hls,applehttp @ 0x31c2860] No longer receiving playlist 0 [hls,applehttp @ 0x31c2860] Now receiving playlist 0, segment 0 Input #0, hls,applehttp, from '/data/sportlogiq/videos/2708/2708-1.m3u8': Duration: 00:37:20.01, start: 1.400000, bitrate: 0 kb/s Program 0 Metadata: variant_bitrate : 0 Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 132 kb/s [mpegts @ 0x31e5b00] DTS 129840 < 577287 out of order [hls,applehttp @ 0x31c2860] DTS 129840 < 577287 out of order [PROGRAM] [STREAM] nb_read_frames=67283 [/STREAM] [STREAM] nb_read_frames=105239 [/STREAM] [/PROGRAM] [STREAM] nb_read_frames=67283 [/STREAM] [STREAM] nb_read_frames=105239 [/STREAM]
If I convert the video to mp4 (using codec copy), the seeking works(frame image is what is expected) and frame counting gives the expected value (67133).
Finally, the matching commit from 3.1 (309fa24) into master (9884f17) still has the seeking problem although it's the same modification to hls.c, so something else must be interfering in the code.
The seeking video example 'https://s3.amazonaws.com/slffmpegdebug/seekProb/seekProb.m3u8' is publicly available if you want to test (it was cut from a bigger one but reproduces the problem)
I hope all this is clear.
Might be related to #5728
Change History (2)
comment:1 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 8 years ago
Keywords: | hls added; m3u8 removed |
---|
The initial video had an error in the dts pts order. The latest master detects it and croaks as expected.
Marked as closed since input is bad.