Getting image buffer data from audio file tags.

Tim-Philipp Müller t.i.m at
Wed Dec 19 05:01:18 PST 2012

On Wed, 2012-12-19 at 12:46 +0000, Nox Deleo wrote:


> 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)?

No, there is no easy way to get to the data at all at the moment, copy
or not.

I'll add a function for that.

>  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 :).

Note that in 1.x it's push_sample / push-sample, you have to create a
GstSample with the buffer, you can't just push the buffer directly.


> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at

More information about the gstreamer-devel mailing list