what caps to use when dynamically linking rtspsrc src pad?

[Chuck Crisler]

I am trying to build a pipeline that works with an RTSP server. I have a
complete example working with gst-launch and have logs. It doesn't work
with my C++ app. :-( The sample RTSP source that I am using has both audio
and video. My goal is to receive the RTSP/RTP streams and mux them into a
single MP2T (yuck) stream and send them to another system. As a point of
reference, here is my gst-launch pipeline that works well. I am using
gstreamer v. 0.10.30

#!/bin/sh
#export GST_DEBUG=rtspsrc:4,mpegtsmux:4,rtph264depay:4,rtpmp4gdepay:4
gst-launch -v rtspsrc location=rtsp://192.168.12.66:/somefile.sdp name=src \
    src. ! queue ! rtph264depay ! mux. \
    src. ! queue ! rtpmp4gdepay ! mux. \
    mpegtsmux name=mux ! udpsink host=$1 port=$2

My C++ code starts off well but has a problem with the second RTP stream. I
create the rtspsrc element plus an mpegtsmux and udpsink and add them to
the pipeline, only linking the mpegtsmux to the udpsink. In the newpadadded
callback function, I create a queue and a depayloader based on the caps,
add them to the pipeline, link them in and sync the state with the parent.
All of that works. In my recent testing the video RTP stream was processed
first (just luck) and the rtph264depay and mpegtsmux elements logged a lot
of messages, suggesting they were processing packets. However, shortly
after linking in the audio the muxer returns an error 10 - Stream is not
associated with any program. Specifically, here are the messages.

mpegtsmux mpegtsmux.c:395:mpegtsmux_create_stream:<RTSPMP2TMux:sink_64>
[00m Creating H264 stream with PID 0x0040
...
mpegtsmux mpegtsmux.c:654:mpegtsmux_collected:<RTSPMP2TMux> [00m Pads
collected
mpegtsmux mpegtsmux.c:610:mpegtsmux_choose_best_stream:<RTSPMP2TMux> [00m
Pulled buffer with ts 0:00:00.080980597 (uncorrected ts 0:00:00.080980597
80980597) for PID 0x0040
mpegtsmux mpegtsmux.c:681:mpegtsmux_collected:<RTSPMP2TMux> [00m error:
Stream is not associated with any program

There isn't a corresponding creation message for PID 0x0041, though there
is one earlier message:
mpegtsmux mpegtsmux.c:610:mpegtsmux_choose_best_stream:<RTSPMP2TMux> [00m
Pulled buffer with ts 0:00:00.051079480 (uncorrected ts 0:00:00.051079480
51079480) for PID 0x0041

which I assume would correspond to the audio channel. That is the only log
message that contains 0x0041. So it seems like it didn't create the audio
stream which makes sense given the error. However, I didn't see any
messages from the mpegtsmux about failing to create any streams.

I have tried using the caps of the newly created rtspsrc pad passed into my
function. That linked but led to this error. I tried creating my own caps
("video/x-h264" and "audio/mpeg", "mpegversion", G_TYPE_INT, 4, NULL) but
that didn't even link. I thought that the caps that I created agreed with
the results from gst-inspect mpegtsmux:

      video/x-h264
      audio/mpeg
            mpegversion: { 1, 2, 4 }

What caps should I be using? I know that this needs to be dynamic because
in production I don't know what CODEC types will be contained in the
streams.

The documentation states that rtspsrc internally creates an rtpbin. If so,
why do I need (or even do I need) to create the rtp jitterbuffer/depay
elements? Couldn't I simply link to the rtspsrc created rtpbin(s)? But if I
took those elements out of my pipeline, how would the branches be
distinguished?

Thank you,
Chuck Crisler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130219/b34c4ebb/attachment-0001.html>