GNOME Bugzilla – Bug 323023
[rmdemux] stops immediately if there are unlinked source pads
Last modified: 2006-03-24 12:09:27 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.
Created attachment 55520 [details] [review] This patch makes Christian happy.
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 posted.
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?
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.
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.
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.
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", ...)
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.
you mean the sources, right?
no wait - you mean only the sinks should post an EOS _message_ on the bus.
any change on this bug?
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).
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_all_source_pads_unlinked), (gst_rmdemux_at_least_one_stream_flowok), (gst_rmdemux_add_stream), (gst_rmdemux_parse_packet): * gst/realmedia/rmdemux.h: Handle unlinked source pads properly and stop if all source pads are unlinked, but only then (#323023).
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.