After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 780233 - m3u8: Consider URI repeat as white list
m3u8: Consider URI repeat as white list
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-03-18 04:32 UTC by Seungha Yang
Modified: 2018-11-03 14:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
m3u8: Consider URI repeat as white list (1.14 KB, patch)
2017-03-18 04:32 UTC, Seungha Yang
none Details | Review

Description Seungha Yang 2017-03-18 04:32:03 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.
Comment 1 Seungha Yang 2017-03-18 04:32:51 UTC
Created attachment 348214 [details] [review]
m3u8: Consider URI repeat as white list
Comment 2 Seungha Yang 2017-03-18 04:39:44 UTC
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
Comment 3 Sebastian Dröge (slomo) 2017-03-20 09:56:33 UTC
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?
Comment 4 Seungha Yang 2017-03-20 11:16:02 UTC
(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.
Comment 5 GStreamer system administrator 2018-11-03 14:06:21 UTC
-- 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.