HLS EXT-X-DISCONTINUITY tag is not supported

[xyq204101]

Summary of the bug:

I'm trying to read input from HLS and output to RTMP, this works fine if the HLS segments are all in one time sequence. However if the time changes e.g. segments generated from two video files, ffmpeg got error 'Non-monotonous DTS in output stream 0:1;'.

According to the HLS documentation, EXT-X-DISCONTINUITY should be used when time sequence changes. (​https://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-3.4.11) But I still got the same error after I added that tag to the m3u8 file. Look at hls.c file in libavformat, it doesn't handle EXT-X-DISCONTINUITY tag.

How to reproduce:

ffmpeg -re -i http://hls-server/playlist.m3u8 -acodec copy -vcodec copy -bsf:a aac_adtstoasc -f flv rtmp://rtmp-server/app

[Carl Eugen Hoyos]

Is network input required to reproduce this issue or is it also reproducible if you provide the segments as input files?
Is network output required to reproduce the problem or is it also reproducible with file output?

[xyq204101]

Network is not required for both input and output.

It can be reproduced locally using the following ffmpeg commands:

First, generate m3u8 file and segments:

ffmpeg -i test.mp4 -hls_list_size 0 -hls_segment_filename 'test%03d.ts' out.m3u8

The test.mp4 file I've used is (​http://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_50mb.mp4)

Then change the out.m3u8 file to swap the second and third segment and add #EXT-X-DISCONTINUITY tags before those two segments

First few lines of original m3u8

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:8.400000,
test000.ts
#EXTINF:4.560000,
test001.ts
#EXTINF:3.120000,
test002.ts
#EXTINF:5.640000,
test003.ts

Modified:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:8.400000,
test000.ts
#EXT-X-DISCONTINUITY
#EXTINF:3.120000,
test002.ts
#EXT-X-DISCONTINUITY
#EXTINF:4.560000,
test001.ts
#EXTINF:5.640000,
test003.ts

Then use the following ffmpeg command to convert that to flv

ffmpeg -i out.m3u8  -acodec copy -vcodec copy -bsf:a aac_adtstoasc -f flv test.flv

Output:

ffmpeg version 3.0.1-tessus Copyright (c) 2000-2016 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --as=yasm --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzmq --enable-version3 --disable-ffplay --disable-indev=qtkit --disable-indev=x11grab_xcb
  libavutil      55. 17.103 / 55. 17.103
  libavcodec     57. 24.102 / 57. 24.102
  libavformat    57. 25.100 / 57. 25.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 31.100 /  6. 31.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, hls,applehttp, from 'out.m3u8':
  Duration: 00:04:41.80, 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
    Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 5.1, fltp, 314 kb/s
File 'test.flv' already exists. Overwrite ? [y/N] y
Output #0, flv, to 'test.flv':
  Metadata:
    encoder         : Lavf57.25.100
    Stream #0:0: Video: h264 ([7][0][0][0] / 0x0007), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 25 tbr, 1k tbn, 90k tbc
    Stream #0:1: Audio: aac (LC) ([10][0][0][0] / 0x000A), 48000 Hz, 5.1, 314 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8341; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8363; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8384; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8341; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8381; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8405; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8427; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8448; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8421; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8469; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8491; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8512; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8461; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8501; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8533; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8555; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8576; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8541; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8581; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8597; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8619; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8640; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8621; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8661; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8683; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8704; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8661; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8701; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8725; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8747; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8768; changing to 16000. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:0; previous: 15981, current: 8741; changing to 15981. This may result in incorrect timestamps in the output file.
[flv @ 0x7ff473816800] Non-monotonous DTS in output stream 0:1; previous: 16000, current: 8789; changing to 16000. This may result in incorrect timestamps in the output file.

... A lot more similar errors

[Carl Eugen Hoyos]

Do you want to report that trancoding fails (or produces unexpected / wrong output) or do you want to report that transcoding prints warnings?
Please understand that the warning are printed by the muxer, they are not related to the demuxer.

[xyq204101]

Replying to cehoyos:

Do you want to report that trancoding fails (or produces unexpected / wrong output) or do you want to report that transcoding prints warnings?

The transcoding is producing unexpected output. When I play the output flv file in VLC, it freeze at 8th second and after few seconds jump to 12th second directly. The content between 8th and 12th second is missing.

Please understand that the warning are printed by the muxer, they are not related to the demuxer.

From my understanding when the muxer saw timestamp difference it will skip those frames, however in this case the demuxer should somehow let the muxer know the timestamp difference is expected.

[Carl Eugen Hoyos]

Replying to xyq204101:

Replying to cehoyos:

Do you want to report that trancoding fails (or produces unexpected / wrong output) or do you want to report that transcoding prints warnings?

The transcoding is producing unexpected output. When I play the output flv file in VLC, it freeze at 8th second and after few seconds jump to 12th second directly. The content between 8th and 12th second is missing.

What output did you expect after swapping the segments?

[xyq204101]

Replying to cehoyos:

Replying to xyq204101:

Replying to cehoyos:

Do you want to report that trancoding fails (or produces unexpected / wrong output) or do you want to report that transcoding prints warnings?

The transcoding is producing unexpected output. When I play the output flv file in VLC, it freeze at 8th second and after few seconds jump to 12th second directly. The content between 8th and 12th second is missing.

What output did you expect after swapping the segments?

The expect output is first contents in test000.ts, then test002.ts, then test001.ts then test003.ts.... according to the sequence of the m3u8 file.

[an_ffmpeg_user]

Replying to xyq204101:

Replying to cehoyos:

Replying to xyq204101:

Replying to cehoyos:

Do you want to report that trancoding fails (or produces unexpected / wrong output) or do you want to report that transcoding prints warnings?

The transcoding is producing unexpected output. When I play the output flv file in VLC, it freeze at 8th second and after few seconds jump to 12th second directly. The content between 8th and 12th second is missing.

What output did you expect after swapping the segments?

The expect output is first contents in test000.ts, then test002.ts, then test001.ts then test003.ts.... according to the sequence of the m3u8 file.

What output did you expect after swapping the segments?

I concur with @xyq204101.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:8.400000,
test000.ts
#EXTINF:4.560000,
test001.ts
#EXTINF:3.120000,
test002.ts
#EXTINF:5.640000,
test003.ts

I would expect this to play test000 > test001 > test002 > test003.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:8.400000,
test000.ts
#EXTINF:3.120000,
test002.ts
#EXTINF:4.560000,
test001.ts
#EXTINF:5.640000,
test003.ts

I can't say how a player should behave in this case. It will be unpredictable. We have seen players that either power-on-through, stall or skip. This stream would not pass the Apple HLS Validator and playback support across software or devices could not be guaranteed.

I would expect FFmpeg's demuxer to scream, moan and complain at the console.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:8.400000,
test000.ts
#EXT-X-DISCONTINUITY
#EXTINF:3.120000,
test002.ts
#EXT-X-DISCONTINUITY
#EXTINF:4.560000,
test001.ts
#EXTINF:5.640000,
test003.ts

I would expect a HLSv2 or above player/encoder with EXT-X-DISCONTINUITY support to play or generate a seamless test000 > test002 > test001 > test003 output without console errors or warnings.

The demuxer may choose to verbose log that a discontinuity flag was detected, but it should not justify a console warning or error if the EXT-X-DISCONTINUITY flag is correctly placed. But TBH, the console output is irrelevant - it is the stream that is important.

@xyq204101 - how does FFplay behave when it tries to play your out.m3u8? It will help take the output modules and VLC out of the equation, helping the developers tag with the correct component.

Also, it may be better to take the bitstream filter and FLV container out of the loop and encapsulate in a single MPEG-TS.

ffmpeg -i out.m3u8 -acodec copy -vcodec copy -f mpegts test.ts

[Holden]

Hi,

I have the same problem. EXT-X-DISCONTINUITY tags are currently not supported by the current version of FFMPEG. VLC does not support this as well. Someone a long time ago did create a patch to try and make this work in 2013:

​https://github.com/bbcallen/FFmpeg/commit/7d154d23c7a6b41da58bc40d3848f46d2eef8496

I have tried to modify this to work on the latest version of FFMPEG by just setting the PTS and DTS to no value and it works sometimes however it is not the correct way and can cause some epic audio sync issues down the line. We need to make sure the timebase from demuxer to muxer is consistent and this patch attempts to do that while my patch fails.

If I find a way to make this work I will submit it here as I have spent alot of time trying to solve this issue and I think when FFMPEG supports EXT-X-DISCONTINUITIES it will be alot better piece of software for my use cases.

[Holden]

There have been many attempts to make this work from various people. Check out AirStachPlayer hls.c file: ​https://github.com/AirStash/AirStashPlayer/blob/d0013059c63cf0807196c1dd396aa4ba2bbc1663/android/contrib/ffmpeg-x86_64/libavformat/hls.c

I have not made their implementation work as of yet. You can hack around the problem by modifying the hls_read_packet function and change the end of the function to:

/* If we got a packet, return it */

if (minplaylist >= 0) {

struct playlist *pls = c->playlists[minplaylist];
*pkt = pls->pkt;
pkt->stream_index += pls->stream_offset;
reset_packet(&c->playlists[minplaylist]->pkt);

if (pkt->dts != AV_NOPTS_VALUE)

c->cur_timestamp = av_rescale_q(pkt->dts,

pls->ctx->streams[pls->pkt.stream_index]->time_base,
AV_TIME_BASE_Q);

pkt->dts = AV_NOPTS_VALUE;
pkt->pts = AV_NOPTS_VALUE;

return 0;

}
return AVERROR_EOF;

Just add the 2 lines:

pkt->dts = AV_NOPTS_VALUE;
pkt->pts = AV_NOPTS_VALUE;

This seems to make FFMPEG handle #EXT-X-DISCONTINUITY

Obviously you will need to compile your own build to make this work.

[Holden]

There is a fix available for this. Please email me at ​holdenforever@gmail.com if you are interested.

[Carl Eugen Hoyos]

Replying to HoldenForever:

There is a fix available for this. Please email me at ​holdenforever@gmail.com if you are interested.

Please send your patch to the development mailing list.

[Anssi Hannula]

This report is valid as indeed the HLS demuxer doesn't currently support EXT-X-DISCONTINUITY tag.

Changing the order of the segments in the playlist and marking them with EXT-X-DISCONTINUITY should indeed result in playback in the new order with consistent timestamps as has been suggested.

To properly support the timestamp discontinuity case we'd need to map the timebase of each discontinuity sequence to a single consistent timebase, and that mapping would need to be considered when selecting the next frame to be output and when seeking.

EXT-X-DISCONTINUITY also allows the file format, the number of tracks, and other stream properties to change, those would require some additional handling (e.g. open a different subdemuxer) but such cases may be more rare.

[Bryan Dunbar]

Did this ever get fixed? Or could somebody send the patch?

[Bryan Dunbar]

Did this ever get fixed? Or could somebody send the patch?

[damengzai]

Replying to HoldenForever:

There have been many attempts to make this work from various people. Check out AirStachPlayer hls.c file: ​https://github.com/AirStash/AirStashPlayer/blob/d0013059c63cf0807196c1dd396aa4ba2bbc1663/android/contrib/ffmpeg-x86_64/libavformat/hls.c

I have not made their implementation work as of yet. You can hack around the problem by modifying the hls_read_packet function and change the end of the function to:

/* If we got a packet, return it */

if (minplaylist >= 0) {

struct playlist *pls = c->playlists[minplaylist];
*pkt = pls->pkt;
pkt->stream_index += pls->stream_offset;
reset_packet(&c->playlists[minplaylist]->pkt);

if (pkt->dts != AV_NOPTS_VALUE)

c->cur_timestamp = av_rescale_q(pkt->dts,

pls->ctx->streams[pls->pkt.stream_index]->time_base,
AV_TIME_BASE_Q);

pkt->dts = AV_NOPTS_VALUE;
pkt->pts = AV_NOPTS_VALUE;

return 0;

}
return AVERROR_EOF;

Just add the 2 lines:

pkt->dts = AV_NOPTS_VALUE;
pkt->pts = AV_NOPTS_VALUE;

This seems to make FFMPEG handle #EXT-X-DISCONTINUITY

Obviously you will need to compile your own build to make this work.

This is useful but not work,I changed some code and it work.
Like this:

ret = av_read_frame(pls->ctx, &pls->pkt);

int seq_no = pls->cur_seq_no - pls->start_seq_no;
struct segment *seg = pls->segments[seq_no];
int64_t pred = av_rescale_q(seg->previous_duration,

AV_TIME_BASE_Q,
s->streams[pkt->stream_index]->time_base);

int64_t max_ts = av_rescale_q(seg->start_time + seg->duration,

AV_TIME_BASE_Q,
s->streams[pkt->stream_index]->time_base);

max_ts += 2 * AV_TIME_BASE;
if(s->start_time > 0){

max_ts+= av_rescale_q(s->start_time,

AV_TIME_BASE_Q,
s->streams[pkt->stream_index]->time_base);

}
if(pls->pkt.dts != AV_NOPTS_VALUE && pls->pkt.dts + pred < max_ts)
pls->pkt.dts += pred;
if(pls->pkt.pts != AV_NOPTS_VALUE && pls->pkt.pts + pred < max_ts)
pls->pkt.pts += pred;

Just change the position of the code above.Others didn`t change.
Because if tag EXT-X-DISCONTINUITY appear ,means dts and pts changed,and if dts less than seek_timestamp,it will stuck here( ts_diff = av_rescale_rnd(pls->pkt.dts, AV_TIME_BASE,

tb.den, AV_ROUND_DOWN) -

pls->seek_timestamp;

if (ts_diff >= 0 && (pls->seek_flags & AVSEEK_FLAG_ANY

pls->pkt.flags & AV_PKT_FLAG_KEY)) {

pls->seek_timestamp = AV_NOPTS_VALUE;
break;

})

hope helpful,if something wrong tell me please.

[Carl Eugen Hoyos]

A real-world stream that allows to reproduce this was posted on the youtube-dl bug tracker.
The following works as expected, playback continues after the discontinuity that can be seen in the status line after ten seconds:

$ ffplay -ss 120 http://ipad-streaming.cbsnews.com/media/mpx/2016/12/11/830443587743/60_1211_FullEpisode_1199010_5000/60_1211_FullEpisode_1199010_5000.m3u8

The following produces only ten seconds output, I stopped transcoding after no frames were written for several seconds, output continues after some time but shows horrible A/V desync:

$ ffmpeg -ss 120 -i http://ipad-streaming.cbsnews.com/media/mpx/2016/12/11/830443587743/60_1211_FullEpisode_1199010_5000/60_1211_FullEpisode_1199010_5000.m3u8 -qscale 2 out.avi
ffmpeg version N-83412-g8b80feb Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      55. 46.100 / 55. 46.100
  libavcodec     57. 75.100 / 57. 75.100
  libavformat    57. 66.101 / 57. 66.101
  libavdevice    57.  2.100 / 57.  2.100
  libavfilter     6. 72.100 /  6. 72.100
  libswscale      4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
  libpostproc    54.  2.100 / 54.  2.100
Input #0, hls,applehttp, from 'http://ipad-streaming.cbsnews.com/media/mpx/2016/12/11/830443587743/60_1211_FullEpisode_1199010_5000/60_1211_FullEpisode_1199010_5000.m3u8':
  Duration: 00:43:55.58, start: 1.400000, bitrate: 0 kb/s
  Program 0
    Metadata:
      variant_bitrate : 0
    Stream #0:0: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [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), 44100 Hz, stereo, fltp
    Metadata:
      variant_bitrate : 0
Please use -q:a or -q:v, -qscale is ambiguous
Output #0, avi, to 'out.avi':
  Metadata:
    ISFT            : Lavf57.66.101
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1920x1080 [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.75.100 mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 44100 Hz, stereo, fltp, 192 kb/s
    Metadata:
      variant_bitrate : 0
      encoder         : Lavc57.75.100 ac3
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg4 (native))
  Stream #0:1 -> #0:1 (aac (native) -> ac3 (native))
Press [q] to stop, [?] for help
frame=  328 fps= 16 q=2.0 Lsize=    7911kB time=00:00:11.14 bitrate=5815.0kbits/s speed=0.538x
video:7629kB audio:256kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.318705%

The issue also manifests itself for the following command line, that produces output starting 140 seconds after the discontinuity:

$ ffmpeg -ss 140 -i http://ipad-streaming.cbsnews.com/media/mpx/2016/12/11/830443587743/60_1211_FullEpisode_1199010_5000/60_1211_FullEpisode_1199010_5000.m3u8 -qscale 2 out.avi

[Sylvain228]

Here is a 24x7 linear test stream with frequent discontinuities.
No solution found to manage discontinuities until now
​https://www.djing.com/tv/live.m3u8

[Jorge Moraleda]

What is the current state of this bug? Are there plans to add support for the EXT-X-DISCONTINUITY tag? I am trying to produce a summary version of a playlist by removing some segments from a continuous playlist and adding EXT-X-DISCONTINUITY tags in the place of the removed segments, but the player does not realize the jump in pts and just sits showing the last frame for the duration of the removed segments. In case it matters, I do take care that every segment after EXT-X-DISCONTINUITY start with an i-frame. Thank you.

[Richard]

Any plans on fixing this bug? I'm encountering it too with a self-written playlist as input that switches between two sources with EXT-X-DISCONTINUITY depending on availability.

[Joe Koberg]

I have a patch fixing this bug at ​http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html

Please let me know if it's suitable for merge.

Thanks!

[Thomas Wilson]

What is the current status of this bug?

Is there a hacky way around it in ffmpeg version 4.2.2 ?

[Balling]

Replying to jkoberg:

I have a patch fixing this bug at ​http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html

Please let me know if it's suitable for merge.

Thanks!

Please resubmit this ​http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180316/739542e4/attachment.obj so it will be shown on ​https://patchwork.ffmpeg.org

[bhertz]

Replying to jkoberg:

I have a patch fixing this bug at ​http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html

Thanks for the patch from a user. Had the same problem with an internet stream, which issued a series of EXT-X-DISCONTINUITY tags from time to time thus making ffmpeg croak ("Non-monotonous DTS in output stream" aplenty, finally it stopped producing output). Your patch fixes that, partly.

Partly because vlc, with which I relay the stream on LAN, still occasionally complains about timestamps upon remuxing. But now it at least recovers autonomously, and no restart is required. Which I previously had to do every two hours or so.

So the patch is of real benefit here, and I specifically registered on this site to convey my appreciation.

[hls_downloader]

When will the patch be finally merged? Stop ignoring the issue please!

[luckysk]

It seems to be on the 2021 petition list, I guess，
btw，can we at least try to merge some of the above mentioned improved patches?

[emkowale]

Could someone please provide instructions on exactly how to apply the patch? It sure would be great if this was included in the packaged version of ffmpeg.

[mrskman]

I sign this petition +1

[Balling]

We need to first apply this LGTM patch ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220128202320.1711694-1-gustav.grusell@gmail.com/

to even start talking about this issue.

[Sergey]

Dear Balling,

LGTM patch was applied, please help solve this problem!

thank you

[cdickey]

I recently stumbled into this issue while building a service to stream to youtube. The command used in the original post is even very very close to what I'm using. However anytime the service attempts to stream using an m3u8 with an EXT-X-DISCONTINUITY tag in, ffmpeg continues on as though nothing is wrong but the Youtube stream health log shows it stops receiving data from that point. I would also like to voice support for getting that patch merged in.

[adamvaul]

I also am working on this issue and would be very grateful for any help in getting ffmpeg to recognize and properly output from .m3u8 with EXT-X-DISCONTINUITY tags into rtmp.

We are currently using this command to output to stream:

ffmpeg -re -protocol_whitelist file,http,https,tcp,tls,crypto -live_start_index -99999 -i out.m3u8 -acodec copy -vcodec copy -f flv "rtmp://..."

[Elliot Lee]

There are some relevant comments in ​https://github.com/jellyfin/jellyfin-ffmpeg/issues/57

In particular:
(a) "One of the major issues is that RFC-8216 is not fully supported in FFMPEG

​https://datatracker.ietf.org/doc/html/rfc8216

#EXT-X-DISCONTINUITY is just one of the things from RFC-8216 that isn't supported properly in FFMPEG.
#EXT-X-DISCONTINUITY-SEQUENCE is also not supported properly either.

Just look through the RFC and you still see things missing from FFMPEG." (github user Protektor-Desura)

(b) "Now, when it comes to supporting certain TV providers like Pluto, simply supporting discontinuity streams is not enough. This is because streams from providers like Pluto often break the HLS RFC spec in various ways, and a spec-compliant HLS demuxer would reject these streams as well.

To illustrate, proper support for the #EXT-X-DISCONTINUITY tag requires the HLS stream to have an EXT-X-DISCONTINUITY-SEQUENCE header to mark which discontinuity sequence the current playlist is in. However, PlutoTV manifests may have inconsistent numbers between updates, with values jumping from 2 to 0 or 1. According to the RFC, a decreasing number is not allowed." (github user gnattu)

So it seems there is more to untangling this whole ball of yarn than just applying the old patch.