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 323023 - [rmdemux] stops immediately if there are unlinked source pads
[rmdemux] stops immediately if there are unlinked source pads
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: Normal normal
: 0.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2005-12-02 14:12 UTC by Michael Smith
Modified: 2006-03-24 12:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

This patch makes Christian happy. (2.12 KB, patch)
2005-12-02 14:13 UTC, Michael Smith
none Details | Review
my take on this, includes fix for broken codec_data handling (10.09 KB, patch)
2006-03-21 20:46 UTC, Tim-Philipp Müller
none Details | Review

Description Michael Smith 2005-12-02 14:12:43 UTC
Real demuxer terminates immediately if a pad for a stream is unlinked.

Also, it fails to send events (notably, EOS) if one or more pads are unlinked.

Patch to come.
Comment 1 Michael Smith 2005-12-02 14:13:41 UTC
Created attachment 55520 [details] [review]
This patch makes Christian happy.
Comment 2 Andy Wingo 2005-12-02 14:25:11 UTC
How does this behave if the user has no real decoders installed? I would think
that if no source pad is connected that it should still cause and error to be
Comment 3 Tim-Philipp Müller 2005-12-02 14:28:31 UTC
Why is it an error if no pads are connected?

If the pad has real video caps and there is no real decoder installed, that is
for decodebin or the application to figure out. In that case decodebin should
post an error about missing decoders, no?
Comment 4 Michael Smith 2005-12-02 14:34:10 UTC
Goes through the entire file, tries to EOS (by pushing the EOS event through the
srcpads), doesn't succeed since there's nowhere for the EOS to go to.

So, that's two problems: we continue output even when there are no linked pads,
and we don't EOS properly.

How do other demuxers handle this? I'm not sure on how to:
a) handle EOS properly
b) find out if a pad is linked without pushing to it.
Comment 5 Andy Wingo 2005-12-02 17:09:19 UTC
I think the ogg demuxer does the same as rmdemux with this patch.

You cannot find out if a pad is linked without pushing to it. At least, it's not
a useful test. For example the pad might be blocked, waiting for a push to link it.

The eos issue does need fixing though. This patch would improve experience for
people with real decoders, but it still seems it would make life for those
without real decoders worse (silent failure rather than error). Unless you can
show that decodebin handles this case I would wait to commit until later.
Comment 6 Andy Wingo 2005-12-02 17:10:57 UTC
another thought: if the demuxer detects that on all pads there is nothing linked
(e.g. via the flowreturn value) it should return a fatal flowreturn.
Comment 7 Edward Hervey 2005-12-03 13:01:23 UTC
Isn't this a more generic problem, where a pipeline which has got no sinks is
not a 'complete' pipeline ? Which is the case here.

It's the job of the application, or playbin, to figure that out and handle it
(show an error message, "You don't have a decoder for fomat video/gizmo-codec", ...)
Comment 8 Wim Taymans 2005-12-07 15:22:04 UTC
Ideally, the demuxer figures out that all pads are unlinked and sends
GST_FLOW_NOT_LINKED upstream (if chain based) or posts an error message (like
basesrc does). No EOS should be posted by any element as this is the sole job of
the sinks.
Comment 9 Jan Schmidt 2005-12-07 16:52:56 UTC
you mean the sources, right?
Comment 10 Jan Schmidt 2005-12-07 16:53:33 UTC
no wait - you mean only the sinks should post an EOS _message_ on the bus. 
Comment 11 Jan Schmidt 2006-01-25 21:44:20 UTC
any change on this bug?
Comment 12 Tim-Philipp Müller 2006-03-21 20:46:12 UTC
Created attachment 61728 [details] [review]
my take on this, includes fix for broken codec_data handling

I don't have a single file that plays back right though (audio doesn't work right yet, and ffmpeg doesn't include decoders for the video files I have, or crashes).
Comment 13 Tim-Philipp Müller 2006-03-24 11:44:32 UTC
Committed part of the patch that deals with unlinked pads. The codec_data stuff needs more work, but that's part of bug #334990.

 2006-03-24  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/realmedia/rmdemux.c: (gst_rmdemux_perform_seek),
        (gst_rmdemux_loop), (gst_rmdemux_chain), (gst_rmdemux_send_event),
        (gst_rmdemux_at_least_one_stream_flowok), (gst_rmdemux_add_stream),
        * gst/realmedia/rmdemux.h:
          Handle unlinked source pads properly and stop if all source pads
          are unlinked, but only then (#323023).
Comment 14 Tim-Philipp Müller 2006-03-24 12:09:27 UTC
Changed message posting as well (to STREAM FAILED rather than CORE ERROR):

2006-03-24  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/realmedia/rmdemux.c: (gst_rmdemux_init),
        (gst_rmdemux_validate_offset), (gst_rmdemux_loop),
        (gst_rmdemux_parse_mdpr), (gst_rmdemux_parse_packet):
          When operating in pull mode, post an error message on the
          bus when all source pads are unlinked or some other fatal
          error occured (#323023). Regrade some recurring debug messages
          to LOG level. Convert c++-style comments into C-style ones.