[gst-devel] Using the gstrtpbin plugin to be able to receive streams with different payloads

[Antoni Silvestre Padrós]

Hi, I've been trying hard to use the gstrtpbin plugin to be able to receive
streams with different payloads at different times.

My objective is be able to comply with the RFC 3264 when it says that when
sending an SDP, the offerer should be ready to receive any of the stream
formats offered.

So, for instance I'd need a pipeline that is ready to receive H264 or
H263-1998 (obviously one of them only not both at the same time), and I
thought a pipeline like the following would do the job:

gstrtpbin name=rtpbin \
    udpsrc port=5000 ! queue ! rtpbin.recv_rtp_sink_0 \
    rtpbin. ! queue ! rtph263pdepay name=rtph263 ! ffdec_h263 ! xvimagesink
sync=false \
     rtpbin. ! queue ! rtph264depay name=rtph264 ! ffdec_h264 ! xvimagesink
\
    udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
     rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5005 sync=false
async=false

Then I capture the signal request-pt-map, where according to the pt-number I
set the caps for the incoming stream.

Well I found that if I don't send all of the formats I described in the
pipeline the pipeline reproduces one frame and stops.

I also tried a pipeline like the following:

gstrtpbin name=rtpbin \
    rtph264depay name=rtph264 ! ffdec_h264 ! xvimagesink \
    rtph263pdepay name=rtph263 ! ffdec_h263 ! xvimagesink sync=false \
     udpsrc port=5000 ! queue ! rtpbin.recv_rtp_sink_0 \
    udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
     rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5005 sync=false
async=false

As you can see the codec dependent part is not connected anywhere, here I
also capture the payload-type-change which is called after the creation of
the corresponding src pad in the rtpbin after setting the caps for the
corresponding incoming stream. In this signal I succesfully connect the
corresponding element to the gstrtpbin. Again if the plugin is not receiving
all the streams it plays one frame and stops...

Also, I tried using the output-selector plugin like these with similar
results:

gstrtpbin name=rtpbin \
    output-selector name=video \
            video. ! rtph264depay name=rtph264 ! ffdec_h264 ! xvimagesink \
    video. ! rtph263pdepay name=rtph263 ! ffdec_h263 ! xvimagesink
sync=false \
     udpsrc port=5000 ! queue ! rtpbin.recv_rtp_sink_0 \
    udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
     rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5005 sync=false
async=false

Finally I tried to create the codec dependent parts of the pipeline in
different bins like this:

 _h263pbin = gst_parse_bin_from_description_full("bin. ( rtph263pdepay
name=rtph263 ! ffdec_h263 ! xvimagesink sync=false )", TRUE, context, 0,
&e);

 _h264bin = gst_parse_bin_from_description_full("bin. ( rtph264depay
name=rtph264 ! ffdec_h264 ! xvimagesink )", TRUE, context, 0, &e);

 pipeline = gst_parse_launch_full("gstrtpbin name=rtpbin \
    udpsrc port=5000 ! queue ! rtpbin.recv_rtp_sink_0 \
     udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
    rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5005 sync=false
async=false \
     ", context, 0, &e);


Then I add the corresponding codec bin to the main bin accordingly, and now
even though I generate a pipeline without references to any other codec
again it plays one frame and complains saying: Unhandled state change from
VOID_PENDING to PLAYING

Well I don't know what else to do... any help would really appreciated. My
main problem is that even though I've read all that I found about blocking
in Gstreamer I don't fully get it, for instance I don't understand why in
the first tests I describe here the pipeline dependent part that is not
linked to the rest of the pipeline can block the whole pipeline.

Also if someone can point me real examples of gstreamer applications that
change their pipeline structure while being on the playing state would be
really useful.

Thanks,

Antoni Silvestre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100824/a6c8c1f9/attachment.htm>