GNOME Bugzilla – Bug 339704
[id3demux] read images from ID3 tags
Last modified: 2006-06-11 20:12:21 UTC
This could be used to display images embedded in ID3 tags in some mp3 files. <hadess> doctau__: is there a gst bug already opened to be able to read thumbnails from id3 tags in gst? <doctau__> hadess: no idea, but I can tell you exactly where you need to add the code (I was just looking at it) <doctau__> gst-plugins-good/gst/id3demux/id3v2frame.c:id3demux_id3v2_parse_frame()
We should probably add a new tag for that to the core, similar to what was added to the 0.8 branch (GST_TAG_IMAGE or whatever).
The problem I see with tag, as opposed to creating a new pad, is that you cannot specify the type of data (png ? jpg ? ...?) whereas you can with a pad/stream.
As long as the data format is agreed upon at the start, I don't really see a problem either way. A good ol' GdkPixbuf would do fine.
Obviously GdkPixbuf is no good, because that would mean relying on GdkPixbuf in the core. Using the same format as GdkPixbuf internally would be good enough.
Using a GdkPixbuf as content would mean a link/dependency on libgdkpixbuf for the tag stuff (for the GType when registering the tag) and for the tag reading element (for the decompression), which isn't a good idea IMHO. I'd just register the new tag to be of GST_TYPE_BUFFER and document it to contain a typefindable compressed image like png or jpeg or gif. Then the application can decide how/when it wants to handle the content, if at all. Typefinding PNG/JPEG/GIF should be easy in any case. Edward: creating a new pad in this case would mean it gets autoplugged and connected to a videosink, overriding visualisation plugins, wouldn't it? We can easily hack around that of course, but I think a tag would make things much easier for applications, don't you think?
The other problem with creating a new pad is that it will cause problems applications (such as Rhythmbox, and other music players) that say "it contains a video/image stream, I'm not interested". (In reply to comment #5) > I'd just register the new tag to be of GST_TYPE_BUFFER and document it to > contain a typefindable compressed image like png or jpeg or gif. Then the > application can decide how/when it wants to handle the content, if at all. > Typefinding PNG/JPEG/GIF should be easy in any case. That sounds reasonable to me. Any application that is actually using GDK can use GdkPixbufLoader fairly trivially to convert the data into a GdkPixbuf.
Does anyone have any sample files at hand by any chance? Also, I wonder what to do about the whole 'picture type' situation - does anyone know if that's used in practice? (I imagine '$11: a bright coloured fish' might be ...)
I don't have any handy, but EasyTag says it will create them and IIRC iTunes embeds cover art in MP3s using this. (In reply to comment #7) > Also, I wonder what to do about the whole 'picture type' situation - does > anyone know if that's used in practice? (I imagine '$11: a bright coloured > fish' might be ...) With the possible exception of the "file icon" type, I can't imagine that many applications pay attention to the type. If we did want the type attached to the tag, it would probably need to be turned into a string or something, since other formats may store images with different types. I'd be happy with just ignoring the picture type, or possibly having an additional IMAGE_PREVIEW tag for the "file icon" type (which could get used for other types that store previews too).
you could just set the caps on the buffer, no need to typefind...
Created attachment 65337 [details] [review] parse APIC frames, take #1 First tentative patch, requires core + base CVS for now (new releases coming up in the next few days). Open issues: - image URIs: should we create a new tag for that, which would mean we couldn't easily pass additional information like picture type etc.; or should we just let the app figure out that a mime type of text/uri-list means it's an URI? - add 'id3-picture-type' number to caps as plain G_TYPE_INT or do we need to create and use an enum type for that? (I doubt this picture type indicator is used very much)
(In reply to comment #10) > - add 'id3-picture-type' number to caps as plain G_TYPE_INT or do we > need to create and use an enum type for that? (I doubt this picture > type indicator is used very much) To me, the most interesting type is the "preview/file icon" type - not particularly for ID3 tags, but for other formats that embed previews. Having a format-neutral way of indicating those (whether something in the caps, or a GST_TAG_IMAGE_PREVIEW tag) would be useful for things like totem-video-thumbnailer.
2006-06-11 Tim-Philipp Müller <tim at centricular dot net> * gst/id3demux/id3v2frames.c: (id3demux_id3v2_parse_frame), (scan_encoded_string), (parse_picture_frame): Extract images from ID3v2 tags (APIC frames). Fixes #339704. * configure.ac: Require core >= 0.10.8 (for GST_TAG_IMAGE and GST_TAG_PPEVIEW_IMAGE used in the patch above). Leaving the picture type issue open for now (since I doubt it is used very much and I don't think this is worth blocking another -good release for, since we might need to add stuff to -base, so we'd need another -base release first). Opened bug #344605 for this.