[Live-devel] Slow connection problem with RTP over RTSP/TCP

[Jeremy Noring]

On Thu, Nov 19, 2009 at 2:31 AM, Ross Finlayson <finlayson at live555.com>wrote:

> And if the server can detect that the network is to slow or congested to
>> send all of the requested data (by detecting that the network buffers in the
>> OS are full) make an attempt to intelligently send enough data to provide a
>> working, all be it degraded, experience to the client rather than just
>> randomly dropping parts of frames so that nothing may work.
>>
>
> Yes, at some point it would be nice to support the IETF's RTP/AVPF profile,
> and an associated feedback-based retransmission (and/or media rescaling)
> scheme.  But this, of course, is on top of UDP. Trying to implement a
> loss-mitigation scheme over TCP is retarded.


I agree.

Furthermore, basically the patch implements a "retransmit" on the RTP stack
level, which is wholly incompatible with any RTP specification I know of.
RTP uses application level framing, which means some of the behaviors are
specifically not defined, and should be implemented by the application
level.  If my video stream is live, "retransmitting" is likely a waste of
time because the data is already obsolete.  And mostly likely I can only
start a stream on keyframe boundaries, so retransmitting some intermediate
frame is also a waste of time if there's already been previous loss. (hence
"application level framing"--only the calling application knows what sort of
loss mitigation plan it should implement)

Question: does Live555 provide a feedback mechanisms for loss, jitter, etc.
(basically some way of getting the RTCP stats) so I can tweak the encoder in
real-time to fit network conditions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091119/f50a74d0/attachment.html>