After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741542 - videodecoder / audio decoder no need to send GST_ELEMENT_ERROR when track corrupt
videodecoder / audio decoder no need to send GST_ELEMENT_ERROR when track cor...
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-12-15 06:58 UTC by Lyon
Modified: 2018-11-03 11:33 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch to comment the GST_ERRRO_OBJECT (1.69 KB, application/octet-stream)
2014-12-15 06:58 UTC, Lyon
patch to comment the GST_ERRRO_OBJECT (1.70 KB, patch)
2014-12-15 08:24 UTC, Lyon
needs-work Details | Review
patch for gstbaseparse (1.33 KB, patch)
2015-04-28 07:20 UTC, Lyon
reviewed Details | Review

Description Lyon 2014-12-15 06:58:43 UTC
Created attachment 292734 [details]
patch to comment the GST_ERRRO_OBJECT

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.
Comment 1 Lyon 2014-12-15 08:24:29 UTC
Created attachment 292741 [details] [review]
patch to comment the GST_ERRRO_OBJECT
Comment 2 Sebastian Dröge (slomo) 2014-12-15 09:01:08 UTC
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.
Comment 3 Lyon 2014-12-15 09:22:03 UTC
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 

Comment 4 Sebastian Dröge (slomo) 2014-12-15 09:27:52 UTC
Well, someone would have to implement that. But it seems to be the correct solution for this problem.
Comment 5 Lyon 2015-01-06 05:22:22 UTC
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().
Comment 6 Sebastian Dröge (slomo) 2015-01-08 13:06:50 UTC
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.
Comment 7 Lyon 2015-04-28 06:35:24 UTC
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.
Comment 8 Lyon 2015-04-28 07:20:09 UTC
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 9 Tim-Philipp Müller 2015-04-28 13:38:59 UTC
Comment on attachment 302499 [details] [review]
patch for gstbaseparse

It should probably still throw an error if there's no upstream demuxer though?
Comment 10 GStreamer system administrator 2018-11-03 11:33:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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: