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 747449 - adaptivedemux: multiple period case does not work well
adaptivedemux: multiple period case does not work well
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-07 13:16 UTC by xixi
Modified: 2016-01-10 20:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.46 KB, patch)
2015-04-07 13:20 UTC, xixi
none Details | Review
multiple period case (2.52 KB, text/plain)
2015-04-08 12:25 UTC, xixi
  Details
new patch (2.49 KB, patch)
2015-04-11 14:48 UTC, xixi
needs-work Details | Review

Description xixi 2015-04-07 13:16:30 UTC
I tested MPEG-DASH multiple period case on master branch.
It does NOT crash, yet it does NOT work well. (because it crashed in 1.4.5 branch, that's why I tried it on master, please refer to Bug 747028 )
 
it failed to detect all streams reached the end, thus failed to advance to next period.
Comment 1 xixi 2015-04-07 13:20:38 UTC
Created attachment 301069 [details] [review]
patch

a patch is attached.
 
detect all streams have reached the end, and advance to next period.
Comment 2 Thiago Sousa Santos 2015-04-07 13:27:17 UTC
Do you have an online example stream or a way to create one to be used locally?
Comment 3 xixi 2015-04-08 12:25:45 UTC
Created attachment 301127 [details]
multiple period case

a test case is attached.


use it locally, and it will "redirect" segment url to an online content server.
Comment 4 Thiago Sousa Santos 2015-04-09 19:32:00 UTC
Review of attachment 301069 [details] [review]:

This causes another issue that is ignoring downstream returns of GST_FLOW_EOS. Basically, downstream elements can return GST_FLOW_EOS to make upstream know that the stream should end. For example, they might be configured with some GstSegment that has a stop that is earlier than upstream knows. This would cause this return to be ignored.

Perhaps we need to have 2 status variables here? One for our internal playlist position and another relative to what downstream returned to us?

Otherwise nice catch, I can reproduce the bug here.
Comment 5 xixi 2015-04-11 14:48:11 UTC
Created attachment 301365 [details] [review]
new patch

new patch is attached.

Please note that I reuse the "eos" field in "_GstAdaptiveDemuxStream" struct, and delete previous related code, since I think it's useless. Please review whether if it will cause some side effects.
Comment 6 xixi 2015-05-14 03:25:15 UTC
ping... any comments will be appreciated
Comment 7 Sebastian Dröge (slomo) 2015-08-16 11:26:11 UTC
Comment on attachment 301365 [details] [review]
new patch

This does not fix your sample mpd, it still goes EOS at 40s instead of continuing with the next period.

The multi-period stream at http://dash.edgesuite.net/dash264/TestCases/5a/nomor/1.mpd works fine (with and without your patch).
Comment 8 Sebastian Dröge (slomo) 2015-09-02 15:43:02 UTC
See bug #754222 which is related. Can you update your patch on top of that and make it work again?
Comment 9 Sebastian Dröge (slomo) 2016-01-10 20:08:00 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!