#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)
Change History (21)
by , 12 years ago
| Attachment: | segment.patch added |
|---|
comment:1 by , 12 years ago
| Summary: | create → create better HTTP Live Streaming with segment |
|---|
comment:2 by , 12 years ago
| Component: | FFmpeg → undetermined |
|---|---|
| Priority: | important → wish |
| Reproduced by developer: | unset |
| Status: | new → open |
Bug reports are not place to send patches, use mailing list for that. This bug report is likely to be ignored.
comment:3 by , 12 years ago
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.
follow-ups: 5 7 10 comment:4 by , 12 years ago
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 by , 12 years ago
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?
comment:6 by , 12 years ago
| Priority: | wish → normal |
|---|---|
| Summary: | create better HTTP Live Streaming with segment → Incorrect segmented HTTP Live Streaming playlists |
| Type: | enhancement → defect |
follow-up: 8 comment:7 by , 12 years ago
@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.tsbut 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
follow-up: 9 comment:8 by , 12 years ago
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 by , 12 years ago
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.
follow-up: 11 comment:10 by , 12 years ago
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 by , 12 years ago
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.
comment:12 by , 12 years ago
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.
follow-up: 14 comment:13 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
| Analyzed by developer: | set |
|---|---|
| Component: | undetermined → avformat |
| Reproduced by developer: | set |
| Resolution: | → fixed |
| Status: | open → closed |
| Type: | defect → 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 by , 12 years ago
| Version: | 1.0 → git-master |
|---|
follow-up: 18 comment:17 by , 12 years ago
| Analyzed by developer: | unset |
|---|---|
| Cc: | added |
| Reproduced by developer: | unset |
| Resolution: | fixed |
| Status: | closed → reopened |
| Type: | enhancement → 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.
follow-ups: 19 20 comment:18 by , 12 years ago
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 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → 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-ENDLISTI 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 by , 12 years ago
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-ENDLISTI 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.
a patch for libavformat/segment.c