GNOME Bugzilla – Bug 780233
m3u8: Consider URI repeat as white list
Last modified: 2018-11-03 14:06:21 UTC
Some live stream have repeated fragment URIs for such as AD with DISCONTINUITY tags. So there might be same URI but different sequence. That's not a violation of spec.
Created attachment 348214 [details] [review] m3u8: Consider URI repeat as white list
Hello slomo I have some live hls manifests which have AD insertion between programs. During the AD time, the ADs are repeated several times with DISCONTINUITY tags. And the some fragments for ADs have same URIs. Should we consider that kinds of manifests as inconsistent manifest? For example, #EXT-X-MEDIA-SEQUENCE:37 #EXTINF:xxx http://my-content/content1.ts #EXTINF:xxx http://my-content/content2.ts #EXT-X-DISCONTINUITY #EXTINF:xxx http://my-content/ad1.ts #EXTINF:xxx http://my-content/ad2.ts #EXT-X-DISCONTINUITY #EXTINF:xxx http://my-content/ad1.ts #EXTINF:xxx http://my-content/ad2.ts .... #EXT-X-DISCONTINUITY #EXTINF:xxx http://my-content/content3.ts
I'm not sure about that. I guess *if* there is #EXT-X-MEDIA-SEQUENCE in the m3u8, it's no problem to accept duplicated URIs, which should handle your case. Without not so much, as then we need to use the URIs for correlating the media sequence ID of the previous and current m3u8, and if there are duplicated URIs this becomes a bit tricky. However also for the case when we have media sequence IDs, I'm aware of streams that count inconsistently and assign the same ID to different URIs... which is exactly the case to catch here. Can you check what the HLS spec specifically says about this? In the section that is quoted in the code above the consistency checking. Should we relax the check and that's still according to the spec?
(In reply to Sebastian Dröge (slomo) from comment #3) > Can you check what the HLS spec specifically says about this? In the section > that is quoted in the code above the consistency checking. Should we relax > the check and that's still according to the spec? Spec's Section 3 is saying that unserialized segment timestamps is allowed for DISCONTINUITY case, as we know. Since the spec defines "incremental MEDIA-SEQUENCE number", but no restriction of duplicated URI in playlist, so my case DISCONTINUITY + duplicated URI) meets the spec. 3. Media Segments .... Each Media Segment MUST carry the continuation of the encoded bitstream from the end of the segment with the previous Media Sequence Number, where values in a series such as timestamps and Continuity Counters MUST continue uninterrupted. The only exceptions are the first Media Segment ever to appear in a Media Playlist, and Media Segments which are explicitly *signaled as discontinuities* (Section 4.3.2.3). Unmarked media discontinuities can trigger playback errors. Therefore, I think we should relax the condition, but to be more correct, we might need to check more something like DISCONTINUITY tag or DISCONTINUITY-SEQUENCE.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/538.