Hey,
Ok I am really confused by this element :) You talk about an RTPMUX
element. You say :
"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.
| | ---> DEPAYLOADER --> DECODER --> | |
RTPBIN -> | RTPDEMUX | ---> DEPAYLOADER --> DECODER --> | MUX | --> SINK
| | ---> DEPAYLOADER --> DECODER --> | |
The MUXER element is what you are talking about. Is this correct?
Hrmm..
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...
Laterz,
Burger
On Tue, 13 Dec 2005 19:55:45 +0200 (EET)
Kai Vehmanen <[EMAIL PROTECTED]> wrote:
> And more...
>
> Gapless playback of streams with mixed payload types (prio:medium;v1)
> ---------------------------------------------------------------------
>
> To further improve the 'Codec independent playout buffer element',
> it should be possible to depayload and decode streams
> with packets with mixed payload types (TS=x/codecA, TS=x+ptime/codecB),
> without audible pauses in the stream.
>
> The current rtpdemux element (part of gst-plugins-farsight) is
> able to demux the different payload types, and push the packets
> to different src pads.
>
> A new work item is to develop an element that is able to
> gather buffers from multiple decoder paths, and push forward
> a continuous media stream to the sink. Although packets might
> traverse different depayloader+decoder chains, the timestamp ranges
> will not overlap. Thus the "rtpmux" element must assemble
> a continuous stream from discontinuous segments created by the
> decoders.
>
> Rationale:
> - Mixing payload types in a single logical stream
> is valid use of RTP, and used by some clients.
>
> --
> 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
-------------------------------------------------------
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
