Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#1842 closed defect (fixed)

Incorrect segmented HTTP Live Streaming playlists

Reported by: teric Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: segment, hls, m3u8
Cc: blacktrash@gmx.net Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
How to reproduce:

% ffmpeg -i -threads 2 -i rtmp://10.10.80.80/live/shandong_HD live=1 -re -copyts -acodec libfaac -vcodec libx264 -vprofile baseline -bsf h264_mp4toannexb -v error -map 0 -b:v 500k -b:a 64k -f ssegment -segment_list livelist.m3u8 -segment_list_flags +live -segment_list_size 3 -segment_time 10 d%05d.ts

ffmpeg 1.0

Firstly, iPad or VLC expect the adjacent lists(m3u8) includes overlaped items, OR VLC will stop always and iPad will stop/jitter occasionally.

eg.
list 1

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1240780828
#EXT-X-TARGETDURATION:10
#EXTINF:12,
d1240781828.ts
#EXTINF:10,
d1240781829.ts
#EXTINF:10,
d1240781830.ts

list 2

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1240780829
#EXT-X-TARGETDURATION:10
#EXTINF:10,
d1240781829.ts
#EXTINF:10,
d1240781830.ts
#EXTINF:10,
d1240781831.ts

Secondly, when the stream is restarted, ffmpeg(segment) should create
segments with different filenames, OR these files will stay stale in CDN
cache
eg.stale segments because file name begin at 000
first times

000.ts
001.ts
002.ts
...

after restart

000.ts
001.ts
002.ts
...
000.ts
001.ts
002.ts

so we can use timestamp as the init segment index.
You can refer to my patch for detail.

Attachments (1)

segment.patch (7.9 KB) - added by teric 4 years ago.
a patch for libavformat/segment.c

Download all attachments as: .zip

Change History (21)

Changed 4 years ago by teric

a patch for libavformat/segment.c

comment:1 Changed 4 years ago by teric

  • Summary changed from create to create better HTTP Live Streaming with segment

comment:2 Changed 4 years ago by richardpl

  • Component changed from FFmpeg to undetermined
  • Priority changed from important to wish
  • Reproduced by developer unset
  • Status changed from new to open

Bug reports are not place to send patches, use mailing list for that. This bug report is likely to be ignored.

comment:3 in reply to: ↑ description Changed 4 years ago by saste

Replying to teric:

Summary of the bug:
How to reproduce:

% ffmpeg -i -threads 2 -i rtmp://10.10.80.80/live/shandong_HD live=1 -re -copyts -acodec libfaac -vcodec libx264 -vprofile baseline -bsf h264_mp4toannexb -v error -map 0 -b:v 500k -b:a 64k -f ssegment -segment_list livelist.m3u8 -segment_list_flags +live -segment_list_size 3 -segment_time 10 d%05d.ts

ffmpeg 1.0

Firstly, iPad or VLC expect the adjacent lists(m3u8) includes overlaped items, OR VLC will stop always and iPad will stop/jitter occasionally.

Can you elaborate on this? I based the segmenter work on the only M3U8 spec available, but I'm aware that special devices may have special requirements (which may or may not be documented). Do you have such documents/links, or your claim is based on your experience (which is fine, just I need to know if I need to rely on some reference spec)?
[...]

Secondly, when the stream is restarted, ffmpeg(segment) should create
segments with different filenames, OR these files will stay stale in CDN
cache

[...]

so we can use timestamp as the init segment index.

Sure this is an idea.

You can refer to my patch for detail.

I'll have a look at the patch, but posting it on the ML should allow a much easier review and should get more attention, so I'd recommend you to post the patch on ffmpeg-devel.

comment:4 follow-ups: Changed 4 years ago by brownard

The problem is that the segmenter doesn't correctly increment the #EXT-X-MEDIA-SEQUENCE tag as per the spec and I don't think the -segment-list-size works as the spec envisages.
The current behaviour is to completely empty the playlist when it reaches the specified size and increment the #EXT-X-MEDIA-SEQUENCE tag by 1
e.g

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXTINF:10,
000.ts
#EXTINF:10,
001.ts
#EXTINF:10,
002.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
003.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
003.ts
#EXTINF:10,
004.ts

