[FFmpeg-trac] #1642(avformat:reopened): -f segment: automagically generate #EXTM3U tags to -segment_list generated playlists

[FFmpeg]

#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 saste):

 Replying to [comment:6 kelexel]:
 > Hi, first of all, many thanks for your 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, this behavior from your patch will really, definitely, break
 HLS.
 >
 > Keep in mind I am talking about transcoding to -f segment 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, and all
 the segments to read the file, so the iOS device and mobile safari will be
 happy and know where your steam starts, when it ends and in how many
 segments, and the length of said segments it should be expecting.
 >
 > 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 see there are several issues here.

 First of all, I confirm that the M3U8 feature is not broken, in the sense
 that it complies with the specifications I read so far (the document I
 linked before, and the one you proposed), so I still consider '''this'''
 ticket closed.

 Second, you are doing some assumptions about M3U8 which are '''against'''
 the specifications, for example about the position of the
 EXT-X-TARGETDURATION tag. Note that I have no idea of how this RTMP -> HLS
 thing works at all, and I can't test it. So if you can provide a
 reproducible failure with the M3U8 generated by ffmpeg, or simply confirm
 that moving the EXT-X-TARGETDURATION at the begin of the file will fix it,
 please do.

 My assumption was that the M3U8 file was read at once and parsed and
 converted by the reader into a list of files to read, and the duration
 information could be retrieved whatever its position was. In case the file
 is read continuously we can't predict the maximum duration of the segments
 in the list, not without a crystal ball, so the solution in this case
 would be to provide a "fake" EXT-X-TARGETDURATION at the begin of the file
 as you seem to suggest (which would be against M3U8 specifications).

 Note that this '''can''' be done if it fixes a problem, e.g. by providing
 a new type m3u8-hls or switch, but note again that this ticket is about
 M3U8 playlists, and not concerned with the weird additional requirements
 of live transcoding whatsoever, so it belongs to a separate ticket.

 Also I suppose that the -segment_list_size option was designed with that
 scenario in mind, so maybe you could adapt your setup to make use of that
 feature.

 > 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.

 Just to clarify, I'm happy to apply (or even modify/readapt) other people
 patches, only I care if that things work properly.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1642#comment:9>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker