Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt

Bernard Aboba <bernard.aboba@gmail.com> Thu, 04 February 2021 16:34 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE03A1690 for <avt@ietfa.amsl.com>; Thu, 4 Feb 2021 08:34:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR650wDdnqvT for <avt@ietfa.amsl.com>; Thu, 4 Feb 2021 08:34:00 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3B83A1678 for <avt@ietf.org>; Thu, 4 Feb 2021 08:34:00 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id b2so5497043lfq.0 for <avt@ietf.org>; Thu, 04 Feb 2021 08:34:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GD8KKYYLhbx+3PlIiKzojhky1XIdQk9Z5HfYfh+59tY=; b=rkuQpU93pANa+BI0z6yDkN3Pd6xJ6gryRQPH3cb2YyJ9CXWM7W8m3x+T81npl9+Q5b 8gCg/4SPkVEw6CLtqWVThXjRWmCAiSBg0nmx9761RD9hGmOFLX3GS7RmTWJbE1T2McoY 0mOh6GHejir88jkQxUvgjvKUTv8x1JzjO2hFRecyHwW9WDb5ZAqWAq2gB3DFf3JC3wI2 0urm9FzCSHPQxoYhCNm0306IfseN+DsI+K4/dxilnkQDlRFfQ5Rdt4B4kP16qKu+rSjf 6ZNh2DTHaE+W8zlVBjdfbsjC3BYMDjdad23DV2MLsZc3Hl7u8QAhtdLj2igcjWN0XAiA 8GIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GD8KKYYLhbx+3PlIiKzojhky1XIdQk9Z5HfYfh+59tY=; b=Xbo9UKUvecTF20QteaI+TGwritWaQA7ffsAhm39DzJA1fOKfaLHm0ULCenbvInGR5e Yjay/SKLaBJI8qG4vrX6Jdsvm35YITYeJIiy1itP9/8K90gOjx6OLhwepz9S0ZZAlpmL yxR+ryjM0TJ/m0uwRki1StfcK7FG7Jj1ZQTD8zuYJR2AKRStOociBuFzK+pmvvoa2LcH HlWba7I/zVOwLIdodST3nge5GBlrB0DhHkHfZeyrxvP+qZJ2tjNBehN2O4Cv4d888gQY kaBqouuyat035qgIAUTJZ1NttEMnpqfsZU8ti1YPrdbEiHFs1DKrnGlkaMEhO68l8+Eh nvBg==
X-Gm-Message-State: AOAM530eohfjeal4JZKQf+PU8RMGFrhLaGBLEGTF+v1zogSS4z672QF7 XqfkAS2ftAg7YFPqo/EUyrZIv8TbX6MQ7uzL72+ahah5+/JmIw==
X-Google-Smtp-Source: ABdhPJxvgQuz5I7uFkndo0f+o5RKprIS5A9g76tGM81FLQPKC7UOf/JxN8DRn10Uq5ztKiZ8FhOz79uMLbY75EdI37c=
X-Received: by 2002:a19:410:: with SMTP id 16mr130635lfe.264.1612456438256; Thu, 04 Feb 2021 08:33:58 -0800 (PST)
MIME-Version: 1.0
References: <161227974389.17487.2345810476114650570@ietfa.amsl.com> <90619FEF-19AE-48B0-8C4C-D2A33870AA85@8x8.com> <AM0PR07MB3860C70B1DEA59A39F35375093B59@AM0PR07MB3860.eurprd07.prod.outlook.com> <DA91D9A6-519F-4FD0-8065-C95670D2DD00@8x8.com>
In-Reply-To: <DA91D9A6-519F-4FD0-8065-C95670D2DD00@8x8.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 04 Feb 2021 08:33:48 -0800
Message-ID: <CAOW+2dserQSN0BkynYjCTbx9y5_BE8K_rfdDin5WDLvTNHk=_g@mail.gmail.com>
To: Jonathan Lennox <jonathan.lennox@8x8.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Justin Uberti <justin@uberti.name>, IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037d79e05ba854530"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/CFURRW6vcOVTvMne1XO4n8W-K8g>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2021 16:34:09 -0000

Jonathan said:

"Hm.  For these, I think the best thing to do would be to see how the
existing (browser) implementations handle these, since there’s deployed
code here.  Justin, would you be able to ask inside Google?  And since as I
understand it the SDP parsing code is separate for the different browsers,
is there someone at the other browser implementations who could check those
as well?"

[BA] Since there is no WebRTC API to set maxfs/maxfr, the values emitted in
subsequent Offers won't change.

On Thu, Feb 4, 2021 at 8:26 AM Jonathan Lennox <jonathan.lennox@8x8.com>
wrote:

>
> Hi, Christer - thanks for your comments.
>
> > On Feb 2, 2021, at 2:30 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >
> > Hi,
> >
> > I don't know if the document will be sent to the SDP directorate, so I
> will give a few comments here:
> >
> > Q1:
> >
> > In Section 6.2.1.1., please place the m= lines and each attribute on
> separate lines.
>
> Apologies, this was an xml2rfc formatting error.  I’ll fix it for the next
> version.
>
> > Q3:
> >
> > Is there a reason why profile-id is optional, since a value will always
> be assumed?
>
> Since profile-id negotiation was developed relatively late in the process
> of writing the spec, existing implementations don’t always send it.  It
> seemed best to maintain compatibility here.
>
> > Q2:
> >
> > In Section 6.2.1, my understanding is that max-fs and max-fr are
> optional. Section 6.2.2 says that the answerer must maintain all
> configuration parameters. Does that apply to max-fs and max-fr too? If so,
> if the offer does not contain max-fs and max-fr, the answer cannot contain
> them either?
>
> > Q4:
> >
> > Section 6.2.2. does not define any restrictions on what can be modified
> in a subsequent offer, so I guess one can modify max-fs, max-fr and/or
> profile-id in a subsequent offer?
>
> Hm.  For these, I think the best thing to do would be to see how the
> existing (browser) implementations handle these, since there’s deployed
> code here.  Justin, would you be able to ask inside Google?  And since as I
> understand it the SDP parsing code is separate for the different browsers,
> is there someone at the other browser implementations who could check those
> as well?
>
> Thanks!
>
> Jonathan
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>