Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#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 Louis Letourneau, 7 years ago

Resolution: invalid
Status: newclosed

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.

comment:2 by Carl Eugen Hoyos, 7 years ago

Keywords: hls added; m3u8 removed
Note: See TracTickets for help on using tickets.