but the #EXT-X-MEDIA-SEQUENCE tag should be equal to the index of the first segment in the list, so in the example above the value in the second and third playlist should be 3 not 1 because the first segment in the list is the fourth overall.

What should happen is rather than emptying the playlist, the first item in the list should be removed and the new item appended so you have a "sliding window" with the #EXT-X-MEDIA-SEQUENCE increasing by 1 each time
e.g

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXTINF:10,
000.ts
#EXTINF:10,
001.ts
#EXTINF:10,
002.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
001.ts
#EXTINF:10,
002.ts
#EXTINF:10,
003.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-TARGETDURATION:10
#EXTINF:10,
002.ts
#EXTINF:10,
003.ts
#EXTINF:10,
004.ts

comment:5 in reply to: ↑ 4 Changed 4 years ago by upeters

Replying to brownard:

The problem is that the segmenter doesn't correctly increment the #EXT-X-MEDIA-SEQUENCE tag as per the spec and I don't think the -segment-list-size works as the spec envisages.

You are right. I can verify that this is exactly the same problem here.
The sliding window function is missing. Most players will stop after the first few segments.

Who could fix that problem?

Last edited 4 years ago by upeters (previous) (diff)

comment:6 Changed 4 years ago by upeters

  • Priority changed from wish to normal
  • Summary changed from create better HTTP Live Streaming with segment to Incorrect segmented HTTP Live Streaming playlists
  • Type changed from enhancement to defect

comment:7 in reply to: ↑ 4 ; follow-up: Changed 4 years ago by teric

@upeters, @brownard

#EXT-X-MEDIA-SEQUENCE should EQUAL or LESS THAN the first item index in current list.
my original patch can create a sliding window.

Replying to brownard:

The problem is that the segmenter doesn't correctly increment the #EXT-X-MEDIA-SEQUENCE tag as per the spec and I don't think the -segment-list-size works as the spec envisages.
The current behaviour is to completely empty the playlist when it reaches the specified size and increment the #EXT-X-MEDIA-SEQUENCE tag by 1
e.g

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXTINF:10,
000.ts
#EXTINF:10,
001.ts
#EXTINF:10,
002.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
003.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
003.ts
#EXTINF:10,
004.ts

but the #EXT-X-MEDIA-SEQUENCE tag should be equal to the index of the first segment in the list, so in the example above the value in the second and third playlist should be 3 not 1 because the first segment in the list is the fourth overall.

What should happen is rather than emptying the playlist, the first item in the list should be removed and the new item appended so you have a "sliding window" with the #EXT-X-MEDIA-SEQUENCE increasing by 1 each time
e.g

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXTINF:10,
000.ts
#EXTINF:10,
001.ts
#EXTINF:10,
002.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
001.ts
#EXTINF:10,
002.ts
#EXTINF:10,
003.ts

.....

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-TARGETDURATION:10
#EXTINF:10,
002.ts
#EXTINF:10,
003.ts
#EXTINF:10,
004.ts

comment:8 in reply to: ↑ 7 ; follow-up: Changed 4 years ago by brownard

The #EXT-X-MEDIA-SEQUENCE should not be less than the index of the first segment.
From http://tools.ietf.org/html/draft-pantos-http-live-streaming-10#page-8

"The EXT-X-MEDIA-SEQUENCE tag indicates the sequence number of the first segment that
appears in a Playlist file."

Replying to teric:

@upeters, @brownard

#EXT-X-MEDIA-SEQUENCE should EQUAL or LESS THAN the first item index in current list.
my original patch can create a sliding window.

comment:9 in reply to: ↑ 8 Changed 4 years ago by saste

Replying to brownard:

The #EXT-X-MEDIA-SEQUENCE should not be less than the index of the first segment.
From http://tools.ietf.org/html/draft-pantos-http-live-streaming-10#page-8

"The EXT-X-MEDIA-SEQUENCE tag indicates the sequence number of the first segment that
appears in a Playlist file."

This should be fixed in:

