g_signal_connect question

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

g_signal_connect question

wanting2learn

I am woking on a gstreamer project and have a problem.

I have pipeline set up and I have used the following to monitor the data
passing through it:

static void onVideoHandoff( GstElement *object, GstBuffer *buffer, gpointer
user_data )
{
    //blah..blah
}

GstElement *identity = gst_element_factory_make("identity", "identity");
g_signal_connect( identity, "handoff", G_CALLBACK(onVideoHandoff), this);

The problem I'm having is that in my onVideoHandoff(..) function when I get
the size of the 'buffer' (thisPacketSize = GST_BUFFER_SIZE(buffer);)  it is
always the same size no matter what type of video frame is going through the
pipeline. (I would expect it to be smaller for delta frames etc but its
always about 2MB).

I'm thinking that this is because the onVideoHandoff function is called
after the video has been decoded and that the buffer size is always the same
as it is about to be writen on screen.

is this correct??

I think I need to monitor the data when it is going through my decoder
element.

My decoder element is set up like so depending in the type needed:
decoder = gst_element_factory_make("ffdec_mjpeg", "decoder"); OR
decoder = gst_element_factory_make("ffdec_mpeg4", "decoder"); OR
decoder = gst_element_factory_make("ffdec_h264", "decoder"); OR

I'm trying to attach an identity element like above but whatever I have
tried has failed.  I have tried the following:
g_signal_connect (decoder, "new-decoded-pad", G_CALLBACK (cb_newpad),
NULL);....
g_signal_connect( decoder, "handoff", G_CALLBACK(cb_handoff), this)

etc but I do not really know the proper way to do this. (the footprint of
the callback function etc)

Can anyone help me??


--
View this message in context: http://n4.nabble.com/g-signal-connect-question-tp1567811p1567811.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: g_signal_connect question

michael smith-6-3
On Wed, Feb 24, 2010 at 9:52 AM, wanting2learn
<[hidden email]> wrote:

>
> I am woking on a gstreamer project and have a problem.
>
> I have pipeline set up and I have used the following to monitor the data
> passing through it:
>
> static void onVideoHandoff( GstElement *object, GstBuffer *buffer, gpointer
> user_data )
> {
>    //blah..blah
> }
>
> GstElement *identity = gst_element_factory_make("identity", "identity");
> g_signal_connect( identity, "handoff", G_CALLBACK(onVideoHandoff), this);
>
> The problem I'm having is that in my onVideoHandoff(..) function when I get
> the size of the 'buffer' (thisPacketSize = GST_BUFFER_SIZE(buffer);)  it is
> always the same size no matter what type of video frame is going through the
> pipeline. (I would expect it to be smaller for delta frames etc but its
> always about 2MB).

Most likely you put your identity element after your decoder - so
you're looking at decoded video frames, which are (for a given
height/width/format) obviously fixed size. You didn't tell us anything
about your pipeline, so there's no way for us to know - but this
sounds like a plausible guess.


>
> I'm thinking that this is because the onVideoHandoff function is called
> after the video has been decoded and that the buffer size is always the same
> as it is about to be writen on screen.
>
> is this correct??
>
> I think I need to monitor the data when it is going through my decoder
> element.

Well, if you want to look at things before the decoder, you could just
put your identity element before the decoder.

You can also use pad probes for this - see the documentation for details.

>
> My decoder element is set up like so depending in the type needed:
> decoder = gst_element_factory_make("ffdec_mjpeg", "decoder"); OR
> decoder = gst_element_factory_make("ffdec_mpeg4", "decoder"); OR
> decoder = gst_element_factory_make("ffdec_h264", "decoder"); OR
>
> I'm trying to attach an identity element like above but whatever I have
> tried has failed.  I have tried the following:
> g_signal_connect (decoder, "new-decoded-pad", G_CALLBACK (cb_newpad),
> NULL);....
> g_signal_connect( decoder, "handoff", G_CALLBACK(cb_handoff), this)
>
> etc but I do not really know the proper way to do this. (the footprint of
> the callback function etc)

Decoders won't normally have a handoff or new-decoded-pad signal; if
you run "gst-inspect ffdec_h264" (or other decoders) it'll tell you
what signals it has.

You should probably just use a pad probe.

Mike

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel