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 638107 - [mp4mux] cover art lost when transcoding from flac to mp4
[mp4mux] cover art lost when transcoding from flac to mp4
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.30
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-12-27 13:08 UTC by Antonio Frediani
Modified: 2011-05-30 10:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simply add the GST_TAG_IMAGE handling, working exactly like GST_TAG_PREVIEW_IMAGE (475 bytes, patch)
2010-12-27 13:08 UTC, Antonio Frediani
committed Details | Review
Self-generated FLAC file with cover image and other metadata (82.26 KB, audio/x-flac)
2010-12-28 08:26 UTC, Antonio Frediani
  Details

Description Antonio Frediani 2010-12-27 13:08:54 UTC
Created attachment 177093 [details] [review]
Simply add the GST_TAG_IMAGE handling, working exactly like GST_TAG_PREVIEW_IMAGE

When transcoding from flac to mp4/aac the cover art was not preserved. 
The problem seems to be that flac embedded pictures are decoded as "image" (GST_TAG_IMAGE) by flacdec, while mp4mux only handled GST_TAG_PREVIEW_IMAGE.

Adding the handling of GST_TAG_IMAGE within the tag_matches_mp4 struct seemed to work for me. 

I attach the patch against the current git trunk. I used the same fourcc as the existing GST_TAG_PREVIEW_IMAGE, from a quick research it doesn't seem to me this could be a problem, but please feel free to point me to the appropriate documentation if this isn't the case.

The command line I used for testing was:
gst-launch-0.10 filesrc location = filename.flac ! flacdec ! faac profile=2 bitrate=224000 ! mp4mux ! filesink location=filename.m4a
Comment 1 Thiago Sousa Santos 2010-12-27 19:45:14 UTC
Checking the docs here:

http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstTagList.html#GST-TAG-IMAGE:CAPS

it seems that GST_TAG_IMAGE should have a field on the buffer caps indicating what type of image it is, so we might want to check that before adding it a cover art.

Other than that I did some tests here with flac files that have cover art and flacdec couldn't find them, flacparse however did and posted the image as GST_TAG_PREVIEW_IMAGE.

It seems we have an inconsistency between flacdec and flacparse, both should find the same information and post the same tag about it, so, other than adding the support for mapping GST_TAG_IMAGE to qtmux/mp4mux, we need to fix this on flacdec/flacparse too.



What's the version of flacdec you're using? (gst-inspect flacdec) should tell the module and version on the top of the output.

And can you try with flacparse and check what tags it finds?
"gst-launch filesrc ! flacparse ! fakesink -t" should show them.
Comment 2 Antonio Frediani 2010-12-28 08:26:01 UTC
Created attachment 177119 [details]
Self-generated FLAC file with cover image and other metadata

This is a sample file I created for testing the conversion to m4a
Comment 3 Antonio Frediani 2010-12-28 08:29:55 UTC
Hi Thiago,
thanks for the excellent information.
You're right about the type field of GST_TAG_IMAGE. However, I didn't find a way to specify that information within the mp4 file itself, as it seems to me that the metadata blocks only carry image type (jpg, png...) and size. 
Do you know of any more detailed information about the mp4 metadata format, or have any proposal for the implementation of this part?

I have tried the tests you suggested but the results were quite different from yours.
Flacdec correctly manages to print the metadata:

FOUND TAG      : found by element "flacdec0".
           image: buffer of 27732 bytes, type: image/jpeg, width=(int)305, height=(int)350, image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_FRONT_COVER
FOUND TAG      : found by element "flacdec0".
     audio codec: FLAC
           album: Test Album
           title: Test Title
    track number: 1
extended comment: COMMENTS=Test Comment
          artist: Test Artist
            date: 2010-01-01
           genre: Classical
         comment: Test Comment

On the other hand, flacparse crashed on decoding the stream.

I tried several files with the same result. From the logs it seems a problem on the cover image reading . I see the error:
flacparse gstflacparse.c:1077:gst_flac_parse_handle_picture:<flacparse0> Error reading data
and when I tried to run it again on the same flac but having removed the cover art it completed without error.

My flacdec is 0.10.25, while flacparse is 0.10.20. My system is a Ubuntu Maverick. What vesion di you use? Do you want me to try another version?

I'm attaching an auto-generated flac file I used for test. I also have the debug log of the flacparse but I don't think I should attach it to this bug. Rather, if you think it necessary I will open another bug on flacparse.

Please let me know if you need any further information or tests

Thanks in advance,
Antonio
Comment 4 Sebastian Dröge (slomo) 2011-05-30 10:11:36 UTC
flacparse and flacdec now both handle the file correctly and post the same image tag. This fixes it in qtmux now.

commit 63d350ceb3f980d9780fb0bf5f5285e028fbbb6a
Author: Antonio Frediani <antonio.frediani@inwind.it>
Date:   Mon May 30 12:09:31 2011 +0200

    qtmux: Use GST_TAG_IMAGE for coverart too
    
    Fixes bug #638107.