HLS does not demux entire clip if start_time > 0

[ronag]

Summary of the bug:

The hls demuxer doesn't seem to play the entire file. From what i can see it seems to play "duration - start_time" time of the file. I've reproduced this on multiple different files.

If I simply play the .ts file everything works fine. However, if I play the m3u8 file I seem to be missing "start_time" time in the end, i.e. the file is ~5.4s but it stops at ~4s.

It seems to me that the demuxer seems to do "frame->pts += start_time" and then stop outputting packets once "frame->ts + start_time >= duration". However, "frame->pts" already includes start_time so somehow start_time gets added into "frame->pts" twice.

How to reproduce:

cd ffmpeg
npm i -g http-server
http-server .
ffplay -i http://localhost:8080/file/M6nmzk2FDeesWy.m3u8

C:\Users\Boffins\Desktop\CasparCG 2.2.0>ffplay.exe -i http://localhost:8080/file/M6nmzk2FDeesWy.m3u8
ffplay version N-90061-gfb580731c1 Copyright (c) 2003-2018 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libmfx --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
  libavutil      56.  7.101 / 56.  7.101
  libavcodec     58. 11.101 / 58. 11.101
  libavformat    58.  9.100 / 58.  9.100
  libavdevice    58.  1.100 / 58.  1.100
  libavfilter     7. 12.100 /  7. 12.100
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
[hls,applehttp @ 000002343b33dd80] Opening 'http://localhost:8080/file/M6nmzk2FDeesWy.ts' for reading
[hls,applehttp @ 000002343b33dd80] Opening 'http://localhost:8080/file/M6nmzk2FDeesWy.ts' for reading
Input #0, hls,applehttp, from 'http://localhost:8080/file/M6nmzk2FDeesWy.m3u8':
  Duration: 00:00:05.40, start: 1.458667, 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], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Metadata:
      variant_bitrate : 0
    Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp
    Metadata:
      variant_bitrate : 0
   5.39 A-V: -5.723 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

[ronag]

Duplicate ​https://trac.ffmpeg.org/ticket/7035

[Carl Eugen Hoyos]

Is this issue only reproducible with ffplay or also with ffmpeg?
Do you believe this is a regression?

[ronag]

I haven't tried with ffmpeg but we have the same problem in CasparCG (which uses ffmpeg). Yes, I believe it is a regression since we have been using an older version of ffplay without problem.

[Carl Eugen Hoyos]

Which commit introduced the regression?

[ronag]

Sorry, the attachment for the test files ended up in the closed duplicate. Adding them to this ticket as well.

[ronag]

So far I can say that 274bd1670b9c85e24f37d08f9043dd82e0a28c67 works.

[ronag]

.

[ronag]

31b351ea81d0a7c0d0ed1982dcc6327b7f43b987 (Dec 4)

Is also fine.

[ronag]

.

[ronag]

I don't know. There are too many commits relative to the time it takes to compile. I've been at this for 2 hours. I think someone familiar with the code and debugger is going to be more successful here...

[Carl Eugen Hoyos]

This shouldn’t take more than 30 minutes: What did you try?

[ronag]

Checkout an older version,

git checkout xxx && ./configure && make && ffplay -i http://localhost:8080/file/M6nmzk2FDeesWy.m3u8

and then work towards earlier dates by guessing and so on

[Carl Eugen Hoyos]

Use git bisect instead: After every test that does not allow to reproduce the issue type git bisect good, after every test that fails git bisect bad. Start with one working and one non-working version, no need to use git checkout after the first two tests.

[ronag]

.

[ronag]

Ok, this seems to be the first broken commit b7d6c0cd48dac7869b9e6803e2d47d05a4fa373b

[Carl Eugen Hoyos]

Can you confirm that your issue is not reproducible with -http_persistent 0?

[ronag]

Seems setting http_persistent and http_multiple to false seems to resolve the issue. Maybe these options should be considered experimental and set to false by default?

ffplay -http_persistent 0 -http_multiple 0 -i http://localhost:8080/file/M6nmzk2FDeesWy.m3u8

[ronag]

.

[ronag]

Is there anything more I can do here to help resolve this issue?

[Balling]

It appears to work now...