[Bug 789084] New: adaptivedemux: throws errors on quality switch
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Oct 17 08:05:43 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=789084
Bug ID: 789084
Summary: adaptivedemux: throws errors on quality switch
Classification: Platform
Product: GStreamer
Version: 1.12.3
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: fzwoch at gmail.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 361717
--> https://bugzilla.gnome.org/attachment.cgi?id=361717&action=edit
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?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list