GNOME Bugzilla – Bug 759033
basesrc: When live, sending EOS after early runtime errors have no effect
Last modified: 2018-11-03 12:31:09 UTC
Filing against v4l2src for now, as it's the only src I found that could reproduce this. gst-launch-1.0 -e v4l2src ! identity error-after=1 ! fakesink
Ok, same with all live sources: gst-launch-1.0 -e fakesrc is-live=1 ! identity error-after=1 ! fakesink
I don't think this is a bug. After an ERROR message you can't expect to get an EOS message or anything really.
Created attachment 316874 [details] [review] gst-launch: Don't wait for the EOS message after errors After an ERROR message, it's not guaranteed that we'll get an EOS message or anything really. The only thing that can be done at this point is to shut down the pipeline immediately.
Review of attachment 316874 [details] [review]: ::: tools/gst-launch.c @@ +1121,3 @@ + PRINT (_("EOS on shutdown enabled -- Forcing EOS on the pipeline\n")); + gst_element_send_event (pipeline, gst_event_new_eos ()); + ignore_errors = FALSE; Is this boolean still useful ?
I believe at some point we did make an effort to make sure that elements driving the pipeline send an EOS event when they stop streaming after an error. It seems like desirable behaviour to me, is there any good reason not to do that?
It's a good idea but I think it's not a good idea to depend on that
The reason why this doesn't work here is that the error happens while the pipeline is only set to PAUSED. The EOS event reaches the sink, the sink prerolls but it waits with posting the EOS message until the pipeline is PLAYING. EOS messages are only ever posted in PLAYING.
(In reply to Sebastian Dröge (slomo) from comment #7) > EOS messages are only ever posted in PLAYING. Should gst-launch try to set the pipeline to PLAYING again before giving up ?
It will never reach PLAYING because of this error
Ok, then shall we just merge your patch, or try to wait with a timeout ?
I let that for Tim and you to decide :) IMHO a timeout would indeed be nicer here
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/143.