On 12/13/05, Kai Vehmanen <[EMAIL PROTECTED]> wrote:
> 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 --> | |
I don't understand the need of this mux element. I am doing exactly
what you said without the mux element. See tapioca_media.c
(tapioca_media_payload_type_change). I just link/unlink the audio sink
when the payload type changes. I tested this changing the encoded
stream and it works fine.
> 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.
Yes, This is exaclty what i am doing and am using gstreamer. I just
have a internal hash that handle this.
Please explain me why this is not enough!
BR
Andrunko
-------------------------------------------------------
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_idv37&alloc_id865&op=click
_______________________________________________
Farsight-devel mailing list
Farsight-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/farsight-devel
