Gracefully Handle (or ignore) GstFlowReturns

[gotsring]

Tim Müller wrote
> There's an errorignore element in gst-plugins-bad (we should really
> move that to core in the next cycle).

I have added errorignore to create the following pipeline:

souphttpsrc location="http://192.168.18.101/mjpeg" is-live=true retries=-1 !
queue leaky=2 max-size-buffers=10 ! errorignore ignore-error=true
convert-to=0 ! multipartdemux boundary=fbdr ! multiqueue ! jpegparse !
videorate ! 'image/jpeg, framerate=20/1' ! jpegdec ! d3dvideosink sync=false
async=false

This indeed appears to prevent the GST_FLOW_ERROR from travelling upstream
to the souphttpsrc. In order to restart the errorignore element after an
error (allowing it to drop the bad frame, then continue operation), I have a
section in the bus event listener that tests if the posted error is from
multipartdemux. If so, it sends a GST_EVENT_RECONFIGURE to the errorignore
sink pad using:

GstPad* errorignore_sinkpad = gst_element_get_static_pad(data->errorignore,
"sink");
if (errorignore_sinkpad != NULL) {
    gst_pad_push_event(errorignore_sinkpad, gst_event_new_reconfigure());
    gst_object_unref(errorignore_sinkpad);
}


This does reset the errorignore element, but I have the following questions:

1. The error continues/repeatedly occurs
By this, I mean that as soon as multipartdemux receives a bad buffer, it
immediately throws a GST_FLOW_ERROR. Errorignore catches it to prevent it
going to the source, then the bus event listener catches the error and
restarts errorignore. Buffers start flowing out of errorignore into
multipartdemux again, immediately triggering the same error, ad infinitum.
Documentation says errorignore unrefs the buffers after catching an error,
but do I also have to send a FLUSH signal or something to clean out
something? I'm running tests now, as well as verifying the error isn't
originating upstream, but I figured I'd ask if I was missing something.

2. The method to restart errorignore looks sloppy.
Catching an error in the bus seems a bit awkward. Is there a cleaner way
send a signal that restarts errorignore? Should I be triggering the
RECONFIGURE event with a probe or a different event callback attached to the
errorignore element itself? I may end up tinkering with the errorignore
source to add an option to silently continue after an error without the need
to send a signal.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/