[gst-devel] Porting ASF demuxer to 0.9

[Tim Müller]

On Fri, 2005-10-21 at 15:19 -0400, Amit Bhalla wrote:

> set_caps() is being called once when the pad is created and once again
> before the buffer is pushed to the pad.  I took a look at a few other
> demuxers and noticed that gst_buffer_set_caps() is being on the buffer
> itself.  Is this necessary?  I tried it out and I am able to get a
> single frame pushed through to xvimagesink but not sure if this is the
> proper use of the api.

A demuxer like asfdemux usually sets fixed caps on its source pads when
it creates them. Those caps are given by the type of stream and aren't
negotiable, so they are fixed. So when you create the pad, you should
have something like for example

 GstPadTemplate *templ;
 GstPad *new_source_pad; 
 gchar *padname;

 padname = g_strdup_printf ("video_%02d", demuxer->num_video_streams);
 templ = gst_element_class_get_pad_template (klass, "video_%02d");
 caps = gst_caps_new_simple ("video/mpeg",
     "mpegversion", G_TYPE_INT, 4,
     NULL);
 new_source_pad = gst_pad_new_from_template (templ, padname);
 ... set up pad functions for queries, events etc. ...
 gst_pad_use_fixed_caps (pad);
 gst_pad_set_caps (pad, caps);
 ... 
 gst_element_add_pad (GST_ELEMENT (demuxer), pad);


> Secondly is it necessary to implement a setcaps() function for the plugin?

Not in this case. You don't need a setcaps() function on the sink pad,
because you only have one type of input, namely video/x-ms-asf, and you
don't need to extract any variable parameters from the input caps. If
you had this as caps on your sink pad: 'video/x-foo,fooversion=(int)
{ 1, 2, 4 }' then you would typically setup a setcaps() function in
order to extract the 'fooversion' parameter and configure the
parser/demuxer properly before receiving any data. asfdemux doesn't need
that though.

Similarly, you don't need to worry about the source pads here, because
they should all have fixed caps anyway.


> And lastly I am seeing a:
> 
> (gst-launch-0.9:28392): GStreamer-CRITICAL **:
> gst_structure_set_parent_refcount: assertion `refcount != NULL' failed
> 
> before a seg fault.  Is this related to improper handling of the
> GstBuffer via _ref and _unref functions?

No idea, I'll leave that to someone else.

It would probably be helpful to find out where that comes from though:

 % G_DEBUG=fatal_warnings gdb --args gst-launch-0.9 your ! pipeline
 ...
 (gdb) run
 ... wait for assertion ...
 Received signal SIGABRT at bla
 (gdb) bt
 ... should show you where that was triggered from ...
 (gdb) kill
 (gdb) quit

Cheers
 -Tim