Re: [rtcweb] Finishing up the Video Codec document

Stephan Wenger <> Wed, 26 November 2014 05:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3BA841A87D7 for <>; Tue, 25 Nov 2014 21:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WZGZ9B4OH-Hk for <>; Tue, 25 Nov 2014 21:17:19 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7223E1A88BC for <>; Tue, 25 Nov 2014 21:17:19 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 26 Nov 2014 05:16:56 +0000
Received: from ([]) by ([]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 05:16:56 +0000
From: Stephan Wenger <>
To: Adam Roach <>, "" <>
Thread-Topic: Finishing up the Video Codec document
Thread-Index: AQHQCQhLH8Rvof4WtkWeNp84Mnvyvpxx2CWA
Date: Wed, 26 Nov 2014 05:16:55 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1274;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274;
x-forefront-prvs: 04073E895A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(24454002)(479174003)(2501002)(97736003)(101416001)(31966008)(2656002)(87936001)(36756003)(86362001)(120916001)(92726001)(561944003)(92566001)(99286002)(15202345003)(107886001)(107046002)(106356001)(106116001)(46102003)(19580405001)(105586002)(19580395003)(76176999)(50986999)(40100003)(122556002)(54356999)(64706001)(66066001)(20776003)(77156002)(77096003)(62966003)(4396001)(15975445006)(95666004)(21056001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Finishing up the Video Codec document
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Nov 2014 05:17:22 -0000

below a few generic comments (not directly related to my action item).

1. Section 3: sRGB is fine.

2. Section 3: Add something like dynamic frame rate / frame interval based
on user locale, available bandwidth, and so on.  For example, in low light
conditions, it almost never makes sense to run a full 30 fps camera when
your transport has only bandwidth for 15 fps.

3. Section 3: Possibly missing: mention that the video scan pattern for
both VP8 and H.264 is YCrCb 4:2:0.

4. Section 3: Possibly missing: the screen content section should mention
that the scan format of video (YCrCb 4:2:0) is known to be suboptimal for
the representation of screen content as produced by systems at the time of
publication, which generally use at least 24 bits per sample RGB.  Perhaps
a forward looking statement: ³In the future, it may become advisable to
use video codecs optimized for screen content (scan pattern, color space,
signal characteristics) for the representation of this type of content.²

5. Section 5 second and third paragraphs: Mention Constrained Baseline
Profile here.   Otherwise, section 5 seems fine to me.  (I know that
constrained baseline is mentioned as a MUST later, but H.264 in isolation
is insufficient even in this overview part of the document).

6. Section 6, 3rd para, 1st and 2nd line, nit: "are MUST²

5. Section 6.2, profile_level_id, suggest to change the receiving side to
a MUST.  The decoder interprets the value anyway as presented in-band.
What¹s the point that a receiver accepts a bitstream (without checking
profile_level_id), and the croaks because the decoder cannot handle the
bitstream complexity as communicated in-band?

6. Section 6.2, max_mbps..., nit: par ameters (1st and second line)

Normative reference to H.264: depending on the timing, it may be better to
reference H.264v9.  That version is currently in ³pre-published² state and
not freely downloadable, but should be generally available rather sooner
than later (and almost certainly before we are through with this draft).

7. Section 6.2, sprop_parameter_sets: For avoidance of doubt, I would
rephrase that as ³this parameter MUST NOT be present².  It is possible to
have that parameter and later change parameter sets in-band, and that is a
condition I think you want to avoid.  (btw. my heart is bleeding.  Some of
you know why.  The rest: keep guessing :-)

8. Section 6.2, Possibly missing: for H.264, should we specify a pixel
aspect ratio?  VP8 uses square pixels, right?  Perhaps follow that lead?

9. Section 7: point to the payload formats also.  H.264 allows for active
content in SEI messages... and the payload formats contain the necessary

On 11/25/14, 15:33, "Adam Roach" <> wrote:

>I've updated the draft-ietf-rtcweb-video based on the minutes from
>Hawaii. Now that we have a clear path to success, I'd like to get the
>document finalized and published as quickly as possible. This means I
>need your feedback on the remaining open issues (1, 4, and 5, below). If
>you are CCed on this mail, it's because you took an action item in
>Hawaii, and I'm waiting to hear back from you.
>New version:
>Action item for Harald Alvestrand from the minutes:
>> Mo Zanaty: An IANA registered header with reference to 3GPP document.
>> Codec specific mechanism way of doing this.
>> Harald: Will send some suggestions on doing this.
>Action item for Bernard Aboba and Stephan Wenger: collect list of H.264
>SEI messages we want to call out as MUST and/or SHOULD.
>Open Issue 1: If you don't want sRGB to be the default color space, say
>something now.
>Open Issue 2 (closed): Took "screen source video metadata" issue out of
>the document, as this is an RTP issue, not a codec issue.
>Open Issue 3 (closed): New text in "stream orientation" section calling
>out various MUST/SHOULD/MAY levels, based on what I took away from the
>mic in Hawaii. If you care about this, double-check that these are what
>you expect them to be.
>Open Issue 4: In Toronto, it was suggested that we don't need to specify
>support for "bilinear" and "none" filter styles, since they're already
>required. I'm happy to remove the statement if someone can point me to
>where this is otherwise mandated. If no one comes forward with a
>citation, I'm going to close this open issue as harmless.
>Open Issue 5: Waiting on feedback from Bernard and Stefan, as detailed
>Open Issue 6 (closed): Please see the text in section 5 of the new
>document, which tracks the text from the Novel Proposal email pretty