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 574401 - metadatamux fails^WIS failure
metadatamux fails^WIS failure
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.12
Assigned To: Stefan Sauer (gstreamer, gtkdoc dev)
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-06 17:40 UTC by Edward Hervey
Modified: 2009-03-22 19:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the '1.jpg' file generated in the previous comment (9.77 KB, image/jpeg)
2009-03-12 16:24 UTC, Edward Hervey
  Details
add more logging, many cleanups, fix muxing jfifless jpeg (17.34 KB, patch)
2009-03-20 09:09 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review
essential fix for the problem, the otehrs are cleanuops. (902 bytes, patch)
2009-03-20 13:29 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Edward Hervey 2009-03-06 17:40:31 UTC
The metadata unit tests are failing....

After looking a bit deeper at this, the problem is with the following pipeline:
gst-launch-0.10 videotestsrc num-buffers=1 ! jpegenc ! metadatamux ! fakesink

It will fail because... the (perfectly valid) jpeg buffer given to metadatamux doesn't contain a 'APP0' marker (0xFFE0), which is
Even worse, it will fail if there is an 'APP0' marker but it's not just after the SOI (Start Of Image 0xFFD8) marker.

metadatamux should (1) parse the buffer to figure out where the APP0 marker is and (2) if not present create one.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-10 20:42:32 UTC
According to my ananlysis the probelm was that the configure was borked. It build metadata elemenst in any case, even if you had neither libexit/libexempi/libiptc. And then then tests failed. If I installed the devel files for those libs the tests work for me. I have fixed the configure to not build the element if the deps are missing.
Closing?
Comment 2 Edward Hervey 2009-03-11 07:40:46 UTC
The fact that metadatamux is failing seems to have nothing to do with external libraries. The analysis I did in the first comment doesn't use external code.
Comment 3 Jan Schmidt 2009-03-11 12:13:45 UTC
There's clearly something strange here - if jpegenc always produced a buffer that metadatamux couldn't understand, the test pipeline would never have worked at all - even for the author of the test.

Since it's been broken a long time, I think we should disable the failing test(s) for this release, and re-enable and fix them afterward.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-12 15:49:10 UTC
just for the record, this works for me. i have not yet figured why it fails e.g. for bilboed. I am not asking for a debug log though :/

gst-launch videotestsrc num-buffers=1 ! jpegenc ! metadatamux exif=true ! metadatademux ! fakesink
Comment 5 Edward Hervey 2009-03-12 16:23:01 UTC
$ gst-launch videotestsrc num-buffers=1 ! jpegenc ! metadatamux exif=true ! metadatademux ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstMetadataMux:metadatamux0: GStreamer encountered a general stream error.
Additional debug info:
gstbasemetadata.c(607): gst_base_metadata_parse (): /GstPipeline:pipeline0/GstMetadataMux:metadatamux0:
Failed to parse stream.
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...


Let's split this up.

$ gst-launch videotestsrc num-buffers=1 ! jpegenc ! filesink location=1.jpg

All good, produces the file, I can view it in eog or any image application.

$ gst-launch filesrc location=1.jpg ! metadatamux exif=True ! filesink location=2.jpg
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstMetadataMux:metadatamux0: GStreamer encountered a general stream error.
Additional debug info:
gstbasemetadata.c(607): gst_base_metadata_parse (): /GstPipeline:pipeline0/GstMetadataMux:metadatamux0:
Failed to parse stream.
Setting pipeline to NULL ...
Freeing pipeline ...

Comment 6 Edward Hervey 2009-03-12 16:24:03 UTC
Created attachment 130539 [details]
the '1.jpg' file generated in the previous comment

I'll let you try out with the file jpegenc generated.
Comment 7 Edward Hervey 2009-03-12 16:25:04 UTC
As you'll notice, that file doesn't contain the APP0 marker.
Comment 8 Jan Schmidt 2009-03-12 16:41:22 UTC
I get the same behaviour as Edward. AFAICT, I have all the libraries the metadata plugin needs installed.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-12 16:54:59 UTC
$ hexdump -C 1.jpg | head -n2
00000000  ff d8 ff db 00 43 00 05  03 04 04 04 03 05 04 04  |.....C..........|
00000010  04 05 05 05 06 07 0c 08  07 07 07 07 0f 0b 0b 09  |................|

$ gst-launch videotestsrc num-buffers=1 ! jpegenc ! filesink location=3.jpg
...
$ hexdump -C 3.jpg | head -n2
00000000  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |......JFIF......|
00000010  00 01 00 00 ff db 00 43  00 05 03 04 04 04 03 05  |.......C........|

libjpeg-6b
Version: 6b-14
Filename: pool/main/libj/libjpeg6b/libjpeg62_6b-14_i386.deb

This is Ubuntu 8.10, I'll try on openSuse 11.1 at home a bit later. I guess I won't need to try gentoo :)
Comment 10 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-12 18:52:55 UTC
On opensuse-11.1:
> hexdump -C 3.jpg | head -n2
00000000  ff d8 ff db 00 43 00 05  03 04 04 04 03 05 04 04  |.....C..........|
00000010  04 05 05 05 06 07 0c 08  07 07 07 07 0f 0b 0b 09  |................|

Name: libjpeg
Version: 6.2.0-843.47

Have a look at:
http://root.cern.ch/viewvc/vendors/libAfterImage/current/libjpeg/README?view=markup
search for "FILE FORMAT WARS" almost at the bottom. Seems that this 6b release introduced this, but this was 27-Mar-199 (see http://www.ijg.org/). Need to check if the jfif is a configure option.

But one thing is clear, metadatamux/demux is making expectations about the input and that needs fixing.
Comment 11 Edward Hervey 2009-03-12 19:09:03 UTC
Since we all agree, I'm disabling the unit tests until we can guarantee it succeeds whatever the underlying libjpeg used.
Comment 12 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-20 09:09:14 UTC
Created attachment 131016 [details] [review]
add more logging, many cleanups, fix muxing jfifless jpeg

> gst-launch videotestsrc num-buffers=1 ! jpegenc ! taginject tags="description=\"test image\"" ! metadatamux exif=true ! filesink location=2.jpg

> exifprobe -S 2.jpg
...

gst-plugins-bad/tests/check> make pipelines/metadata.check
Running suite(s): MetaData
100%: Checks: 2, Failures: 0, Errors: 0
Comment 13 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-20 13:29:02 UTC
Created attachment 131028 [details] [review]
essential fix for the problem, the otehrs are cleanuops.