[FFmpeg-trac] #1642(avformat:reopened): -f segment: automagically generate #EXTM3U tags to -segment_list generated playlists
FFmpeg
trac at avcodec.org
Mon Sep 3 23:30:37 CEST 2012
#1642: -f segment: automagically generate #EXTM3U tags to -segment_list generated
playlists
-------------------------------------+-------------------------------------
Reporter: kelexel | Owner:
Type: enhancement | Status: reopened
Priority: normal | Component: avformat
Version: git-master | Resolution:
Keywords: segment, | Blocked By:
HLS, m3u8 | Reproduced by developer: 1
Blocking: |
Analyzed by developer: 1 |
-------------------------------------+-------------------------------------
Comment (by kelexel):
I might have spotted an issue.
Take the following example:
ffmpeg -i rtmp://foo.ext/app/stream ... -f ... -segment_list_live
Here we're transcoding a live rtmp feed, ok.
Problem:
If broadcaster disconnects from RTMP server (connection issue, whatever)
ffmpeg assumes the stream is ending, thus adds EXT-X-ENDLIST tag to the
playlist.
HLS clients when seeing this tag will go from live > record mode, so the
stream playback will end on the HLS clients.
Now, broadcaster comes back online, streams again to the rtmpd, and we re-
start ffmpeg.
A new playlist is normally generated ... all *seems* fine BUT(!!!):
If HLS clients "refresh" the url, they will most likely pick the cached
playlist rather than the one.. And since the cached playlist has
EXT-X-ENDLIST in it, it will just "replay" the last containing segments
and totally ignore the new server-side playlist.
So, in theory, if using -segment_list_live it is a bad idea to write
EXT-X-ENDLIST..
BUT (hehe), there *seems* to be another -useful- tag, namely "#EXT-X
-ALLOW-CACHE:1/0"
I think it's mostly meant for caching mpegts files, but might also work
with the playlists.
Will test and report my findings..
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1642#comment:21>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list