[gst-devel] GstPlay, data_src with more than one pad.

Martin Eikermann meiker at uni-paderborn.de
Fri May 16 15:34:10 CEST 2003


Hi,

I'm building an appliaction and use gstreamer, more precisely GstPlay, 
for it. The application is supposed to have an OnScreenDisplay (plugin 
under development), this works fine as long as I play from a source with 
one src-pad only (filesrc, udpsrc, ...). But for the OnScreen display I 
need to run the pipeline continuesly in order to be able to update the 
OSD-Image. So while not playing anything, I'd like to set the data_src 
in GstPlay to

  ( { videotestsrc pattern=2 ! queue } { silence ! queue } )

But using the above Bin (with ghostpads) won't work. After debugging a 
while I came to the following conclusions

1. gst_play_default_set_data_src() calls gst_element_link(data_src, 
spider) just once.
2. I tried to fix 1. by linking the data_src #pads times to the spider, 
but failed. Tough gst-inspect says spider.sink is a template. Can spider 
handle more than one incoming link? How can I fix GstPlay to do so.

<i-failed-with-this>
gst_play_default_set_data_src(...)
[...]
  while (srcpads) {
         dest_pad = gst_element_get_pad(play->autoplugger, "sink");
         dest_pad = (GstPad *) GST_PAD_REALIZE(dest_pad);
         dest_parent = gst_pad_get_parent(dest_pad);
         src_pad = (GstPad *) GST_PAD_REALIZE(srcpads->data);
         src_parent = gst_pad_get_parent(src_pad);
         GST_DEBUG(0, "GrepHelper- Linking Pad: %s:%s to %s:%s",
               GST_ELEMENT_NAME(src_parent),
               GST_PAD_NAME(src_pad),
               GST_ELEMENT_NAME(dest_parent),
               GST_PAD_NAME(dest_pad)
               );
         gst_element_link_pads (src_parent, GST_PAD_NAME(src_pad),
                    dest_parent, GST_PAD_NAME(dest_pad)
                    );
         srcpads = g_list_next(srcpads);
         printf("Number: %d\n", i++);
</i-failed-with-this>

3. coding around this issue by building a data_src equivalent to

     ( avimux name=mux { videotestsrc pattern=2 ! queue ! mux.video_00 } 
{ silence ! queue ! mux.audio_00} )

     will make the pipeline at least able to successfully change to the 
running state, but results in tons of "abnormal clock diff" warnings.



Can someone give me a hint on this.

Thanks
  Martin





More information about the gstreamer-devel mailing list