GNOME Bugzilla – Bug 741542
videodecoder / audio decoder no need to send GST_ELEMENT_ERROR when track corrupt
Last modified: 2018-11-03 11:33:43 UTC
Created attachment 292734 [details] patch to comment the GST_ERRRO_OBJECT In https://bugzilla.gnome.org/show_bug.cgi?id=711094 commit 81471099d22e7f1d9e2a9b4ac1182b259cc7fb3a and f8477e6b88fdb364809bef70ac3909aba878978f When there is input data and no output data to the end of the stream, it will send GST_ELEMENT_ERROR, So the clips playing will quit. However, if only one of the tracks is corrupt, there is no need to quit other tracks playing. The patch comments the GST_ELEMENT_ERROR() and just add GST_ERROR_OBJECT() information instead.
Created attachment 292741 [details] [review] patch to comment the GST_ERRRO_OBJECT
The reason for this is that you want some kind of error indication if there was no data at all but there was supposed to be data. With these errors what you should get is a single error at the very end of the stream, but e.g. a correct audio stream would still play fine. Consider the case where all streams don't play correctly. Without those error messages just nothing would happen and the stream ends. With these error messages you get an actual error in the end as expected. I assume what we could do is that decodebin/uridecodebin/playbin could aggregate these specific error messages (how to distinguish from others?) and convert them to a warning message unless all streams had such an error message. That way you only get an error if all streams actually failed.
Thanks for the answer. So would there be a plan to do such aggregation in decodebin/uridecodebin/playbin to handle these error? Currently maybe we will just print the error message, and without sending the GST_ELEMENT_ERROR in our work, until deocdebin/uridecodebin/playbin can handle these message Thanks Lyon
Well, someone would have to implement that. But it seems to be the correct solution for this problem.
Hi, I've met an use case below, could anybody give us some advice: When there is corrupt audio track in the stream (say there is unrecoverable error we met). is there anyway good way to stop the audio track and without stop the whole stream? I see in the gstaudiodecoder.c, there is a function gst_audio_decoder_error(), which will send error message and return GST_FLOW_ERROR when error(say deocding error) is exceed the max count. However, I don't see it will return GST_FLOW_EOS to upstream or push eos event to downstream. I tried in the audio decoder subclass to return GST_FLOW_EOS to upstream, but sometimes the video track data full in the queue will block the whole preroll and there is no chance for the upstream demux to send eos event downstream (which will cause it hang in preroll). So I also push eos event to downstream in subclass when meeting the unrecoverable error, it can solved the problem. I was wondering if this mechanism (return EOS upstream and push eos event downstream meanwhile)can be used in the baseclass (audio decoder) in gst_audio_decoder_error().
There currently is no mechanism to ignore errors in specific parts of the pipeline, especially not inside automatically created pipelines like decodebin/playbin. What you described is not really a solution to this problem either as it will not allow to detect errors from the application. If you have a manual pipeline you can do that by ignoring ERROR messages from specific parts of your pipeline, ignoring GST_FLOW_ERROR and unlinking broken pipeline parts.
We just found in gstbaseparse.c, similar situation as vidoedecoder/audiodecoder. if one of the track cannot find valid frame in the parser, it will send GST_ELEMENT_ERROR, which will cause all other tracks quit playing. It looks the same behavior should be done as videodecoder/audiodecoder in the baseparse.
Created attachment 302499 [details] [review] patch for gstbaseparse There is no need to send GST_ELEMENT_ERROR becuase ohter tracks may still good to play. no need to end the element, just print error message is enough
Comment on attachment 302499 [details] [review] patch for gstbaseparse It should probably still throw an error if there's no upstream demuxer though?
-- 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/gst-plugins-base/issues/150.