commit 8b6aeb1fcdd975422e251ebfc3da8565d7f6c604
Author: Stefano Sabatini <stefasab@gmail.com>
Date:   Sat Nov 17 17:21:43 2012 +0100

    lavf/segment: fix value for the M3U8 EXT-X-MEDIA
    
    From the M3U8 specification:
    |The EXT-X-MEDIA-SEQUENCE tag indicates the sequence number of the first
    |URI that appears in a Playlist file.
    
    Previously it was using the list index number. Also remove now unused
    list_count field.

comment:10 in reply to: ↑ 4 ; follow-up: Changed 4 years ago by saste

Replying to brownard:

The problem is that the segmenter doesn't correctly increment the #EXT-X-MEDIA-SEQUENCE tag as per the spec and I don't think the -segment-list-size works as the spec envisages.
The current behaviour is to completely empty the playlist when it reaches the specified size and increment the #EXT-X-MEDIA-SEQUENCE tag by 1

[...]

but the #EXT-X-MEDIA-SEQUENCE tag should be equal to the index of the first segment in the list, so in the example above the value in the second and third playlist should be 3 not 1 because the first segment in the list is the fourth overall.

This one should be fixed.

What should happen is rather than emptying the playlist, the first item in the list should be removed and the new item appended so you have a "sliding window" with the #EXT-X-MEDIA-SEQUENCE increasing by 1 each time

Current behavior is advertised in the docs as:

 segment_list_size size
           Overwrite the listfile once it reaches size entries. If 0 the listfile is never overwritten. Default value is 0.

Now I see that having a sliding window seems more useful. Two questions: should the old behavior be retained according to you? How can the new behavior be enabled, if it has to convive with the old one? Also, in order to simplify discussion, I invite you to join ffmpeg-devel (but it is completely up to you).

