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 789084 - adaptivedemux: throws errors on quality switch
adaptivedemux: throws errors on quality switch
Status: RESOLVED DUPLICATE of bug 789457
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.12.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-17 08:05 UTC by Florian Zwoch
Modified: 2017-10-26 08:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
error log (29.69 KB, text/plain)
2017-10-17 08:05 UTC, Florian Zwoch
Details

Description Florian Zwoch 2017-10-17 08:05:43 UTC
Created attachment 361717 [details]
error log

This is very stream (network) dependent. Tested with real live sources, I experience errors saying "Could not download fragments". This may happen almost immediately after receiving the first fragment - or sometimes also after a couple of minutes, or even hours.

It feels to me that this happens when the receiver decides to switch streams and adding new pads and removing old ones. I can prevent this error from happening when setting the "connection-speed" option in playbin basically locking HLS demux to one stream so no switching will occur.

I tracked it down to the the "Can't push EOS on non-exposed pad" error which will trigger a download error. I have no idea that this means in this logic or why this is happening. For testing I simply removed the "goto download_error:" line and the stream plays just fine and also seems to switch quality without major hiccups, I think. Not sure if this had any side effects though.

Attached is a GST_DEBUG=adaptivedemux:5 log when the issue occurred. I haven't grasped the logic on how the switching is done but I have seen references src_pad0, src_pad1 and src_pad2 - which feels strange? I would think two pads should be enough?
Comment 1 Florian Zwoch 2017-10-26 08:09:47 UTC

*** This bug has been marked as a duplicate of bug 789457 ***