#4048: segment: Handle WebVTT as per HLS spec -------------------------------------+------------------------------------ Reporter: 11rcombs | Owner: Type: enhancement | Status: new Priority: normal | Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Comment (by cehoyos): Iiuc, there is a bug: Our hls muxer does not conform to the specification and produces output that is incorrect. Is that correct? If yes, please explain how this can be reproduced. (You know what I mean with ''explain''?) I know that you understand the ticket and I realize that whoever will fix this already understands the issue (and possibly already knows how to fix it). but ideally every ticket should be reproducible for every user. This is particularly important in the future: The commit fixing the ticket might (in theory) introduce another problem and whoever wants to fix it may not know so much about hls... Or said differently: It is great that you added a link to the specification and quoted the relevant paragraph, it will make somebody's life much easier. But as said previously this analysis (no matter if helpful like in this case or disturbing like in other tickets not created by you) should never replace the actual bug report. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4048#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#4048: segment: Handle WebVTT as per HLS spec -------------------------------------+------------------------------------ Reporter: 11rcombs | Owner: Type: enhancement | Status: new Priority: normal | Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Changes (by 11rcombs): * keywords: hls webvtt => Comment: It's not so much a bug as the lack of support for a newly-specified behavior. But let's use this {{{test.vtt}}} file as an example: {{{ 00:00.000 --> 00:07.000 Test line 1, spans segments 0 and 1 00:07.000 --> 00:08.000 Test line 2, contained in segment 1 00:16.000 --> 00:18.000 Test line 3, should be in segment 3 after an empty segment 2 00:18.000 --> 00:40.000 Test line 4, should span several segments }}} Let's run {{{ffmpeg -i in.vtt -f segment -segment_time 5 -segment_format webvtt -scodec copy out-%05d.vtt}}}. We get: out-00000.vtt {{{ WEBVTT 00:00.000 --> 00:07.000 Test line 1, spans segments 0 and 1 }}} out-00001.vtt {{{ WEBVTT 00:07.000 --> 00:08.000 Test line 2, contained in segment 1 }}} out-00002.vtt {{{ WEBVTT 00:16.000 --> 00:18.000 Test line 3, should be in segment 3 after an empty segment 2 }}} out-00003.vtt {{{ WEBVTT 00:18.000 --> 00:40.000 Test line 4, should span several segments }}} The correct output for HLS would be: out-00000.vtt {{{ WEBVTT 00:00.000 --> 00:07.000 Test line 1, spans segments 0 and 1 }}} out-00001.vtt {{{ WEBVTT 00:00.000 --> 00:07.000 Test line 1, spans segments 0 and 1 00:07.000 --> 00:08.000 Test line 2, contained in segment 1 }}} out-00002.vtt {{{ WEBVTT }}} out-00003.vtt {{{ WEBVTT 00:18.000 --> 00:40.000 Test line 4, should span several segments }}} out-00004.vtt {{{ WEBVTT 00:18.000 --> 00:40.000 Test line 4, should span several segments }}} <etc…, with more duplicates up to out-00007.vtt> The two behaviors that need adding (writing empty segments, and duplicating packets spanning multiple segments) seem like they could reasonably be separate options. The writing-empty-segments behavior seems sensible for generic subtitle segmenting (in order to have predictable segment durations), whereas duplicating packets is pretty WebVTT-in-HLS- specific. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4048#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#4048: segment: Handle WebVTT as per HLS spec -------------------------------------+------------------------------------ Reporter: 11rcombs | Owner: Type: enhancement | Status: new Priority: normal | Component: avformat Version: git-master | Resolution: Keywords: hls webvtt | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Comment (by Djfe): I guess this kinda belongs to this ticket: https://amd.cdn.turner.com/adultswim/episodes/no_uk_geo/bobsburgers/2017/03/... is the webvtt Stream (subtitle only stream) related to https://amd.cdn.turner.com/adultswim/episodes/no_uk_geo/bobsburgers/2017/03/... from http://www.adultswim.com/videos/bobs-burgers/the-itty-bitty-ditty- committee/ Though I'm not sure. If this is only an issue about the muxer but not the demuxer, then say so and I'll open a new ticket. FFmpeg only saves the first segment instead of merging all segments together, like it's described in this ticket. ffmpeg -i url -c copy example.vtt Since the m3u8 won't be up forever, here's the content of it: {{{ #EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:300 #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:300.299, bobsburgers_cc_505_Digital_IttyBittyDittyCommittee_stream_webvttvtt_00001.vtt #EXTINF:300.300, bobsburgers_cc_505_Digital_IttyBittyDittyCommittee_stream_webvttvtt_00002.vtt #EXTINF:300.300, bobsburgers_cc_505_Digital_IttyBittyDittyCommittee_stream_webvttvtt_00003.vtt #EXTINF:300.300, bobsburgers_cc_505_Digital_IttyBittyDittyCommittee_stream_webvttvtt_00004.vtt #EXTINF:104.104, bobsburgers_cc_505_Digital_IttyBittyDittyCommittee_stream_webvttvtt_00005.vtt #EXT-X-ENDLIST }}} FFmpeg only saves the first 5mins, so I guess that's the segment time. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4048#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker