Re: GStreamer access to raw audio data

[Zach Morgan <zpmorgan gmail com>]

Hi Torsten,

Thanks for fixing GStreamer::Buffer.

Can I ask here about the status of bug 620099? (
https://bugzilla.gnome.org/show_bug.cgi?id=620099 ) It's been
implicated as the cause of bug 668713. (
https://bugzilla.gnome.org/show_bug.cgi?id=668713 )

This bug is a little bit devastating for my purpose. The whole point
of PDL::GStreamer is to provide access to raw audio & video data, but
whenever I try pulling a buffer using either a pad signal or appsink's
pull_buffer method, the buffers seem to evaporate and destroy nearby
perl variables. I can only guess that it has something to do with both
threading and garbage collecting.

This branch of PDL::GStreamer pretty much highlights the problem
without using my GStreamer::AppSink module. Whenever I try running
examples/spectrogram.pl, it always crashes, sometimes in strange and
interesting ways. This is with perl 5.15; I haven't tried it with
another version.
https://github.com/zpmorgan/PDL-GStreamer/tree/uridecodebin

I've had much more success piping directly to & from gst-launch. This
solution may be a bit ugly, and it will become increasingly ugly, but
it has its advantages. It has to start a new process to seek in a
playing video, but that's not a major problem for me.
https://github.com/zpmorgan/PDL-GStreamer

Thanks,
Zach Morgan

On 2/18/12, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
> On 19.01.2012 14:01, Zach Morgan wrote:
> > I took your advice and cannibalized GStreamer::Interfaces to create
> > bindings for Appsink and Appsrc. I'm not clear on how you would make
> > it nice and perlish, so any criticism is welcome. Also, I've never
> > used xs or created bindings before. I didn't touch the set_callbacks
> > methods, and the GstAppStreamType enum, which isn't even tested,
> > probably could have been handled better.
>
> First of all: fantastic work!  That was really quick.  Comments:
>
> • For an example of how to handle callbacks, look into GstBus.xs.
>
> • Your gst_app_sink_pull_buffer_list wrapper lacks sv_2mortal() wrapped
> around newSVGstBuffer(), but otherwise it looks fine.
>
> • For gst_app_src_get_latency, you could use xsubpp's OUTLIST, like so:
>
>    void gst_app_src_get_latency (GstAppSrc *appsrc,
>                                  OUTLIST guint64 min,
>                                  OUTLIST guint64 max);
>
> But note that there are some unresolved issues on win32 that seem to
> involve OUTLIST.¹  So if you want to be on the safe side, you have to do
> it manually, as is done for gst_clock_add_observation, for example.
>
> ¹ Search for "Gtk2::TreeView get_path_at_pos doesn't return array on
> Windows".
>
> • Your handling of GstAppStreamType looks good.  Its mention in the
> "maps" file will trigger all the magic.
>
> > And a question: Will GStreamer buffers leak every bit of data that
> > they're set with? I don't see what this comment is referring to.
> > http://git.gnome.org/browse/perl-GStreamer/tree/xs/GstBuffer.xs#n100
>
> Indeed, they do leak everything.  I never used GStreamer::Buffer, so I
> never noticed.  This commit should fix it:
> <http://git.gnome.org/browse/perl-GStreamer/commit/?id=d26bd4e433133df222b75c7ebf5b50882a15d87e>.
>   Please test.
>
> > My GStreamer::App repo is at https://github.com/zpmorgan/GStreamer-App
>
> Next stop: CPAN!
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list