Getting image buffer data from audio file tags.
Locked
 
|
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.
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Getting image buffer data from audio file tags.
|
|
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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
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 <[hidden email]> wrote: On Tue, 2012-12-18 at 18:53 +0000, Nox Deleo wrote: _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Getting image buffer data from audio file tags.
|
|
On Wed, 2012-12-19 at 12:46 +0000, Nox Deleo wrote:
Hi, > 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. Cheers -Tim > Thanks again. > > > On 18 December 2012 23:15, Tim-Philipp Müller <[hidden email]> 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 > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Ok, thanks for the clarification. I've just been reading up on appsrc, but I can't find any reference to a "push-sample"...every documentation source I can find (appsrc plugin docs, appsrc docs in base plugins library reference, and tutorials at gstreamer.com) say "push-buffer", and push sample gives me "unknown signal name: push-sample". Is this a mistake or am I missing something?
On 19 December 2012 13:01, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Getting image buffer data from audio file tags.
|
|
On Wed, 2012-12-19 at 15:25 +0000, Nox Deleo wrote:
> Ok, thanks for the clarification. I've just been reading up on appsrc, > but I can't find any reference to a "push-sample"...every > documentation source I can find (appsrc plugin docs, appsrc docs in > base plugins library reference, and tutorials at gstreamer.com) say > "push-buffer", and push sample gives me "unknown signal name: > push-sample". Is this a mistake or am I missing something? "push-buffer" is GStreamer 0.10 API, "push-sample" is the equivalent GStreamer 1.0 API (since in 1.0 you can't attach caps to buffers any more, so we needed a helper struct to pass caps alongside a buffer). GStreamer 0.10 is not maintained any longer. The gstreamer.com website is not maintained by the GStreamer project. The official GStreamer website and documentation lives on http://gstreamer.freedesktop.org . Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Sorry if I'm just being dense here, but the docs package I downloaded says it's for GStreamer 1.0, and the headings on the following two pages say the same: I'm also explicitly asking for GStreamer 1.0 when I load Gst introspection modules in python, and that's also telling me push_buffer: >>> import gi
>>> gi.require_version('GstApp', '1.0') >>> from gi.repository import GstApp >>> print(dir(GstApp.AppSrc)) ...'props', 'provide_clock', 'push_buffer', 'query', 'query_convert'...
Very confusing. On 19 December 2012 15:33, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Getting image buffer data from audio file tags.
|
|
In reply to this post by Nox Deleo
On 12/19/2012 04:25 PM, Nox Deleo wrote:
> Ok, thanks for the clarification. I've just been reading up on appsrc, > but I can't find any reference to a "push-sample"...every > documentation source I can find (appsrc plugin docs, appsrc docs in > base plugins library reference, and tutorials at gstreamer.com > <http://gstreamer.com>) say "push-buffer", and push sample gives me > "unknown signal name: push-sample". Is this a mistake or am I missing > something? > Use push-buffer in appsrc, both in 0.10 and 1.0. Wim > > On 19 December 2012 13:01, Tim-Philipp Müller <[hidden email] > <mailto:[hidden email]>> wrote: > > On Wed, 2012-12-19 at 12:46 +0000, Nox Deleo wrote: > > Hi, > > > 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. > > Cheers > -Tim > > > Thanks again. > > > > > > On 18 December 2012 23:15, Tim-Philipp Müller <[hidden email] > <mailto:[hidden email]>> 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 > > [hidden email] > <mailto:[hidden email]> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > <mailto:[hidden email]> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Getting image buffer data from audio file tags.
|
|
In reply to this post by Nox Deleo
On Wed, 2012-12-19 at 15:52 +0000, Nox Deleo wrote:
> Sorry if I'm just being dense here, but the docs package I downloaded > says it's for GStreamer 1.0, and the headings on the following two > pages say the same: > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsrc.html > > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-appsrc.html > > I'm also explicitly asking for GStreamer 1.0 when I load Gst > introspection modules in python, and that's also telling me > push_buffer: > >>> import gi > >>> gi.require_version('GstApp', '1.0') > >>> from gi.repository import GstApp > >>> print(dir(GstApp.AppSrc)) > ...'props', 'provide_clock', 'push_buffer', 'query', > 'query_convert'... > Very confusing. Sorry, you're entirely right. It's me who was confused. It is indeed push-buffer for appsrc. appsink was changed from buffer to sample, I just assumed the same was done for appsrc as well, but seems not (and it's not really needed since you can set the caps via the property upfront anyway). Apologies for the confusion :) Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
No worries, and thanks for the help. On 19 December 2012 16:03, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
I feel like I'm very close now. I've set up a random access appsrc, and connected it to a pngenc followed by a filesink. I've set the appsrc's "size" property to the size of the album cover's image buffer, and when the "need-data" signal is fired, I'm pushing the entire buffer. I've also set the appsrc's "caps" property to the caps of the original album cover (sample.get_caps() from the image tag). In addition to a "could not send sticky events" warning, I'm also getting a "streaming task paused, reason not-negotiated". Also, it doesn't seem to like my use of "disconnect" for the "need-data" signal. It contradicts the GObject docs saying it's expecting an integer rather than a string. I've never done anything with pushing buffers around manually, so I'm a little out of my depth here. Here my slightly messy source (also probably full of bad practices): Thanks.
On 19 December 2012 16:28, Nox Deleo <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |