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 626857 - MJPEG frame decode element should not generate an error if decoder fails to decode.
MJPEG frame decode element should not generate an error if decoder fails to d...
Status: RESOLVED DUPLICATE of bug 623063
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.24
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-08-13 15:38 UTC by American Dynamics
Modified: 2010-08-13 15:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description American Dynamics 2010-08-13 15:38:54 UTC
Currently, the gstreamer MJPEG element (gst-plugins-good.XXX/ext/jpeg/gstjpegdec.c) will generate an error (GST_ELEMENT_ERROR/GST_FLOW_ERROR) if the decoder fails to decode for a couple of specific anomalies.  We would like for these “anomalies” to actually generate a (GST_ELEMENT_WARNING/GST_FLOW_OK) instead of errors.  We attempt to obey the documentation: (GST_MESSAGE_ERROR
an error occured. When the application receives an error message it should stop playback of the pipeline and not assume that more data will be played. 
).  So in our application, the pipeline will ultimately be torn-down and rebuilt thus possibly disturbing important video footage.  A copy of an IRC chat with feedback from some gstreamer representatives has been attached.
 
<GstMatt> Greetings.
<GstMatt> Can I get an opinion?
<GstMatt> Should it be an error if a MJPEG frame fails to decode?
<__tim> probably not
<MikeS-tp> ideally not; perhaps a warning
<GstMatt> It was bothering me, because I'm tearing down the pipeline & rebuilding, when I get an error.
<GstMatt> But the next frame might be (is probably) just fine...
<GstMatt> I'm using decodebin, but I think it's using the ffmpeg jpeg decoder, inside
<GstMatt> Would you consider that a bug, then?
<MikeS-tp> GstMatt: if you're using the ffmpeg plugin, then.. don't?
<MikeS-tp> GstMatt: if the jpegdec element behaves the same, feel free to file a bug
<GstMatt> You mean if the jpegdec element also treats it as an error, then file a bug on the jpegdec element?
<MikeS-tp> Yes. It's generally a bad idea to use the ffmpeg elements where there are alternatives.
<GstMatt> Ah.
<GstMatt> But ffmpeg's JPEG decoder uses MMX
<GstMatt> Is it worth trying  to make the ffmpeg element behave better?
<GstMatt> (elements, I mean)
 
== MikeS-tp [~msmith@c-67-188-38-75.hsd1.ca.comcast.net]
==  realname : Michael Smith
==  channels : #gstreamer 
==  server   : leguin.freenode.net [Ume?, SE, EU]
==  account  : MikeS-tp
== End of WHOIS
 
== __tim [~timm@dsl-217-155-195-89.zen.co.uk]
==  realname : Tim-Philipp Müller
==  channels : #gstreamer 
==  server   : kornbluth.freenode.net [Frankfurt, Germany]
==           : is using a secure connection
==  account  : __tim
== End of WHOIS
Comment 1 Tim-Philipp Müller 2010-08-13 15:44:52 UTC

*** This bug has been marked as a duplicate of bug 623063 ***