Re: [AVTCORE] What does "same codec+configuration" mean?
Iñaki Baz Castillo <ibc@aliax.net> Wed, 23 March 2016 12:57 UTC
Return-Path: <ibc@aliax.net>
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 5618012D752
for <avt@ietfa.amsl.com>; Wed, 23 Mar 2016 05:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=aliax-net.20150623.gappssmtp.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 MZFQb7IBbwrP for <avt@ietfa.amsl.com>;
Wed, 23 Mar 2016 05:57:07 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com
[IPv6:2607:f8b0:4002:c05::233])
(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 7F1C212D1CB
for <avt@ietf.org>; Wed, 23 Mar 2016 05:46:48 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id g127so16930889ywf.2
for <avt@ietf.org>; Wed, 23 Mar 2016 05:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=aliax-net.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=q2M7vsdzxbIRNNur4Vg5nMVqNNznBRwEKxBDzQtJLpU=;
b=HaW8eUYENFWvzHkKKZzRkA/gtuKBAz2EaNBx3Fk14Lk5t63apmM51sJgQ4TjQOnGmZ
Yk6s2ro4vjI7Jv0YRs4ZXsUVvQZaYgKCaIUIKH+L2rplDAUnGlSgbpqbRzuBMbH2Pfs3
uRFaoZHRvh/no3c9DL+AvNJA8YoYUoOOvWMhve7PuekOgCse2iaR+QA+SnvVWK5TVbon
8QzEogdz8/lK56DymB92nTpSwIWw2GzEe+bT3Yk6c+79kvLkKsJeLuZ47QlKYU/yoWGY
3KlUqQjKUGsxPYIPjDhp4YWpIHGtQfT1tyPMds+9qyRyBMRtLOzU29L11XrYXdDwuEsr
PBJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=q2M7vsdzxbIRNNur4Vg5nMVqNNznBRwEKxBDzQtJLpU=;
b=ggaG9SgTTcSN3B9coiNCvoPTyvYsCXREb80/B8731qECqknwG0B2J7q5Z9+nSIpIwM
EBOHe8wnB3xrp0/np+73QXXiUuvmQHJ1nl3LuNBwB/LPZzdnrDA8LdOoUDPyPXsKZF9Z
5MAr+bzzRWAMD/9+MRj47ztKNUGxuYrivhrxIlfN/aslePs2nmiRCwHLJXHs1qpClfRp
QMEZQQ6uxu86AiJoxKipBPasp0MkmsliQcl26CGpDp01XEHYC7XKPvxbGFFHbk9nbQ0C
LwTNiDx86U4WGId+SmVExp+Ey24HDb9x3p8bZXZLbWwlPpNnMoUuR+Vy75Dps7rVfjYo
2JVg==
X-Gm-Message-State: AD7BkJK3srjahd9wbrNPSpkf2KqlZK55mkmcWXYRsdQOCQMriFumR1nNwfvtvBIuG2DqUgW9+615aiTZPML8lw==
X-Received: by 10.13.251.135 with SMTP id l129mr1166895ywf.283.1458737207721;
Wed, 23 Mar 2016 05:46:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Wed, 23 Mar 2016 05:46:28 -0700 (PDT)
In-Reply-To: <56F15CDC.202@ericsson.com>
References: <CALiegfn2bMHX-yRDrHh0RKx-n4DfnLb1HfEeX18_ZigJGYOsLA@mail.gmail.com>
<56F15CDC.202@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Wed, 23 Mar 2016 13:46:28 +0100
Message-ID: <CALiegf=tzUZQUApL7MiLHA0vLcD+RsGHz61NMACL_Obv0NE3cA@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/a5WjfkxLsrMEU8CnAmgtwTuBMiM>
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] What does "same codec+configuration" mean?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 23 Mar 2016 12:57:09 -0000
2016-03-22 15:55 GMT+01:00 Magnus Westerlund <magnus.westerlund@ericsson.com>om>: > 10.1.2. Payload Type (PT) Value Reuse > > Multiple bundled "m=" lines might represent RTP based media. As all > RTP based media associated with a BUNDLE group belong to the same RTP > session, in order for a given payload type value to be used inside > more than one bundled "m=" line, all codecs associated with the > payload type number MUST share an identical codec configuration. > This means that the codecs MUST share the same media type, encoding > name, clock rate and any parameter that can affect the codec > configuration and packetization. > [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose > attribute values must be identical for all codecs that use the same > payload type value. > > So identical a=rtpmap and a=fmtp lines would meet this criteria. This is becoming so hard to manage: Offer by Firefox 48: m=audio 49706 UDP/TLS/RTP/SAVPF 109 9 0 8 a=rtpmap:109 opus/48000/2 a=fmtp:109 maxplaybackrate=48000;stereo=1 a=rtpmap:9 G722/8000/1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 61083 UDP/TLS/RTP/SAVPF 120 126 97 a=rtpmap:120 VP8/90000 a=fmtp:120 max-fs=12288;max-fr=60 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 Answer by Chrome 51: m=audio 61998 UDP/TLS/RTP/SAVPF 109 9 0 8 a=rtpmap:109 opus/48000/2 a=fmtp:109 minptime=10; useinbandfec=1 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 9 UDP/TLS/RTP/SAVPF 120 a=rtpmap:120 VP8/90000 Obviously they both interop at opus and VP8 level, so let's see codecs definition: 1a) opus in Firefox: a=rtpmap:109 opus/48000/2 a=fmtp:109 maxplaybackrate=48000;stereo=1 1b) opus in Chrome: a=rtpmap:109 opus/48000/2 a=fmtp:109 minptime=10; useinbandfec=1 So I must assume that maxplaybackrate, stereo, minptime and useinbandfec are optional params for opus, or that their default values (if omitted) match those values, so both codecs+configuration are the "same". 2a) VP8 in Firefox: a=rtpmap:120 VP8/90000 a=fmtp:120 max-fs=12288;max-fr=60 2b) VP8 in Chrome: a=rtpmap:120 VP8/90000 Here also I assume that max-fs and max-fr are optional parameters that do not prevent both offered codec+configuration to match. 3a) G722 in Firefox: a=rtpmap:9 G722/8000/1 3b ) G722 in Chrome: a=rtpmap:9 G722/8000 Do they match? Is "1" the default value for the 'encoding' field in a rtpmap entry? 4) H264 in Firefox: a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 Since Firefox offers two H264 codecs I must assume they are, indeed, different codecs. So it seems that "packetization-mode=1" make them different (which also means that its default value is not 1). Right? This is terribly complex and unmanageable. And this requires the SFU developer to become an expert in codec specific parameters (regardless the SFU won't decode media). -- Iñaki Baz Castillo <ibc@aliax.net>
- [AVTCORE] What does "same codec+configuration" me… Iñaki Baz Castillo
- Re: [AVTCORE] What does "same codec+configuration… Magnus Westerlund
- Re: [AVTCORE] What does "same codec+configuration… Iñaki Baz Castillo
- Re: [AVTCORE] What does "same codec+configuration… Iñaki Baz Castillo
- Re: [AVTCORE] What does "same codec+configuration… Iñaki Baz Castillo