<div dir="ltr">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 :).<div>
<br></div><div style>Thanks again.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 December 2012 23:15, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2012-12-18 at 18:53 +0000, Nox Deleo wrote:<br>
<br>
Hi,<br>
<div class="im"><br>
> I'm trying to pull the image tag data from an audio file. I can pull a<br>
> GstSample from the TagList, and a GstBuffer from that, but I don't<br>
> know how to get the data out of that into something I can use in<br>
> Python. I found an example (in the comments)<br>
> here: <a href="http://www.jezra.net/blog/use_python_and_gstreamer_to_get_the_tags_of_an_audio_file" target="_blank">http://www.jezra.net/blog/use_python_and_gstreamer_to_get_the_tags_of_an_audio_file</a>, 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.<br>
<br>
</div>Yes, that's currently a bit of a problem, due to some missing bits in<br>
gobject-introspection, which doesn't allow bindings to access byte<br>
arrays in structures (you would get at the data in C by 'mapping' the<br>
buffer and then accessing mapinfo.data and mapinfo.size). See<br>
<br>
<a href="https://bugzilla.gnome.org/show_bug.cgi?id=678663" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=678663</a><br>
<br>
for the whole story.<br>
<br>
It looks like we'll have to add a utility function to get the data from<br>
bindings until this is fixed on the g-i/bindings side. Someone remind me<br>
if I forget.<br>
<br>
I don't know if there's a clever way to get at the data some other way,<br>
other than what you're trying to do, or serialising it to a strings and<br>
parsing the hex values. (ugh)<br>
<div class="im"><br>
<br>
> I tried briefly to push the buffer into an appsrc->encoder->filesink<br>
> pipeline, but this segfaulted on me (I haven't read up on using<br>
> appsrc, so that's no surprise, but I'm hoping there's an easier way of<br>
</div>> doing this).<br>
<br>
Sounds like you might be running into an annotation/bindings bug we've<br>
just fixed in the 1.0.4 release that's just come out (should hopefully<br>
land in your distro soon). A workaround for that was to not use the<br>
explicit push_sample API on appsrc, but pass the sample with the buffer<br>
using the signal_emit_by_name API (not sure about exact py-gi syntax).<br>
<br>
Cheers<br>
-Tim<br>
<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>