On Tue, 13 Dec 2005 [EMAIL PROTECTED] wrote:
"Thus the "rtpmux" element must assemble a continuous stream from
discontinuous segments created by the decoders."
[...]
But, once a stream comes out of the decoders, it is not an RTP stream
anymore, it's either a raw audio or video stream. I don't really
understand what this element is suppose to do. Logically, this element
would actually take a bunch of independently decoded streams, that came
from the same RTP stream, and put them back together and send them to
for example the audio sink. In that case, the element should not be
called an RTPMUX element, just a normal audio muxer.
Yes, the word "rtpmux" was badly chosen - the element should be a
enchanded "adder" or some such.
The main difference is that a single RTP stream (aka one RTP session, aka
one timestamp space) does not contain multiple independent streams, but
just one logical stream. The catch is that some chunks/segments/whatever
of the stream could be encoded with a different codec than others. So
you'd get:
(srate=8000, ptime=20msec, ts incremented by 160 by each packet)
ts: 0 160 320 480 ...
rtp-pt: ILBC ILBC G711 ILBC ...
| | ---> DEPAYLOADER --> DECODER --> | |
RTPBIN -> | RTPDEMUX | ---> DEPAYLOADER --> DECODER --> | MUX | --> SINK
| | ---> DEPAYLOADER --> DECODER --> | |
Now when the above example stream goes through our rtpbin
receive elements, packets for ts={0,160,480} go through depayload+decoder
subchain for ILBC, and packet with ts=320 trhough a different
depayload+decoder pair. The mux element won't get a constant
stream of audio from all the subchains, but has to assemble the
pieces together.
Now I've asked about this, read gst sources, and my conclusion is that the
current elements can't handle the above case (function as the "mux"
element above). But I'd be of course extremely please to be proven wrong
here.
Now this reminds me why I didn't want to put the depayloader INSIDE
RTPRECV -> Because there can be several payloads inside the same RTP
Stream. I guess we need to talk some more about this...
Yeps, that's a complication. In a non-gstreamer world, you could have a
hash table of depayload and decoder plugins, indexed by RTP-PT. A
generic depayloader/decoder element would just check the payload type, and
handle the data with the correct plugin. With gst, we'll need to do the
same in a bit different manner.
--
under work: Sofia-SIP at http://sofia-sip.sf.net
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Farsight-devel mailing list
Farsight-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/farsight-devel
