[FFmpeg-trac] #1642(avformat:closed): -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:  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            |
-------------------------------------+-------------------------------------
Changes (by saste):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:3 kelexel]:
 > I am sorry, but I think your patch is not fully HLS compliant !
 >

 > First of, you did not add #EXT-X-TARGETDURATION:X in segment_list_open,
 you added in in segment_list_close, no clue why. From my tests and
 compared m3u8 playlists, this tag needs to sit on top, otherwise you
 cannot use HLS for live (RTMP) transcoding !
 > Because when live transcoding, we do not have the end of the stream yet,
 so we are not issuing a segment_list_close until a very long time. But,
 iOS clients need to know right now about #EXT-X-TARGETDURATION, thus the
 absolute need to have it in segment_list_open and not in
 segment_list_close.

 The format was written based on:
 http://tools.ietf.org/html/draft-pantos-http-live-streaming-08

 which is the only official M3U8 spec as far as I know. Note that there is
 no requirement of the tag to be at the top of the file, and since the file
 is supposed to be read and parsed '''at once''' this should not be an
 issue.

 The reason why it is written at the end is because it is much simpler from
 the coding point of view (you don't know the maximum segment duration
 until you write all files, so this avoids caching information in the
 segment).

 > Second, I do not understand your per-file generated #EXTINF tags.
 >
 > Here is the result of what it produced for me:
 >
 > {{{
 > #EXTM3U
 > #EXT-X-VERSION:4
 > #EXTINF:11.217433,
 > alpha_720p00000.ts
 > #EXTINF:9.605956,
 > alpha_720p00001.ts
 > #EXTINF:9.617756,
 > alpha_720p00002.ts
 > #EXTINF:6.033333,
 > alpha_720p00003.ts
 > #EXT-X-TARGETDURATION:11
 > #EXT-X-ENDLIST
 > }}}
 >
 > First, my segment_time is 10, here we have 11 (no clue why).
 > Second, I thought #EXTINF should give the duration of each segment,
 where here, we get wacky, decrementing durations (why?!)

 This is expected and not wrong (apart from the computation of target
 duration, which had to be "12" in the example below, patch fixing that
 already integrated). Please read the segment documentation, keep in mind
 that video segments are split at key-frames, and it is not in general
 possible to get predictable durations for each segment.

 > Conclusion, this patch does bring some m3u8 goodness, and is certainly
 more elegant that my (unexperienced) patch.
 >
 > But it does not work with live transcoded HLS streams, and produces
 doubtful m3u8 playlists.
 >
 > If you want to fix it, move #EXT-X-TARGETDURATION on top, ensure it has
 a valid segment_time and fix (or explain) the wacky #EXTINF tags
 >

 > Next time, maybe just have a quick look at the patches proposed.
 > Even if not being that elegant, they might contain some useful infos.

 My segment patchset predates your patch:
 http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/149665

 Note that I was not aware of your patch until I opened trac for closing
 the ticket, otherwise I would have tried to adapt your patch for
 integration. In general you're advised to send patches to ML if you want
 to work on them, as they will usually attract more attention.

 > Thank you.

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