Re: [Sframe] Partial decodability and IDUs

Bernard Aboba <> Sun, 22 November 2020 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D71C3A0F47 for <>; Sun, 22 Nov 2020 15:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nAt4rBEF39zI for <>; Sun, 22 Nov 2020 15:10:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8BC93A0F46 for <>; Sun, 22 Nov 2020 15:10:55 -0800 (PST)
Received: by with SMTP id l11so7934098plt.1 for <>; Sun, 22 Nov 2020 15:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=USIaPKUfjOM7rj/NV+H4RK3NePTxwUpHwxHMZ+U0sA4=; b=uEfX4LII0r6uef4EPWcBCAvAw4COpUXIPY0x0dbaPHEHMtgb+YLl+2XByBaIlye65B HXJIVBSw2+QzRP0Ti5uRIJS56ItS8xgQ1ThaF+R5vnD6Av/EmyuZ6RucBF2YhDe8jQX9 VViGXIy28yuR/1ekbk32YllAOy2sKicPRrQ8FvUHKmIvp4BPBN2Cx3FVCbzh99M7g4Mu HGdZihN+BUUwLMnT3Hti9g+P9L10j2SBoS185ouIAp+rolnH6Ziy/hMZNVCgyIhXBrUl Hgv/5MEJ7pOT3tQ1iWD3tc794q9CPElRFo40GEncX8D8qnqF5xAzKhAPp5yX412B+6AZ sV6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=USIaPKUfjOM7rj/NV+H4RK3NePTxwUpHwxHMZ+U0sA4=; b=BljzrDv5WpQfPadV0sxrmktrbmJYyV+4u2Y5wvplTmtcX1TtJWl5328KqJAR3y5DvS 7vn1Yz+FLDCHFsL2O7R5YYOTE3g8VDNHSA4QHpIy/peQfu6lJEP3o34PwasfqTV5QUPs 1jahtDt7QzmPI7EzfA/Mjd1wbAgNIcDsKmhgnjtFTMcnoDiPZ1mt1ldFDXZ9SQG68hBm D3r+FSWmJwD4ZUO7rUZQZx+AU8NPDK7t9isUmA5V1Jv7wuwHGkigmUfwmnr8als8PnRS oZMakDXBcjN+JsyHZOhYDzNIbJyGNdtbJnqYZIMtQve9KXmOAH/GOu5mhGKCEBHM98a7 Rqjg==
X-Gm-Message-State: AOAM530kWqu/7ZbtdY+zpE01QLkPT7jA0gzrVujoqZdZiLxhwTkHyRex ya+mMaf4J23g11VvvSHBFTJ5sEXzfx1OAw==
X-Google-Smtp-Source: ABdhPJzqmLzKm3KkBWU8FMntJZC7pMFpHyHaSi/XZDpItC3mAAmeyX2Eu69NwqTkDnB735XsYrsnJw==
X-Received: by 2002:a17:902:e787:b029:d9:f88d:c32d with SMTP id cp7-20020a170902e787b02900d9f88dc32dmr5858639plb.79.1606086654818; Sun, 22 Nov 2020 15:10:54 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id u24sm9948777pfm.51.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Nov 2020 15:10:54 -0800 (PST)
From: Bernard Aboba <>
X-Google-Original-From: Bernard Aboba <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Sun, 22 Nov 2020 15:10:52 -0800
Message-Id: <>
References: <>
Cc: Magnus Westerlund <>,,
In-Reply-To: <>
To: Sergio Garcia Murillo <>
X-Mailer: iPhone Mail (18B92)
Archived-At: <>
Subject: Re: [Sframe] Partial decodability and IDUs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Nov 2020 23:10:57 -0000

On Nov 22, 2020, at 2:48 PM, Sergio Garcia Murillo <> wrote:
> The only RTCP recovery I am aware of that could apply for IDUs is the slice loss indication which requires macroblock information, which is a way lower information layer than the one SFUs works with (it may not even be available if payload is encrypted).
> Moreover, the SFU will not rely the SLIs received from the receiving endpoint as it has no way of tracking SLIs requests from endpoints and map them to already sent ones in order to avoiding overflowing the encoder with SLIs requests.
> Also, before adding support from it, I would like to get real implementation feedback as it is currently not implemented in (lib)webrtc and I have not heard anynone asking for it ever.

[BA] Although RPSI and SLI Sections are included in several codec documents, I have not seen them implemented. We do not support SLI or RPSI in our SFU. The reasoning is that with RTX and FEC and other messages supported in WebRTC (NAK, PLI, FIR), then SLI and RPSI do not provide incremental value. 

>> So in the later cases you might want to distribute the layers on different SSRCs so that one can immediately determine how important the
>> information is. I think that possibility will exist if this RTP payload format is done correctly.

[BA] We do support MRST with H.264/SVC, and found some advantages in doing so (not having to rewrite sequence numbers in an SFU). However MRST is not supported in VP8, VP9, AV1 and most H.264/SVC implementations, and the performance cost of translation outweighed the forwarding performance advantages.