Re: [Sframe] Partial decodability and IDUs

Sergio Garcia Murillo <> Thu, 19 November 2020 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5FFF3A1389 for <>; Thu, 19 Nov 2020 15:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 9yiAY71aj4CC for <>; Thu, 19 Nov 2020 15:27:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 941A73A1386 for <>; Thu, 19 Nov 2020 15:27:14 -0800 (PST)
Received: by with SMTP id d12so8118582wrr.13 for <>; Thu, 19 Nov 2020 15:27:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=NVbk09OprGQOQLKiywjP5kPQKebwGuw7aylVXFoWH/Y=; b=YbEZH7YQdWvG7cP3haNffaXpjqqbAGpgW4J9Sfe8hxTB3qjooQ9lFE537WXYU61WCp CEP2ZC9jUroJZkqgrPmeOWw2SmuZh121f2dJtpD2xuXfYGM7FtOjdlXQNw2DW7YfAcxX LvSaauNgf7MAc4dWxtPS3YRKy79xi1eCL+TYigfFac2YlaF0TuL7CMkgQAOeounxYKcX wwe6MtNhoqRXL9Ohyx0QLLMjfBidVcqnwF2hescDys6zfncgQEuU06KsDbnl9pwrd6cG qW8fxdtIk17wgR4Uroa0hnpSUPi6JZPinxU0z/AmWBfpXy75aMUwHTB6yYT5lqqs6l2y Tpzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NVbk09OprGQOQLKiywjP5kPQKebwGuw7aylVXFoWH/Y=; b=Ci+bem/Rwvg9PuvMVax2CIt0DRvEPsDoMmJbVv94ccgLb1KzloyF+D/qhHn9NlCrD9 pW6GRzPghvyANaHF9hxMHXGZ4ILbTCTkoUnSmIMckIcHkaRax2bl3dQWjAz1CDyRz/zy xwjd79X2RgIsP65cBPuNMQFNZXTeGJ4UOCEImW7x/JkspnM/izfK3Kjr4nKBt6ncDtLP ahXFGCM0oipZTpxpvJDpGARh0YfvMlGEQ1iwmNConPGEAucSgk8sg84O+Qci9xFu63Zf CogheFNCng6p7TBe10U9PwVmmwq849Q7APY4QsXcK2SOASzLqzo53F7dPwphSQklmkbA U4eQ==
X-Gm-Message-State: AOAM532eB2yGC9hNGgP47UYs0jAXHm0xzZo4C2pTfYAwz7pUaWUCxoAQ QgjgBH17wka9vOFIajJ+D/z9bARd0VBq6Q==
X-Google-Smtp-Source: ABdhPJzE0kZmpiN61Vkd4ugVP4gMTCIlbVy04fJNawUaIWrBdHtc6nX6oZneGo8YTN0PKwAmajenwQ==
X-Received: by 2002:adf:f7ce:: with SMTP id a14mr12765775wrq.294.1605828432612; Thu, 19 Nov 2020 15:27:12 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id x13sm2114796wmi.20.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 15:27:12 -0800 (PST)
To: Bernard Aboba <>
Cc: Richard Barnes <>,
References: <> <> <> <> <> <>
From: Sergio Garcia Murillo <>
Message-ID: <>
Date: Fri, 20 Nov 2020 00:27:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Thu, 19 Nov 2020 23:27:16 -0000

On 20/11/2020 0:22, Bernard Aboba wrote:
> Sergio said:
> "I am afraid that we end up another doing a per-codec packetizer, 
> which would be almost the same as just using current packetization 
> formats and explain how to use encrypted data with them. And all for a 
> feature that we are not current using in webrtc."
> [BA] Some per-codec logic is required.  How else can the metadata be 
> obtained from the bitstream? But the question is whether it is 
> *required* to packetize IDUs separately, so they don't share fate.  
> I'd say this would depend on the use case. If WebRTC didn't care 
> enough about this to implement it previously, why should SFrame make a 
> difference?

Taking the AV1 dependency descriptor as an example, all of the elements 
are well defined in a codec agnostic way. Being simplistic in the 
example, there is no need for describing how to get the width and height 
of the video frame from an h264 stream, the encoder would be responsible 
for filling the the correct information. Or at least that was the idea 
behind the design.

Best regards