GNOME Bugzilla – Bug 629910
jpegparse: properly clean up comment string
Last modified: 2010-12-11 21:51:05 UTC
I have this error connecting to the mjpeg from an axis camera: GStreamer-WARNING **: Trying to set string on taglist field 'comment', but string is not valid UTF-8. Please file a bug. according to Wim Taymans "it means an element doesn't properly clean up the comment string before handing it to the application" thanks drakkan1000
Created attachment 170518 [details] wireshark dump
Can't you tell the pipeline? It would be usefuly to limmit cehcking which element it could be.
Could you run your code (or gst-launch-0.10) with $ G_DEBUG=fatal_warnings gdb --args ./yourapp ... and then when it breaks at the warnings get a stack trace with 'bt'? (I suspect jpegparse btw, I noticed other brokenness wrt comment tags there too the other day, moving there for now)
yes the problem is jpegparse, this pipeline works without warning: gst-launch-0.10 -v souphttpsrc location=http://root:npgadmin@192.168.2.136/mjpg/1/video.mjpg ! multipartdemux ! jpegdec ! xvimagesink while this one give the warning: gst-launch-0.10 -v souphttpsrc location=http://root:npgadmin@192.168.2.136/mjpg/1/video.mjpg ! multipartdemux ! jpegparse ! jpegdec ! xvimagesink here is the trace, I suspect it is not useful since I haven't debug symbol: (gdb) bt
+ Trace 223878
Created attachment 171148 [details] [review] jpegparse: Convert string to utf8 on tag adding From the bt it seems be jpegparse, this patch should fix it, can you try it? Alternatively, you could gdp payload your camera output so that we could reproduce it over and test. Something like gst-launch -e souphttpsrc ! gdppay ! filesink location=stream.gdp should provide us with a sample to test.
Created attachment 171177 [details] gdppayload produced with: gst-launch-0.10 -e souphttpsrc location=.. ! multipartdemux ! gdppay ! filesink location=stream.gdp I get the same warning with the following pipeline: gst-launch-0.10 filesrc location=/home/nicola/stream.gdp ! gdpdepay ! jpegparse ! jpegdec ! xvimagesink
According to the TIFF spec such fields use plain ascii: ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary zero). I can't find anything about this in official jfif specs: http://www.jpeg.org/public/jfif.pdf Also the libjpeg sources don't help much. So if the attached patch help, it could be okay, otherwise we might want to consider forcing it to be ascii.
No, the patch doesn't fix it. Adding a check for is_utf8 in the end should make it not assert. But it will lose the COM tag.
Bug #626618 now also contains a patch that tries to address this.
Had not noticed this bug here, but the following handles this essentially as the patch here does: commit a3144019068b952ee2b74c5daeec7a869075af0b Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Dec 6 19:00:28 2010 +0100 jpegparse: try to convert comment tag to UTF-8 Note: it seems the attached patch has a minor typo (still adds non-transformed comment to the taglist) and as such may have failed to fix (as mentioned above). Above commit does eliminate the warning.
I just compiled the latest svn and I still have the same warning
My bad, the latest git solve the issue, thanks Nicola