Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED
Randell Jesup <randell-ietf@jesup.org> Sun, 01 July 2012 06:44 UTC
Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809D821F84BD for <rtcweb@ietfa.amsl.com>; Sat, 30 Jun 2012 23:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_BACKHAIR_56=1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5hpg+CN19wJ for <rtcweb@ietfa.amsl.com>; Sat, 30 Jun 2012 23:44:53 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D849221F84B9 for <rtcweb@ietf.org>; Sat, 30 Jun 2012 23:44:52 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SlDtt-00052w-DC for rtcweb@ietf.org; Sun, 01 Jul 2012 01:44:53 -0500
Message-ID: <4FEFF1B6.6050504@jesup.org>
Date: Sun, 01 Jul 2012 02:44:06 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <CAEdus3KnqLHyBRtCUfE03C4rdTJfyEDoZReEo60cnz_30GuBnw@mail.gmail.com>
In-Reply-To: <CAEdus3KnqLHyBRtCUfE03C4rdTJfyEDoZReEo60cnz_30GuBnw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jul 2012 06:44:53 -0000
On 6/29/2012 3:30 AM, Stefan Holmer wrote: > Doesn't this in the end boil down to what tools we have for baseline > resilience? Retransmissions are fairly easy to implement and will in > most cases give a much better experience than for example relying on > periodic key frames or doing key frame requests. Also it isn't necessary > for the decoder to support decoding streams with lost packets. "Better experience" incorporates a bunch of assumptions. Assuming we're talking video only: If you want it to be seamless, you have to be running a jitter buffer depth of at least 1 RTT plus time-to-decide-packet-may-be-lost plus random-constant. The second part of that can be tricky and network-state dependent. On corporate networks, I'd see sudden 100ms changes in base delay over 1-3 packets; a short time-to-decide would flag each of those as missing. This is ok (the re-xmit will get ignored as a dup), but adds packets at an apparent bad point for the network. That said, small RTTs certainly happen within LANs and corporations, and between neighbors in a single provider often. Note that often/normally with small RTTs you also get reasonably small jitter, and thus the adaptive jitter buffer might run very small numbers, so one might need to put a lower limit on the jitter buffer in these cases. The alternatives: 1) request re-xmit and freeze video queue when the jitter buffer runs dry. If the packet comes in ASAP, freeze <= RTT+constant (modulo application scheduling delay at the sender side). Then you can repair the broken frame, decode it, and then decode any following frames. Typically after a freeze you drop a frame or more; you might end up showing some of them depending on decode speed and how long the freeze lasted. If the re-xmit (or the request) is lost, then delays can stretch much longer, since you need to wait RTT+bigger constant before requesting again. In some conference apps even if the mixer just forwards video packets, the RTT is receiver<->mixer, not receiver<->mixer<->sender (this requires the mixer to buffer packets for possible retransmission). 2) request IDR (or refresh of corrupted slice). Downside here is that you need to wait for the next frame encode at the sender side (so 0-33ms normally, or perhaps 0-100ms), and then the frame typically takes many packets to send (which also may be lost, and take time to receive especially on low-BW links), and IDR initial quality may be noticeably lower. The receiver may freeze the video until the IDR is received or keep decoding with errors. If there's a significant chance of the IDR losing a packet, a freeze could be substantial time. 3) request repair. Note that #2 and #3 may be the same at the receiver side, with the sender deciding the best available repair. In this case, the sender would instead of an IDR use a some other set of (smaller) packets to create an error-free up-to-date state at the receiver, such as encoding using a long-term-reference-frame, or using some other known-error-free frame in the receiver. Note that repair is basically just a normal p-frame, albeit with somewhat lower quality and/or somewhat higher bandwidth used. A big plus is that the end state is close to the same as re-transmit, but you don't have to speed through decoding any skipped frames. Repair also allows the receiver to use alternate recovery mechanisms than simply freezing, including simply continuing to decode p-frames ignoring the lost frame. This induces artifacts, but keeps motion loss to a minimum, especially in longer-RTT links. Note that #3 in particular should result in similar freeze length as #1, perhaps 1 frame longer, if it freezes. If it plays with errors instead, the freeze is typically 1 frame (the lost one). (Others?) My normal preference is #3. But, as discussed above, in low-RTT networks it may be a good option and might give 0-frames of freeze. But, you still have all the complexities about how to decide when and how to use re-xmit; I think the 1 frame freeze is a reasonable option and a reasonable fallback if the source doesn't re-transmit. Also, if retransmit is REQUIRED, and the media is gatewayed to other sources (non-webrtc), and they don't support retransmit (likely), then the gateway would need to buffer and act as a retransmit agent (complicating the gateway). If it's RECOMMENDED, this is not a big deal and the gateway can stay simpler. -- Randell Jesup randell-ietf@jesup.org
- [rtcweb] RTP Usage: Is RTP Retransmission REQUIRE… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Fabio Pietrosanti (naif)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Bernard Aboba
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cameron Byrne
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Colin Perkins
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Fabio Pietrosanti (naif)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Fabio Pietrosanti (naif)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Colin Perkins
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cameron Byrne
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Colin Perkins
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Fabio Pietrosanti (naif)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cameron Byrne
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Fabio Pietrosanti (naif)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Michael Welzl
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cameron Byrne
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cullen Jennings
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Magnus Westerlund
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Stefan Holmer
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… John Leslie
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cullen Jennings
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Colin Perkins
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Cullen Jennings
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roy, Radhika R CIV (US)
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Randell Jesup
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Randell Jesup
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Stefan Holmer
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roni Even
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Randell Jesup
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Stefan Holmer
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Olle E. Johansson
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Justin Uberti
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Randell Jesup
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Olle E. Johansson
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Stefan Hakansson LK
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roman Shpount
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Olle E. Johansson
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Roman Shpount
- [rtcweb] 答复: RTP Usage: Is RTP Retransmission REQ… Lishitao
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Randell Jesup
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Martin Thomson
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Olle E. Johansson
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Martin Thomson
- Re: [rtcweb] RTP Usage: Is RTP Retransmission REQ… Stefan Hakansson LK
- [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? Harald Alvestrand
- Re: [rtcweb] LTE using AM_RLC or UM_RLC mode for … Göran Eriksson AP
- Re: [rtcweb] LTE using AM_RLC or UM_RLC mode for … Cameron Byrne