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 781183 - adaptivedemux: Support period change in live playlist
adaptivedemux: Support period change in live playlist
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.14.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-04-11 14:36 UTC by Seungha Yang
Modified: 2018-05-14 14:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
adaptivedemux: Support period change in live playlist (2.03 KB, patch)
2017-04-11 14:38 UTC, Seungha Yang
none Details | Review
dashdemux: Fix sync of updated manifest from previous one (1.14 KB, patch)
2017-04-11 14:39 UTC, Seungha Yang
none Details | Review
adaptivedemux: Support period change in live playlist (2.09 KB, patch)
2018-05-10 14:10 UTC, Seungha Yang
none Details | Review
adaptivedemux: Support period change in live playlist (2.62 KB, patch)
2018-05-11 06:53 UTC, Seungha Yang
committed Details | Review
dashdemux: Fix sync of updated manifest from previous one (1.33 KB, patch)
2018-05-11 06:54 UTC, Seungha Yang
committed Details | Review

Description Seungha Yang 2017-04-11 14:36:57 UTC
live playlist can have multi-period
Comment 1 Seungha Yang 2017-04-11 14:38:13 UTC
Created attachment 349681 [details] [review]
adaptivedemux: Support period change in live playlist
Comment 2 Seungha Yang 2017-04-11 14:39:14 UTC
Created attachment 349682 [details] [review]
dashdemux: Fix sync of updated manifest from previous one

_get_next_fragment_timestamp() returns relative timestamp to period start.
But gst_mpd_client_stream_seek() uses absolute MPD timeline.
Comment 3 Seungha Yang 2017-04-11 14:43:00 UTC
Following MPD has 85sec update period and each period has 3min duration.
http://vm2.dashif.org/livesim/periods_20/testpic_2s/Manifest.mpd

Current adaptive/dash demux has two issues.
One is, period change is possible only static mpd. And when mpd is updated, period start does not considered. So, after updating mpd, abnormal segments are fetched. (e.g., go back to the first segment of period)
Comment 4 Seungha Yang 2018-05-10 14:10:07 UTC
Created attachment 371899 [details] [review]
adaptivedemux: Support period change in live playlist

Rebase. The reported issue is still there
Comment 5 Edward Hervey 2018-05-11 05:29:42 UTC
Review of attachment 371899 [details] [review]:

Can you put more details in the commit message explaining what those changes do (something like "it was previously doing ... whereas we need ... and therefore we do ...")
Comment 6 Seungha Yang 2018-05-11 06:53:45 UTC
Created attachment 371926 [details] [review]
adaptivedemux: Support period change in live playlist

Regardless of LIVE or VOD, "a manifest has next period but 
currently EOSed" state is meaning that it's time to advance period.

Previous behavior of adpativedemux, however, was able to period
advancing only for VOD case, since the adaptivedemux tried to
update and wait new manifest without respecting existence of the next period.
Comment 7 Seungha Yang 2018-05-11 06:54:46 UTC
Created attachment 371927 [details] [review]
dashdemux: Fix sync of updated manifest from previous one

Add some comment in code
Comment 8 Edward Hervey 2018-05-12 07:29:57 UTC
Attachment 371926 [details] pushed as a8cb766 - adaptivedemux: Support period change in live playlist
Attachment 371927 [details] pushed as 9956f22 - dashdemux: Fix sync of updated manifest from previous one