I have found what the problem is and have verified a hack that gets around it. My rtsp media test source has 2 streams, one audio and one video. For some reason, the mpegtsmux_collected() is called *BEFORE* the newpad_created callback function in my code has been called for the second stream. The mpegtsmux_collected function will only try to create streams once, and at that time it creates a stream for all of the program IDs that it has recorded. It seems that since my code has only connected a single pad that the program ID map only has 1 entry. I have verified that the mux->collect->data list (?) only has a single entry in this situation. The mpegtsmux_create_streams function loops for all of the collect data objects (???) when it is called (walks the mux->collect->data list). For some reason, when gst-launch is used, both 'branches' are created before the mpegtsmux_collected() is called. My hack to prove this was to set the mux->first = TRUE in the mpegtsmux_request_new_pad() function because, if that function is called then we really do want to add a pad and the resulting program to the stream. Also, the mpegtsmux_create_streams function checks if a stream already exists in a mux and, if it does, simply throws a message and ignores the stream. This is a hack and the better question is why isn't my newpad_created function called earlier, as happens when this is run from gst-launch. That is a question that I can't yet answer, but would appreciate info from anyone who knows and understands the mpegtsmux code. I would like to mention that both tests used the same rtsp source and SDP and in both tests the rtspsrc element function gst_rtspsrc_create_stream() had been called for both streams very early in the processing.<br>
<br>TIA,<br>Chuck Crisler<br>