rtspsrc problem - I know what is happening, not why

[Chuck Crisler]

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.

TIA,
Chuck Crisler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130221/32f3261a/attachment.html>