Hi,
On Wed, 14 Dec 2005, Andre Magalhaes wrote:
| | ---> 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.
yes, the approach taken in tapioca is definitely the way to go short-term.
The problem is how to ensure gapless playback even in strange cases like a
stream where encoding changes every 5 packets (i.e. not just once but
continuously).
Especially with the current architecture with jitter buffer in each
depayloader, you will always have to throw away some audio when switching
payload types.
When the codec-independent playout/jitter buffer is implemented (see my
earlier post), the situation improves already a lot: you don't have to
flush the jitter buffer if payload type changes. But you'll still have to
stop the pipeline, reconnect, and restart playing. This probably cause a
gap. One alternative is reconnecting on the fly... more about in the next
post.
Generally, this work item is a low priority item. For normal use, gapless
playback of this type of streams is not required.
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.
I guess the difference is that you don't have a generic
depayloader/decoder, but all the depayloader/decoder implementations are
gstreamer elements themselves and visible in the pipeline. But I guess
this is really the only way to do it in gstreamer.
--
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
