Hello,
a slightly updated version of this is available at:
http://projects.collabora.co.uk/farsight/ticket/5
There was some talk about the relation of this to tickets #1
(pull-based consumption) and #3 (continuous clock-drift compensation).
Now these are definitely related - #1 and #3 are long-term
items for improving the playout buffer. But before that, we should have
basic a RTP implementation that can handle drift (not continuously
compensating, but restarting the reception if we go completely out of
sync).
And this detection part is at the core of #5. I'm open to better
alternatives, but one solution is:
- measure the time elapsed since start of the stream
based on timestamps in the incoming packets
- measure time elapsed since start of the stream
measured by pipeline clock
- if the two drift too much, restart (i.e. do the same
steps you do for the very first RTP packet; reinitialize
the gst-timestamp<->rtp-timestamp mapping, send NEWSEGMENT,
maybe something else to make sure alsasink/etc will forget
the past and start from scratch, and then continue scheduling
packets out as usual)
To me, this is at least much easier task than implementing for example
#3. Anyways, _something_ has to be done, because there will _always_ be
drift (see my reasoning for #3) and currently we are not doing anything
about it.
Alternatives (other than #1 and #3):
- implement a "overrun/underrun" event that can be sent
upstream by alsasink (and other sinks) to notify that is
has got too much data (buffer overrun), or has run out
of data (underrun); .... maybe use the QoS framework (already
has initial stuff to report about buffering-%)
- ... anyone?
And then quickly about how #1 and #3 do their magic:
- #1 (pull-based): if sink pulls data, and you don't have
any, or you have it too much, you know you've drifted apart
- #3 (continuous clock-compensation): the sink consumption
rate is adjusted to match the incoming rate - nice for
the RTP code, not so nice for the poor sink
Then a whole different discussion is how to do the rate adaptation without
user knowing about it: restart (user will notice), resampling (sounds
good, but cpu-heavy), periodic adding/dropping of audio frames (less
cpu-heavy than resampling, definitely better than restart, but not that
easy to implement right -> you should do adding/removing between
talkspurts). But until we solve the detection problem first, and have at
least the "restart" solution done, ... these are just nice topics for
academic discussion. ;)
On Mon, 12 Dec 2005, Kai Vehmanen wrote:
Hello all,
based on last week's discussions on #farsight, I've written down some
improvement items for the gst RTP support. Here's the first one. The items
are divided into urgent items (something we must have), and more long-term
stuff (which would be nice to have already now, but without which one can
still build VoIP/conferencing apps).
For background, see:
http://gstreamer.freedesktop.org/documentation/rtp.html
http://bugzilla.gnome.org/show_bug.cgi?id=323017
Please comment either on the list, or IRC (I'll comment and summarize the
feedback).
Codec independent playout buffer element (prio:urgent)
------------------------------------------------------
A gstreamer element that takes in application/x-rtp buffers and stores
them in a playout (jitter) buffer. The buffer will contain the packets
sorted by RTP-timestamp and RTP-seqno, with duplicates removed. This
is essentially the functionality that is not provided by
gst-plugins-base-0.10/gst-libs/gst/rtp/gstbasertpdepayload.c
The element will have a separate thread that schedules out packets for
playout at the pipeline sink. The element will monitor the frequency of
incoming packets, and use this information to select a proper sleep
interval.
The element should be able to detect overrun and underrun situations
caused by clock-drift between the sender and the receiver (sink in
the pipeline the playout buffer is part)
Rationale:
- Separate element is used instead of gstbasertpdepayload.c
because the codec might change mid-stream and so the
playout buffer should be able to contain packets
for multiple codecs at the same time.
- A separate thread is needed to ensure packets are
scheduled even in the case no packets are
received from the network (pause of X msecs is fatal if X
is larger than the size of sink element buffers).
--
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
