GNOME Bugzilla – Bug 508321
[decodebin] EOS detected in typefind does not propagate
Last modified: 2011-05-19 06:20:26 UTC
Please describe the problem: When this file (see attached) is detected (incorrectly?) by typefind, the pipeline stalls with last message being: 0:00:02.736563560 29585 0x70b1d0 INFO GST_PADS gstpad.c:2928:gst_pad_event_default_dispatch:<typefind:sink> Sending event 0x6ab680 (eos) to all internally linked pads Presumably this should be a simple fix as this does work in 0.10.13 Steps to reproduce: gst-launch filesrc=gst_decodebin_achilles ! decodebin ! fanksink Actual results: Expected results: Does this happen every time? Other information:
Created attachment 102474 [details] test file
It seems that this happens (at least in this case) as soon as he mp3parse element is created. However, if you explicitly add this to the pipeline, typefind errors out. gst-launch filesrc location=gst_decodebin_achilles ! mp3parse ! decodebin ! fakesink ERROR: from element /pipeline0/decodebin0/typefind: Stream contains no data.
there's no valid mp3 file in here, so mp3parse never finds anything to output. It should throw an error on seeing EOS (or earlier?) in this case.
I agree that mp3parse should ideally post an error on seeing EOS and not having output any data, but I also think that whoever is driving the pipeline (in this case filesrc/basesrc, I guess), should also post an error when the gst_pad_push_event(EOS) fails, ie. something like: Index: gstbasesrc.c =================================================================== RCS file: /cvs/gstreamer/gstreamer/libs/gst/base/gstbasesrc.c,v retrieving revision 1.152 diff -u -p -r1.152 gstbasesrc.c --- gstbasesrc.c 9 Jan 2008 12:25:17 -0000 1.152 +++ gstbasesrc.c 13 Jan 2008 20:04:35 -0000 @@ -2154,7 +2154,18 @@ pause: gst_message_new_segment_done (GST_OBJECT_CAST (src), src->segment.format, src->segment.last_stop)); } else { - gst_pad_push_event (pad, gst_event_new_eos ()); + gboolean eos_ret; + + eos_ret = gst_pad_push_event (pad, gst_event_new_eos ()); + GST_ERROR ("eos_ret = %d", eos_ret); + if (!eos_ret) { + /* if downstream didn't handle the EOS event (like if it's not + * linked to a sink yet), post an error message so the app can + * shut down the pipeline correctly. */ + GST_ELEMENT_ERROR (src, STREAM, FAILED, + (_("Internal data flow error.")), + ("streaming task paused, downstream did not accept EOS")); + } src->priv->last_sent_eos = TRUE; } } else { Not sure why this worked in 0.10.13 right now ("something must have changed somewhere"), but it seems the reason the FALSE from push_event isn't propagated up to basesrc is that gst_pad_event_default_dispatch() doesn't accumulate the return values - I think it should only return TRUE if at least one of the _push_event() returned TRUE and otherwise FALSE.
Could be that mp3parse wasn't there at that point? (I don't remember), or decodebin was doing delayed plugging differently?
The problem with posting errors when EOS returns FALSE is that the EOS could have been refused because the pipeline was flushing for a seek. This can only be fixed correctly when we have a GstFlowReturn from a push_event.
The file is not detected as MP3 anymore, mp3parse (and probably everything else) now posts an error message on the bus if no data was received before EOS and events return a GstFlowReturn in 0.11. Anything else that should be done here?