Another thing that you may want to check is the new hls muxer (but even if that works for you I'd like to fix the segmenter, which is a more generic beast).

comment:11 in reply to: ↑ 10 Changed 4 years ago by upeters

Replying to saste:

Two questions: should the old behavior be retained according to you? How can the new behavior be enabled, if it has to convive with the old one?

No, no need to keep it. The old (current) behavior seems to be useless. It should be completely replaced by a sliding window behavior.
The window size should be defined by -segment_list_size (default 5?).

Two other things: It would be a nice feature if the m3u8 output could be redirected to STDOUT by using "-" as filename (like other ffmpeg input/output) for further processing (ftp upload etc.). And also a delete option would be usefull where ffmpeg deletes the last file fallen out of the sliding window.

Version 0, edited 4 years ago by upeters (next)

comment:12 Changed 4 years ago by brownard

I agree with @upeters, I see no use for the current behaviour and it should be replaced. If it has to be kept you could add a "+windowed" flag to segment_list_flags which could then be used in conjunction with segment_list_size to specify the window size.

comment:13 follow-up: Changed 4 years ago by jeremycondon

Where does this issue stand? I see that the patch has been applied, but it is still not producing the expected m3u8 for me. When I have it set to 8 segments (segment_list_size 8), I get:

# m3u8 for segment 00006
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOWCACHE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10.007800,
d00000.ts
#EXTINF:10.007800,
d00001.ts
#EXTINF:9.984589,
d00002.ts
#EXTINF:10.007811,
d00003.ts
#EXTINF:10.007811,
d00004.ts
#EXTINF:9.984589,
d00005.ts
#EXTINF:10.007800,
d00006.ts

and for segment 8 I get

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:7
#EXT-X-ALLOWCACHE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10.007800,
d00007.ts
#EXTINF:9.984578,
d00008.ts

I would expect segment 8 to look like:

#EXTINF:9.984589,
d00002.ts
#EXTINF:10.007811,
d00003.ts
#EXTINF:10.007811,
d00004.ts
#EXTINF:9.984589,
d00005.ts
#EXTINF:10.007800,
d00006.ts
#EXTINF:10.007800,
d00007.ts
#EXTINF:9.984578,
d00008.ts

comment:14 in reply to: ↑ 13 Changed 4 years ago by saste

Replying to jeremycondon:

Where does this issue stand? I see that the patch has been applied, but it is still not producing the expected m3u8 for me.

No patch related to this has been applied yet. You can try this branch:
http://gitorious.org/~saste/ffmpeg/sastes-ffmpeg/commits/extend-segment-20130113

and report, I plan to apply the relevant patches soon.

comment:15 Changed 4 years ago by saste

  • Analyzed by developer set
  • Component changed from undetermined to avformat
  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from open to closed
  • Type changed from defect to enhancement

Should be fixed in:

commit d4890c10680edaeccd7a186467b59930ef922d26
Author: Stefano Sabatini <stefasab@gmail.com>
Date:   Thu Dec 20 14:20:19 2012 +0100

    lavf/segment: add support to segment list file entries sliding window listing
    
    In particular, should fix trac ticket #1842.

comment:16 Changed 4 years ago by cehoyos

  • Version changed from 1.0 to git-master

comment:17 follow-up: Changed 4 years ago by blacktrash

  • Analyzed by developer unset
  • Cc blacktrash@gmx.net added
  • Reproduced by developer unset
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from enhancement to defect

I just made the experience that having EXT-X-TARGETDURATION at EOF instead of the beginning crashes on old iOS versions - 3.1 in my test case. Moving it to the top fixed the problem.

comment:18 in reply to: ↑ 17 ; follow-ups: Changed 4 years ago by saste

Replying to blacktrash:

I just made the experience that having EXT-X-TARGETDURATION at EOF instead of the beginning crashes on old iOS versions - 3.1 in my test case. Moving it to the top fixed the problem.

This is what I get:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-ALLOWCACHE:1
#EXT-X-TARGETDURATION:16
#EXTINF:3.361789,
outseg-002.ts
#EXTINF:3.342667,
outseg-003.ts
#EXTINF:15.248567,
outseg-004.ts
#EXT-X-ENDLIST

I don't know what you mean by "EXT-X-TARGETDURATION at EOF".

comment:19 in reply to: ↑ 18 Changed 4 years ago by saste

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to saste:

Replying to blacktrash:

I just made the experience that having EXT-X-TARGETDURATION at EOF instead of the beginning crashes on old iOS versions - 3.1 in my test case. Moving it to the top fixed the problem.

This is what I get:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-ALLOWCACHE:1
#EXT-X-TARGETDURATION:16
#EXTINF:3.361789,
outseg-002.ts
#EXTINF:3.342667,
outseg-003.ts
#EXTINF:15.248567,
outseg-004.ts
#EXT-X-ENDLIST

I don't know what you mean by "EXT-X-TARGETDURATION at EOF".

Please reopen (or open a new ticket) if you can provide the missing information.

comment:20 in reply to: ↑ 18 Changed 3 years ago by blacktrash

Replying to saste:

Replying to blacktrash:

I just made the experience that having EXT-X-TARGETDURATION at EOF instead of the beginning crashes on old iOS versions - 3.1 in my test case. Moving it to the top fixed the problem.

This is what I get:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-ALLOWCACHE:1
#EXT-X-TARGETDURATION:16
#EXTINF:3.361789,
outseg-002.ts
#EXTINF:3.342667,
outseg-003.ts
#EXTINF:15.248567,
outseg-004.ts
#EXT-X-ENDLIST

I don't know what you mean by "EXT-X-TARGETDURATION at EOF".

At end of file:

#EXTINF:9.000000,
test-027.ts
#EXTINF:2.258667,
test-028.ts
#EXT-X-TARGETDURATION:10
#EXT-X-ENDLIST

Like at the beginning of this bug report.

ffmpeg version N-48505-g8214c1d
built on Jan  6 2013 14:01:46 with gcc 4.0.1 (GCC) (Apple Inc. build 5493)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-network --disable-ffserver --enable-shared --enable-postproc --enable-libx264 --enable-libxvid --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx --enable-librtmp --extra-cflags=-I/sw/include --extra-libs=-L/sw/lib
libavutil      52. 13.100 / 52. 13.100
libavcodec     54. 85.101 / 54. 85.101
libavformat    54. 59.105 / 54. 59.105
libavdevice    54.  3.102 / 54.  3.102
libavfilter     3. 32.100 /  3. 32.100
libswscale      2.  1.103 /  2.  1.103
libswresample   0. 17.102 /  0. 17.102
libpostproc    52.  2.100 / 52.  2.100

Perhaps this has changed since 6th of Jan. I still have a batch of transcoding to do, and don't want to change version before I'm finished. Will try again later.

Note: See TracTickets for help on using tickets.