[FFmpeg-trac] #1642(avformat:closed): -f segment: automagically generate #EXTM3U tags to -segment_list generated playlists
FFmpeg
trac at avcodec.org
Sun Aug 19 03:26:51 CEST 2012
#1642: -f segment: automagically generate #EXTM3U tags to -segment_list generated
playlists
-------------------------------------+-------------------------------------
Reporter: kelexel | Owner:
Type: enhancement | Status: closed
Priority: normal | Component: avformat
Version: git-master | Resolution: fixed
Keywords: segment, | Blocked By:
HLS, m3u8 | Reproduced by developer: 1
Blocking: |
Analyzed by developer: 1 |
-------------------------------------+-------------------------------------
Comment (by kelexel):
Hi, first of all, many thanks for the time invested in this issue.
Now, the real issue resides in the #EXT-X-TARGETDURATION being written at
the end of the file.
Because it is only written when ffmpeg exepects to have reached the end of
the file, it will really, definitely, break HLS.
Keep in mind I am talking about fetching a live (RTMP in my case) feed,
for which you have no clue of when the feed ends - so no clue of when you
will invoke segment_list_close)
All I can do is encourage you to check by yourself, using any source file
and -f segment, outputing mpegts files to a dir, and use an iOS device to
read said files.
The playlist will be read by the client each time the client will reach
the last file specified in the playlist, and keep doing it until it
eventually reaches a #EXT-X-ENDLIST) in said playlist.
If the iOS device has no clue of the segment length it should expect, it
will miserably fail to read said stream (at least on iOS 5.x)
So, once again, your patch will work for known duration files, i.e.: I'm
transcoding a file, because the client will find in the playlist, at the
end, both the EXT-X-TARGETDURATION and mostly EXT-X-ENDFILE tags, so the
iOS device and mobile safari will be happy and know where your steam
starts, when it ends and in how many segments it should expect it.
But this logic breaks HTTPLiveStream !
I won't argue on the pseuso scarse (I agree) RFC on m3u8.
But real-life tests show that if that tag is not present at the top of the
file, it will simply not work.
iOS devices need to know that tag to accept reading the mpeg2ts segments.
If it doesn't find that tag it simply throws an error. When you are doing
live transcoding of a current video stream, you have no idea when the
stream will end, so your only chance is to put that tag in
segment_list_open and really not in segment_list_close
I am not arguing who patched what first, I am not a developer, just an
aware-user.
All I can say is that if you use my (dirty) patch on previous sources,
your iOS device will play a live and pre-recorded stream fine.
But, if you use your patch, than iOS devices will only play pre-recorded
streams, and fail to play live-transcoded streams.
That's all I'm trying to point out.
With all due respect to you and the ffmpeg community.
Please consider modifying your patch.
Best regards.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1642#comment:6>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list