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 711086 - hlssink: doesn't have the sink flag set
hlssink: doesn't have the sink flag set
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.x
Other All
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-29 17:04 UTC by Baldur Gislason
Modified: 2013-11-07 16:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Baldur Gislason 2013-10-29 17:04:40 UTC
hlssink doesn't appear to handle EOS events properly so the host application expecting an EOS event upon the end of pipeline execution does not receive the event.
Proof of concept application based on hello world app in C:
http://paste.ubuntu.com/6325031/

However running the same pipeline under gst-launch works because gst-launch doesn't use the same callback method to receive the EOS event.
Comment 1 Baldur Gislason 2013-10-30 13:53:47 UTC
Running the app with debug level 6, grep -i eos:
http://paste.ubuntu.com/6330121/
Comment 2 Alessandro Decina 2013-11-02 10:51:00 UTC
The problem here is that you're nesting two pipelines (pipeline0 inside hellodear) and that doesn't appear to work too well. The outer pipeline (hellodear) never reaches EOS because gstbin.c:is_eos always returns FALSE, since the function checks if all the sinks have emitted EOS and hellodear doesn't contain any sinks.

If you get rid of the outer hellodear pipeline things works as expected.
Comment 3 Thiago Sousa Santos 2013-11-07 16:12:44 UTC
What is the use case here for having nested pipelines? Maybe you wanted a bin inside a pipeline? This seems like a weird usecase.

In any case, hlssink didn't have the SINK flag set on it and it was causing the failure.


This commit 805e313cce90f69580704e3e604481ab416d209e fixes it, thanks for reporting this bug.
Comment 4 Baldur Gislason 2013-11-07 16:58:10 UTC
Yes it appears the nesting was unnecessary, there was no particular reason for it, I have just always done it like this (since 2010) and it has always worked. Removing the nesting and creating the initial bin with parse_launch worked around the problem.