Getting image buffer data from audio file tags.

[Nox Deleo]

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 zen.co.uk> 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:
> http://www.jezra.net/blog/use_python_and_gstreamer_to_get_the_tags_of_an_audio_file,
> 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 mapinfo.data and mapinfo.size). See
>
> https://bugzilla.gnome.org/show_bug.cgi?id=678663
>
> 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 lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121219/c5b3920e/attachment-0001.html>