Getting image buffer data from audio file tags.

Nox Deleo noxdeleo at
Wed Dec 19 04:46:25 PST 2012

Thanks for the reply. I got the gist of the bug report, but am a little
confused on finer details. Is it saying that for now (without any patches),
I would be able to get a copy of the byte array from mapinfo to work with
in Python? I only need to read the data, after which I'll store it
elsewhere (GstDiscoverer info -> MongoDB and GridFS for the cover art if I
can get it). If so, are there any reasons not to (like ending up with alot
of these just sat in memory)? I already tried the serialize to string
approach (ugh is right, but I was desperate), but it ended up causing
segfaults down the line when pushed into GObject attributes on Clutter/Mx
components. I stopped there with that approach since it was horrible
anyway. As for the appsrc, I was doing an emit('push-buffer', buffer) on
it, since I wasn't even aware of the other approach. If I end up having to
use that, I'll have a read up on using appsrc first since the segfault is
probably my fault anyway. I think Ubuntu 12.10 is still sat on GStreamer
1.0.1, so I probably need to use the GStreamer PPA or stop being lazy and
compile the source :).

Thanks again.

On 18 December 2012 23:15, Tim-Philipp Müller <t.i.m at> wrote:

> On Tue, 2012-12-18 at 18:53 +0000, Nox Deleo wrote:
> Hi,
> > I'm trying to pull the image tag data from an audio file. I can pull a
> > GstSample from the TagList, and a GstBuffer from that, but I don't
> > know how to get the data out of that into something I can use in
> > Python. I found an example (in the comments)
> > here:
> but I'm guessing it's for an older version of GStreamer since GstBuffer
> doesn't seem to have a 'data' attribute in GStreamer 1.0.
> Yes, that's currently a bit of a problem, due to some missing bits in
> gobject-introspection, which doesn't allow bindings to access byte
> arrays in structures (you would get at the data in C by 'mapping' the
> buffer and then accessing and mapinfo.size). See
> for the whole story.
> It looks like we'll have to add a utility function to get the data from
> bindings until this is fixed on the g-i/bindings side. Someone remind me
> if I forget.
> I don't know if there's a clever way to get at the data some other way,
> other than what you're trying to do, or serialising it to a strings and
> parsing the hex values. (ugh)
> > I tried briefly to push the buffer into an appsrc->encoder->filesink
> > pipeline, but this segfaulted on me (I haven't read up on using
> > appsrc, so that's no surprise, but I'm hoping there's an easier way of
> > doing this).
> Sounds like you might be running into an annotation/bindings bug we've
> just fixed in the 1.0.4 release that's just come out (should hopefully
> land in your distro soon). A workaround for that was to not use the
> explicit push_sample API on appsrc, but pass the sample with the buffer
> using the signal_emit_by_name API (not sure about exact py-gi syntax).
> Cheers
>  -Tim
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list