From ietf-secretariat-reply@ietf.org Fri Jul 12 09:15:28 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DEF21F9F96 for ; Fri, 12 Jul 2013 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsBjikJYvKNE for ; Fri, 12 Jul 2013 09:15:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A1E21F9FA1 for ; Fri, 12 Jul 2013 09:15:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712161527.30640.80664.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 09:15:27 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 12 Jul 2013 13:52:02 -0700 Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:15:28 -0000 Changed milestone "Submit RTP Header extension for mixer to client audio level indication as Proposed Standard", set due date to October 2011 from October 2011. Changed milestone "Submit RTP Header extension for client to mixer audio level indication as proposed standard", set due date to October 2011 from October 2011. Changed milestone "Submit Support for multiple clock rates in an RTP session for Proposed Standard", set due date to December 2011 from December 2011. Changed milestone "Request Publication of specification for duplicating RTP Streams with intended status as Proposed Standard", set due date to March 2013 from March 2013. Added milestone "Taxonomy of RTP (as informational) to IESG", due October 2013. URL: http://datatracker.ietf.org/wg/avtext/charter/ From keith.drage@alcatel-lucent.com Tue Jul 16 07:53:38 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C75221F9B21 for ; Tue, 16 Jul 2013 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5b4rcDFqIiU for ; Tue, 16 Jul 2013 07:53:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D27C421F9A8F for ; Tue, 16 Jul 2013 07:53:30 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6GErRfu002452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 09:53:29 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GErRae020294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 16:53:27 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:53:27 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5g== Date: Tue, 16 Jul 2013 14:53:26 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AD4E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:53:38 -0000 (As AVTEXT WG cochair) The latest version of the taxonomy draft has been submitted https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy= /=20 This document was allocated to AVTEXT by dispatch, and we have created a mi= lestone for it in AVTEXT. This draft is not yet a working group document. We do expect to spend some significant time discussing the contents in the = AVTEXT meeting in Berlin, so please start raising your issues on the AVTEXT= list. Additionally, if there are counter proposals existing that the AVTEXT chair= s would not otherwise be aware of, then please identify them to the AVTEXT = chairs / list. Regards Keith From keith.drage@alcatel-lucent.com Wed Jul 17 04:58:03 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A821F9EA9 for ; Wed, 17 Jul 2013 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS3G4O52wSOa for ; Wed, 17 Jul 2013 04:57:58 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D96E521F9E28 for ; Wed, 17 Jul 2013 04:57:57 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6HBvsZ5006238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 06:57:55 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HBvrTt031898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:57:53 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 13:57:53 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: [dispatch] Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrAACo7ARD//+TjgP//1h+Q Date: Wed, 17 Jul 2013 11:57:52 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06B988@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Subject: [avtext] FW: [dispatch] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:58:03 -0000 A comment (which I am forwarding to the list) on the taxonomy document... -----Original Message----- From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: 17 July 2013 12:27 To: DRAGE, Keith (Keith) Cc: mmusic@ietf.org; rtcweb@ietf.org; clue@ietf.org; dispatch@ietf.org; avt= @ietf.org Subject: Re: [dispatch] Taxonomy 2013/7/17 DRAGE, Keith (Keith) : > The expectation however is that documents going forward from other workin= g groups would use the new terminology rather than other terms. > > Obviously how this is handled is up to the individual working groups, but= using the new terminology will be the only good way of making your results= understandable outside your specific field. > > So that is why your review and input is important. Hi Drage, First of I'm sorry but I'm not subscribed to MMUSIC nor CLUE, so let me please reply here (it is just a single topic): I'm really annoying after reading the draft section 2.4 "Media Stream": http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#= section-2.4 ------------------------ Each Media Stream is identified by a unique Synchronization source (SSRC) [RFC3550] that is carried in every RTP and Real-time Transport Control Protocol (RTCP) packet header. ------------------------ In W3C we have "MediaStream" and "MediaStreamTrack", and "MediaStreamTrack" is exactly what the draft above defines as "Media Stream". So let me say that this is the most confusing terminology it can be. -- I=F1aki Baz Castillo From jonathan@vidyo.com Wed Jul 17 14:29:40 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7A21F9970 for ; Wed, 17 Jul 2013 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUU+t8Hozweb for ; Wed, 17 Jul 2013 14:29:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id C5DC221F99D7 for ; Wed, 17 Jul 2013 14:29:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9AD2E7AB50C; Wed, 17 Jul 2013 17:29:29 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 86C1A7AB4F2; Wed, 17 Jul 2013 17:29:25 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Wed, 17 Jul 2013 17:27:13 -0400 From: Jonathan Lennox To: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= Date: Wed, 17 Jul 2013 17:29:29 -0400 Thread-Topic: [dispatch] Taxonomy Thread-Index: Ac6DNGcOQksL6zfRRzWJaTz/pmxe8A== Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] [dispatch] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:29:40 -0000 Hi, I=F1aki -- the right place to discuss this draft is the AVTExt mailing = list, Cc'd. On Jul 17, 2013, at 7:26 AM, I=F1aki Baz Castillo wrote: > I'm really annoying after reading the draft section 2.4 "Media Stream": >=20 > http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01= #section-2.4 >=20 > ------------------------ > Each Media Stream is identified by a unique Synchronization source > (SSRC) [RFC3550] that is carried in every RTP and Real-time > Transport Control Protocol (RTCP) packet header. > ------------------------ >=20 > In W3C we have "MediaStream" and "MediaStreamTrack", and > "MediaStreamTrack" is exactly what the draft above defines as "Media > Stream". >=20 > So let me say that this is the most confusing terminology it can be. It's actually even worse than that -- in SDP, a "Media Stream" has yet anot= her meaning, as the object described by an m-line -- i.e., not the same thi= ng as either an RTP media stream, nor an RtcMediaStream. Unfortunately, we haven't come up with any good alternative terms that we c= an get consensus on. Do you have any suggestions? By the way, I don't think a WebRTC RtcMediaStreamTrack actually is the same= thing as an RTP media stream, once things like RTX, FEC, and simulcast are= taken into account=85explicating subtleties like that is one of the purpos= es of this draft. I'm not sure it's succeeded at this yet, though. -- Jonathan Lennox jonathan@vidyo.com From fineberg@vline.me Wed Jul 17 15:36:58 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50D721F9B07 for ; Wed, 17 Jul 2013 15:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4miZ5y9JaM2 for ; Wed, 17 Jul 2013 15:36:54 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 27B7321F9A1C for ; Wed, 17 Jul 2013 15:36:54 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so2400903pbc.35 for ; Wed, 17 Jul 2013 15:36:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type:x-gm-message-state; bh=oR8DJ/MgaM+eOUt27KQcdTQSqaSnEiRhmKAQKZCHkTU=; b=DUFxPzcErSy/nxLcuuIWm0BJCzkuHAX7fl0S+inA7YxtLTbsX5mdL5eXcdgd3A9/Ne ptrhsPSFlPfb/siFE3ncIbBS3jzQW72T/k+ho1Gb/B2dPIHTw5RbDTJCn5qubzoGsrQd 1bqfVZTGfYM4Aka99UB3rmcknJXKfzdO/qUNn0k2hZFRxYvW2yLlh7LvPfQyGtWA85mv /fOeOp7GmyZEN1xpsTexY6mMi017+1zLfDN7b7+Uuqgpr3BDpgs1yM0iz5mnqekYgnY5 n3+QlbqJ2pDsLJEbX6QhADJyQ57Ztn6EI8hQCYCxlsYZJWOEu+k2eySNk/PW4YEcIbtI lA9g== X-Received: by 10.66.49.68 with SMTP id s4mr4481132pan.98.1374100613781; Wed, 17 Jul 2013 15:36:53 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id eq5sm9929764pbc.15.2013.07.17.15.36.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 15:36:52 -0700 (PDT) Message-ID: <51E71C82.7090608@vline.me> Date: Wed, 17 Jul 2013 15:36:50 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: avtext@ietf.org References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> In-Reply-To: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010703070807050808080308" X-Gm-Message-State: ALoCoQmp3xv9CtdFYEkzYSt6ghUfFtfnazupaDA72cD8yBomk5x5l+2NvEmbeH9ED9uWxNqA9ODB X-Mailman-Approved-At: Wed, 17 Jul 2013 16:02:03 -0700 Subject: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:37:49 -0000 This is a multi-part message in MIME format. --------------010703070807050808080308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middlebox needs to have acesss to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg@vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts@ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. The IETF Secretariat --------------010703070807050808080308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets.  This is undesirable both because the middlebox needs to have acesss to the keys as well as the because of the added overhead of the decrypt/encrypt cycle.  This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption.  Comments welcome.

Regards,
Adam Fineberg
fineberg@vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts@ietf.org
To: Adam Fineberg <fineberg@vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

                                                                                  


The IETF Secretariat

--------------010703070807050808080308-- From keith.drage@alcatel-lucent.com Thu Jul 18 04:24:20 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54A221F93DB for ; Thu, 18 Jul 2013 04:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjky6Miz77b9 for ; Thu, 18 Jul 2013 04:24:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 206F911E8124 for ; Thu, 18 Jul 2013 04:24:10 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6IBO34H012341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Jul 2013 06:24:05 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6IBO3UI026198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 13:24:03 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 13:24:03 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: Agenda for AVTEXT session in IETF 87 Berlin Thread-Index: Ac6DqU4D0mYcm5InSki5YYq9zwu/Pw== Date: Thu, 18 Jul 2013 11:24:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06C682@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [avtext] Agenda for AVTEXT session in IETF 87 Berlin X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 11:24:21 -0000 I have posted the initial agenda for Berlin at https://datatracker.ietf.org/meeting/87/agenda/avtext/ Comments welcome. Note that the intent of the penultimate agenda item is not to duplicate the= MMUSIC discussion - but rather to reflect the impact on AVTEXT of the MMUS= IC discussions. Regards Keith From fineberg@vline.me Thu Jul 18 08:45:46 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395B821E80F5 for ; Thu, 18 Jul 2013 08:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAveoWq7uXcn for ; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id CFF6A11E815C for ; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so3218542pdd.34 for ; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=jXUTlsZ9ee1gEnqWulnepTMcYn1XmbOYiddCXXIpaew=; b=GlSYNl5ydBD2l0q6shQ9iZKPw/v6DGJ6LyN9hmRHYRhdwthe0bGbdfRwbWBCMnSj7D HoYlLZRQ8XDVecJD6KUzrXakJgWTb5Ok6vYHxvw7hbVgUMoNZKAGme7oXUh5u+A7YTXy SmSAbUqnw5OCnGkpd4nVx9g2+yKPBywRvT1w1b4ym/RYCNtzEFwfVP5zD+jK5fYh/lIk B/cdz0JVKHOaJEg7XH5t1pkjBhy3M43RpXoCmO+AY2StwDGOp22kji/OSG6rd81T/EIp lFZEYBq1ZtSnFxNhxfx/lbYs2F5pl8WUt3Ui/eKtz9lH3cfsN5EJQAbbvs4JIZSsEBDM ynTA== X-Received: by 10.66.146.9 with SMTP id sy9mr13993340pab.16.1374162341121; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id ai6sm17379482pad.15.2013.07.18.08.45.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 08:45:40 -0700 (PDT) Message-ID: <51E80DA2.4030500@vline.me> Date: Thu, 18 Jul 2013 08:45:38 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: <51E7324A.3090405@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080806000200010002090007" X-Gm-Message-State: ALoCoQmlRhwGMDWsZ18Rig0onQH2VXYoPnK2e+LW4UL225idWy4Wf2MYvWPOKPXs/znb+u/xJyPB X-Mailman-Approved-At: Thu, 18 Jul 2013 08:46:56 -0700 Cc: avtext@ietf.org, "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:45:46 -0000 This is a multi-part message in MIME format. --------------080806000200010002090007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, Good question. I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize. If you'd like to help specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: > Since the need is not codec specific (e.g. it arises with any codec > supporting temporal, spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the temporal layer information > from the RTP header which requires us to decrypt the SRTP packets. > This is undesirable both because the middle-box needs to have access > to the keys as well as the because of the added overhead of the > decrypt/encrypt cycle. This draft proposes an RTP header extension > that will allow us to use the VP8 temporal layer information included > in the header extension and therefore do forwarding without SRTP > decryption. Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- > Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > Date: Tue, 09 Jul 2013 10:02:05 -0700 > From: internet-drafts at ietf.org > > To: Adam Fineberg > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Regards, Adam --------------080806000200010002090007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam
--------------080806000200010002090007-- From bernard_aboba@hotmail.com Thu Jul 18 19:40:13 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5772C21E815C; Thu, 18 Jul 2013 19:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4kIuI9nv6c2; Thu, 18 Jul 2013 19:40:08 -0700 (PDT) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8721E813A; Thu, 18 Jul 2013 19:40:08 -0700 (PDT) Received: from BLU169-W107 ([65.55.111.137]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 19:40:07 -0700 X-TMN: [8StdPs56VaXZ0flKiKzTGvdAqo3Db3STgwAlm+JlLkU=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e40724f7-758d-4c47-8861-18af1b356bd4_" From: Bernard Aboba To: Adam Fineberg Date: Thu, 18 Jul 2013 19:40:07 -0700 Importance: Normal In-Reply-To: <51E80DA2.4030500@vline.me> References: <51E7324A.3090405@vline.me> , <51E80DA2.4030500@vline.me> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2013 02:40:07.0645 (UTC) FILETIME=[47FA88D0:01CE8429] Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 02:40:13 -0000 --_e40724f7-758d-4c47-8861-18af1b356bd4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it may be possible to generalize this. For example=2C for H.264/SV= C which can support temporal=2C spatial and quality scalability=2C you woul= d need the quality_id and dependency_id in addition to the temporal_id (wha= t you call the temporal layer index). =20 Date: Thu=2C 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org=3B avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt =0A= =0A= =0A= =0A= =0A= Bernard=2C =0A= =20 =0A= Good question. I'm not familiar enough with the parameter=0A= requirements of all other scalable codecs to be able to generalize. =0A= If you'd like to help specify them=2C I'd be fine revising the draft=0A= to generalize. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/17/13 8:26 PM=2C Bernard Aboba=0A= wrote: =0A= =0A= =0A= =0A= Since the need is not codec specific (e.g. it=0A= arises with any codec supporting temporal=2C spatial and quality=0A= scalability)=2C why=20 =0A= a VP8-specific RTP extension?=20 =0A= =20 =0A= =0A= Date: Wed=2C 17 Jul 2013 17:09:46 -0700 =0A= From: fineberg@vline.me =0A= To: rtcweb@ietf.org =0A= Subject: [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =20 =0A= Hi=2C=0A= =0A= I'm working on WebRTC=0A= services and have found that while developing services that=0A= forward VP8 video streams if we want to take advantage of=0A= the VP8 temporal scaling we must get the temporal layer=0A= information from the RTP header which requires us to decrypt=0A= the SRTP packets. This is undesirable both because the=0A= middle-box needs to have access to the keys as well as the=0A= because of the added overhead of the decrypt/encrypt cycle.=0A= This draft proposes an RTP header extension that will allow=0A= us to use the VP8 temporal layer information included in the=0A= header extension and therefore do forwarding without SRTP=0A= decryption. Comments welcome.=0A= =0A= Regards=2C=0A= Adam Fineberg=0A= fineberg=0A= at vline.com =0A= =20 =0A= -------- Original Message --------=0A= =0A= =0A= =0A= Subject:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt=0A= =0A= =0A= Date:=0A= Tue=2C 09 Jul 2013 10:02:05 -0700=0A= =0A= =0A= From:=0A= internet-drafts at ietf.org=0A= =0A= =0A= To:=0A= Adam Fineberg =0A= =0A= =0A= =0A= =20 =0A= =20 =0A= A new version of I-D=2C draft-fineberg-avtext-temporal-layer-ex= t-00.txt=0A= has been successfully submitted by Adam Fineberg and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-fineberg-avtext-temporal-layer-ext=0A= Revision: 00=0A= Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information=0A= Creation date: 2013-07-08=0A= Group: Individual Submission=0A= Number of pages: 6=0A= URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt=0A= Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext=0A= Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00=0A= =0A= =0A= Abstract:=0A= This document defines a mechanism by which packets of Real-Time=0A= Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A= indicate=2C in an RTP header extension=2C the temporal layer information= =0A= about the frame encoded in the RTP packet. This information can be=0A= used in a middlebox performing bandwidth management of streams=0A= without requiring it to decrypt the streams.=0A= =0A= =0A= =20 =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam = --_e40724f7-758d-4c47-8861-18af1b356bd4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think it may be possible to ge= neralize this. =3B For example=2C for H.264/SVC which can support tempo= ral=2C spatial and quality scalability=2C you would need the quality_id and= dependency_id in addition to the temporal_id (what you call the temporal l= ayer index).  =3B =3B

Date: Th= u=2C 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_a= boba@hotmail.com
CC: rtcweb@ietf.org=3B avtext@ietf.org
Subject: Re: = [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-l= ayer-ext-00.txt

=0A= =0A= =0A= =0A= =0A= Bernard=2C
=0A=
=0A= Good question. =3B I'm not familiar enough with the parameter=0A= requirements of all other scalable codecs to be able to generalize.&nbs= p=3B=0A= If you'd like to help specify them=2C I'd be fine revising the draft=0A= to generalize.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/17/13 8:26 PM=2C Bernard Aboba= =0A= wrote:
=0A=
=0A=
= =0A= =0A=
Since the need is not codec specific (e.g. it=0A= arises with any codec supporting temporal=2C spatial and quality=0A= scalability)=2C why
=0A=  =3Ba VP8-specific RTP extension?
=0A=  =3B
=0A=
=0A=
Date: Wed=2C 17 Jul 2013 17:09:46 -070= 0
=0A= From: fineberg@vline.me
=0A= To: rtcweb@ietf.org
=0A= Subject: [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
=0A=
=0A= Hi=2C
=0A=
=0A= I'm working on WebRTC=0A= services and have found that while developing services that=0A= forward VP8 video streams if we want to take advantage of=0A= the VP8 temporal scaling we must get the temporal layer=0A= information from the RTP header which requires us to decrypt=0A= the SRTP packets. This is undesirable both because the=0A= middle-box needs to have access to the keys as well as the=0A= because of the added overhead of the decrypt/encrypt cycle.=0A= This draft proposes an RTP header extension that will allow=0A= us to use the VP8 temporal layer information included in the=0A= header extension and therefore do forwarding without SRTP=0A= decryption. Comments welcome.
=0A=
=0A= Regards=2C
=0A= Adam Fineberg
=0A=
fineberg=0A= at vline.com
=0A=
=0A= -------- Original Message --------=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Subject:New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
Date:Tue=2C 09 Jul 2013 10:02:05 -0700
From:internet-drafts at iet= f.org
To:Adam Fineberg =3B<=3Bfineberg at vline.com>=3B=
=0A=
=0A=
=0A= 
A new version of I-D=2C draft-fineberg-avtext-temporal-=
layer-ext-00.txt=0A=
has been successfully submitted by Adam Fineberg and posted to the=0A=
IETF repository.=0A=
=0A=
Filename:	 draft-fineberg-avtext-temporal-layer-ext=0A=
Revision:	 00=0A=
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information=0A=
Creation date:	 2013-07-08=0A=
Group:		 Individual Submission=0A=
Number of pages: 6=0A=
URL:             http://www.ietf.org/internet-drafts/draft-=
fineberg-avtext-temporal-layer-ext-00.txt=0A=
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext=
-temporal-layer-ext=0A=
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-tempor=
al-layer-ext-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a mechanism by which packets of Real-Time=0A=
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A=
   indicate=2C in an RTP header extension=2C the temporal layer information=
=0A=
   about the frame encoded in the RTP packet.  This information can be=0A=
   used in a middlebox performing bandwidth management of streams=0A=
   without requiring it to decrypt the streams.=0A=
=0A=
=0A=
=0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/l= istinfo/rtcweb
=0A=
=0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
= --_e40724f7-758d-4c47-8861-18af1b356bd4_-- From bernard_aboba@hotmail.com Thu Jul 18 22:56:30 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ACB11E82A3; Thu, 18 Jul 2013 22:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqkJWjeU5Nrh; Thu, 18 Jul 2013 22:56:20 -0700 (PDT) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDAE11E829E; Thu, 18 Jul 2013 22:56:17 -0700 (PDT) Received: from BLU401-EAS75 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 22:56:16 -0700 X-TMN: [XL0vYhv/qdKDyNQZ7Du3jkvRaw85Bc66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95" Content-Transfer-Encoding: 7bit References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51E8B3B8.3090502@vline.me> Date: Thu, 18 Jul 2013 22:56:12 -0700 To: Adam Fineberg X-OriginalArrivalTime: 19 Jul 2013 05:56:16.0271 (UTC) FILETIME=[AEA059F0:01CE8444] Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:56:30 -0000 --Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" wrote: > Bernard, >=20 > Are there other codecs you are thinking should be supported? If it's gene= ralized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generaliz= ed header. >=20 > Regards, > Adam >=20 > On 7/18/13 7:40 PM, Bernard Aboba wrote: >> I think it may be possible to generalize this. For example, for H.264/SV= C which can support temporal, spatial and quality scalability, you would nee= d the quality_id and dependency_id in addition to the temporal_id (what you c= all the temporal layer index). =20 >>=20 >> Date: Thu, 18 Jul 2013 08:45:38 -0700 >> From: fineberg@vline.me >> To: bernard_aboba@hotmail.com >> CC: rtcweb@ietf.org; avtext@ietf.org >> Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-av= text-temporal-layer-ext-00.txt >>=20 >> Bernard, >>=20 >> Good question. I'm not familiar enough with the parameter requirements o= f all other scalable codecs to be able to generalize. If you'd like to help= specify them, I'd be fine revising the draft to generalize. >>=20 >> Regards, >> Adam >>=20 >> On 7/17/13 8:26 PM, Bernard Aboba wrote: >> Since the need is not codec specific (e.g. it arises with any codec suppo= rting temporal, spatial and quality scalability), why=20 >> a VP8-specific RTP extension?=20 >> =20 >> Date: Wed, 17 Jul 2013 17:09:46 -0700 >> From: fineberg@vline.me >> To: rtcweb@ietf.org >> Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext= -temporal-layer-ext-00.txt >>=20 >> Hi, >>=20 >> I'm working on WebRTC services and have found that while developing servi= ces that forward VP8 video streams if we want to take advantage of the VP8 t= emporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both b= ecause the middle-box needs to have access to the keys as well as the becaus= e of the added overhead of the decrypt/encrypt cycle. This draft proposes an= RTP header extension that will allow us to use the VP8 temporal layer infor= mation included in the header extension and therefore do forwarding without S= RTP decryption. Comments welcome. >>=20 >> Regards, >> Adam Fineberg >> fineberg at vline.com >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt >> Date: Tue, 09 Jul 2013 10:02:05 -0700 >> From: internet-drafts at ietf.org >> To: Adam Fineberg >>=20 >> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >> has been successfully submitted by Adam Fineberg and posted to the >> IETF repository. >>=20 >> Filename: draft-fineberg-avtext-temporal-layer-ext >> Revision: 00 >> Title: A Real-Time Transport Protocol (RTP) Header Extens= ion for VP8 Temporal Layer Information >> Creation date: 2013-07-08 >> Group: Individual Submission >> Number of pages: 6 >> URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtex= t-temporal-layer-ext-00.txt >> Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-te= mporal-layer-ext >> Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-tempora= l-layer-ext-00 >>=20 >>=20 >> Abstract: >> This document defines a mechanism by which packets of Real-Time >> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >> indicate, in an RTP header extension, the temporal layer information >> about the frame encoded in the RTP packet. This information can be >> used in a middlebox performing bandwidth management of streams >> without requiring it to decrypt the streams. >>=20 >> _______________________________________________ rtcweb mailing list rtcwe= b@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> --=20 >> Regards, >> Adam >=20 --Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam

--Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95-- From fineberg@vline.me Thu Jul 18 20:34:21 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73611E827B; Thu, 18 Jul 2013 20:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RNqKuCaqEac; Thu, 18 Jul 2013 20:34:20 -0700 (PDT) Received: from cat2.kjsl.com (cat2.kjsl.com [IPv6:2001:1868:2001::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBDD11E8278; Thu, 18 Jul 2013 20:34:20 -0700 (PDT) Received: from Adam-Finebergs-MacBook-Pro-2.local (75-25-130-225.lightspeed.sjcpca.sbcglobal.net [75.25.130.225]) (Authenticated sender: fineberg) by cat2.kjsl.com (Postfix) with ESMTP id AE5E712550A; Thu, 18 Jul 2013 23:34:17 -0400 (EDT) Message-ID: <51E8B3B8.3090502@vline.me> Date: Thu, 18 Jul 2013 20:34:16 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: <51E7324A.3090405@vline.me> , <51E80DA2.4030500@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050600000506060503030109" X-Mailman-Approved-At: Fri, 19 Jul 2013 06:25:06 -0700 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 03:34:21 -0000 This is a multi-part message in MIME format. --------------050600000506060503030109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, Are there other codecs you are thinking should be supported? If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: > I think it may be possible to generalize this. For example, for > H.264/SVC which can support temporal, spatial and quality scalability, > you would need the quality_id and dependency_id in addition to the > temporal_id (what you call the temporal layer index). > > ------------------------------------------------------------------------ > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org; avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the parameter > requirements of all other scalable codecs to be able to generalize. > If you'd like to help specify them, I'd be fine revising the draft to > generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it arises with any > codec supporting temporal, spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while > developing services that forward VP8 video streams if we want to > take advantage of the VP8 temporal scaling we must get the > temporal layer information from the RTP header which requires us > to decrypt the SRTP packets. This is undesirable both because the > middle-box needs to have access to the keys as well as the because > of the added overhead of the decrypt/encrypt cycle. This draft > proposes an RTP header extension that will allow us to use the VP8 > temporal layer information included in the header extension and > therefore do forwarding without SRTP decryption. Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- > Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > Date: Tue, 09 Jul 2013 10:02:05 -0700 > From: internet-drafts at ietf.org > > To: Adam Fineberg > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Regards, > Adam --------------050600000506060503030109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam

--------------050600000506060503030109-- From juberti@google.com Fri Jul 19 06:32:46 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BAC11E8118 for ; Fri, 19 Jul 2013 06:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1Uikad7e5fw for ; Fri, 19 Jul 2013 06:32:44 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 862B711E8103 for ; Fri, 19 Jul 2013 06:32:44 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so9194036ieb.24 for ; Fri, 19 Jul 2013 06:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sNXOXmw8EKbRAAw1QZCo1qOK2THNFdoLwgNWXkVo5Hg=; b=VMeTu4BCQ+OCl7M+ridcpBmJNIIXCQ7qHJ9iLbSue/z2CVj7MLjJC+TVkrBThPXAlB 3k9qXbRgPr2VgHcsTwyif3rfeMsS2NKA5WWJCnmrYzjkg1yeQ7V52avrLQXht5dARS1a PR4n+wDzpzVD7ykopMb/Squ4FZ7VJ8idfqG1pPOTBzSi4xGqT5RQbgHji4JhKHYlIFwk FJ9JrI1B/uupoNb+wckNqTxVZINmSAOuGEurfQ9G+TzFyifdITE2EwS8iSq+S7ZrGHCL kkY8pFO2AWJtkA3gVExp1ev0+fvECnWtFIX4m2GyNOuTvuQBlQwt1RyTIBgwVt9OYbCf 1LVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=sNXOXmw8EKbRAAw1QZCo1qOK2THNFdoLwgNWXkVo5Hg=; b=UzjHgRv9hmySo1nYxgCl233YDK3mxDSZiTPxDSq20Wbo/NK8va43Npnw2XP3q0Nbz7 1xPQ7dPq735llvab7S6S/O/c1PYYaekJbSO1OcNW1wV2BWLNuVirKEkWjtNZIgpAolm8 10BYgMzUhxm+RHeMTe2kvErA8zSEY48oJyOkWZ98phJS3sRGJFKcclixd1WSkZhdqHK+ EOAv6py3RxHgYo0lD4EHTHLoXEXdQTzlB0zg1zJYVlVXXL+aYb5HilI57pi1vs8QmUpw 6315gXjaJMWdqPif4t5KdblUcU4xj4bWAczFUmaWiHnmiAsGq1to7XPRzwWxOojv2Chi F4bw== X-Received: by 10.42.109.138 with SMTP id l10mr10160677icp.38.1374240763822; Fri, 19 Jul 2013 06:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Fri, 19 Jul 2013 06:32:23 -0700 (PDT) In-Reply-To: References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> From: Justin Uberti Date: Fri, 19 Jul 2013 09:32:23 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf303bf8be90697404e1dd5c94 X-Gm-Message-State: ALoCoQmoLAyQucIKU/fEyqeH9lwdjX1S4soIS8eSGM9amMgGIXH440rM25WJvFzhNCPAT0Rs9/qNOwJ3Dxt4HnsynBPU6gXgQGB7LpFUJIrLzJUwKrWwvCySYYwIxSn5DiyJwQyknBvYbQKFex65ok8D2PZaUTDxDVjnioIm96KPhXPQzbdETugS9ozCbosdOwKxSRP08FLi X-Mailman-Approved-At: Fri, 19 Jul 2013 06:34:39 -0700 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" , Adam Fineberg Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:32:46 -0000 --20cf303bf8be90697404e1dd5c94 Content-Type: text/plain; charset=UTF-8 Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba wrote: > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" wrote: > > Bernard, > > Are there other codecs you are thinking should be supported? If it's > generalized I would think we want to be able to cover all known scalable > codecs. I'll look into the H264/SVC fields to see how to encode them in a > generalized header. > > Regards, > Adam > > On 7/18/13 7:40 PM, Bernard Aboba wrote: > > I think it may be possible to generalize this. For example, for H.264/SVC > which can support temporal, spatial and quality scalability, you would need > the quality_id and dependency_id in addition to the temporal_id (what you > call the temporal layer index). > > ------------------------------ > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org; avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the parameter requirements of > all other scalable codecs to be able to generalize. If you'd like to help > specify them, I'd be fine revising the draft to generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it arises with any codec > supporting temporal, spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage of the > VP8 temporal scaling we must get the temporal layer information from the > RTP header which requires us to decrypt the SRTP packets. This is > undesirable both because the middle-box needs to have access to the keys as > well as the because of the added overhead of the decrypt/encrypt cycle. > This draft proposes an RTP header extension that will allow us to use the > VP8 temporal layer information included in the header extension and > therefore do forwarding without SRTP decryption. Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt Date: Tue, 09 Jul 2013 > 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg at vline.com> > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Regards, > Adam > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf303bf8be90697404e1dd5c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8= /9 as well as H.264/5 SVC
that would be a start. It seems doable = to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" &= lt;fineberg@vline.me= > wrote:

=20 =20 =20 =20
Bernard,

Are there other codecs you are thinking should be supported?=C2=A0 If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
=20
I think it may be possible to generalize this.=C2=A0= For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index). =C2=A0=C2=A0

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fine= berg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@i= etf.org; avtext@ie= tf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.=C2=A0 I'm not familiar enough with the paramet= er requirements of all other scalable codecs to be able to generalize.=C2=A0 If you'd like to help specify them, I'd= be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
=20
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
=C2=A0a VP8-specific RTP extension?
=C2=A0
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rt= cweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.co= m

-------- Original Message --------
Subj= ect: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date= : Tue, 09 Jul 2013 10:02:05 -0700
From= : internet-drafts at ietf.org
To:<= /th> Adam Fineberg=C2=A0<finebe= rg at vline.com> 


A new =
version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-=
00.txt
Status:          http://datatr=
acker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ie=
tf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= 

--=20
Regards,
Adam

=20

__________________________________= _____________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--20cf303bf8be90697404e1dd5c94-- From fluffy@iii.ca Fri Jul 19 06:42:52 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001AB11E812C; Fri, 19 Jul 2013 06:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpaSUJ1AYKcx; Fri, 19 Jul 2013 06:42:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6518011E8118; Fri, 19 Jul 2013 06:42:47 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1EF4A509B8; Fri, 19 Jul 2013 09:42:38 -0400 (EDT) References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6 Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 06:42:38 -0700 To: Bernard Aboba Cc: "avtext@ietf.org" , "rtcweb@ietf.org" , Adam Fineberg Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:42:52 -0000 --Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That's the set of codecs that seems interesting to most people right now On Jul 18, 2013, at 10:56 PM, Bernard Aboba wrot= e: > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. >=20 > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" wrote: >=20 >> Bernard, >>=20 >> Are there other codecs you are thinking should be supported? If it's gen= eralized I would think we want to be able to cover all known scalable codecs= . I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. >>=20 >> Regards, >> Adam >>=20 >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>> I think it may be possible to generalize this. For example, for H.264/S= VC which can support temporal, spatial and quality scalability, you would ne= ed the quality_id and dependency_id in addition to the temporal_id (what you= call the temporal layer index). =20 >>>=20 >>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>> From: fineberg@vline.me >>> To: bernard_aboba@hotmail.com >>> CC: rtcweb@ietf.org; avtext@ietf.org >>> Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-a= vtext-temporal-layer-ext-00.txt >>>=20 >>> Bernard, >>>=20 >>> Good question. I'm not familiar enough with the parameter requirements o= f all other scalable codecs to be able to generalize. If you'd like to help= specify them, I'd be fine revising the draft to generalize. >>>=20 >>> Regards, >>> Adam >>>=20 >>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>> Since the need is not codec specific (e.g. it arises with any codec supp= orting temporal, spatial and quality scalability), why=20 >>> a VP8-specific RTP extension?=20 >>> =20 >>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>> From: fineberg@vline.me >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtex= t-temporal-layer-ext-00.txt >>>=20 >>> Hi, >>>=20 >>> I'm working on WebRTC services and have found that while developing serv= ices that forward VP8 video streams if we want to take advantage of the VP8 t= emporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both b= ecause the middle-box needs to have access to the keys as well as the becaus= e of the added overhead of the decrypt/encrypt cycle. This draft proposes an= RTP header extension that will allow us to use the VP8 temporal layer infor= mation included in the header extension and therefore do forwarding without S= RTP decryption. Comments welcome. >>>=20 >>> Regards, >>> Adam Fineberg >>> fineberg at vline.com >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt >>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>> From: internet-drafts at ietf.org >>> To: Adam Fineberg >>>=20 >>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>> has been successfully submitted by Adam Fineberg and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-fineberg-avtext-temporal-layer-ext >>> Revision: 00 >>> Title: A Real-Time Transport Protocol (RTP) Header Extens= ion for VP8 Temporal Layer Information >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL: http://www.ietf.org/internet-drafts/draft-fineberg-avte= xt-temporal-layer-ext-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-t= emporal-layer-ext >>> Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-tempor= al-layer-ext-00 >>>=20 >>>=20 >>> Abstract: >>> This document defines a mechanism by which packets of Real-Time >>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>> indicate, in an RTP header extension, the temporal layer information >>> about the frame encoded in the RTP packet. This information can be >>> used in a middlebox performing bandwidth management of streams >>> without requiring it to decrypt the streams. >>>=20 >>> _______________________________________________ rtcweb mailing list rtcw= eb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>> --=20 >>> Regards, >>> Adam > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
That's the set of codecs that seems interesting to most people right now

On Jul 18, 2013, at 10:56 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam

_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext
--Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6-- From stewe@stewe.org Fri Jul 19 09:03:44 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B8321F85D1; Fri, 19 Jul 2013 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSmr16J+xtRR; Fri, 19 Jul 2013 09:03:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 754D421F85BB; Fri, 19 Jul 2013 09:03:29 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 19 Jul 2013 15:33:03 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.146]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.42]) with mapi id 15.00.0731.000; Fri, 19 Jul 2013 15:33:03 +0000 From: Stephan Wenger To: Justin Uberti , Bernard Aboba Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOhJVBdM05O/fEXUeQN07SatH6lQ== Date: Fri, 19 Jul 2013 15:33:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377424004)(13464003)(377454003)(2473001)(479174003)(16236675002)(76786001)(36756003)(81542001)(54316002)(83072001)(83322001)(74706001)(50986001)(53806001)(31966008)(76482001)(56776001)(4396001)(16406001)(51856001)(69226001)(47976001)(59766001)(8558605003)(47736001)(80022001)(15202345003)(74502001)(74876001)(49866001)(65816001)(81342001)(19580405001)(63696002)(74366001)(76796001)(54356001)(79102001)(74662001)(76176001)(77982001)(47446002)(56816003)(77096001)(19580385001)(46102001)(19580395003)(66066001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB191; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE0E9F569F89Bstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:03:44 -0000 --_000_CE0E9F569F89Bstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for = VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CE0E9F569F89Bstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <733E8B5C549C77459614F7BC7CA923A3@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 = that has already been demonstrated.  For H.265, some initial thoughts = below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under developm= ent.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/= wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and t= here may well be cases where different pruning strategies may be advisable.=  For example, a layering structure could be constructed that expands = into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By lo= oking at the six bit field alone, a middle box will not be able to meaningf= ully remove NAL units belonging to one of the branches completely while pru= ning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the = dimension_id[][] (and associated control info) in the header extension, or = require the middle box to have access to the VPS and be able to interpret i= ts content.  The further could take considerably more than 16 bits and we would be talking about a variable le= ngth data structure.  The latter requires the middle box to have state= and a mechanism to intercept the VPS (through signaling=97as the encrypted= in-band VPS would not be useful under the assumption that the middle box does not have the key to the media=97wh= ich is the motivation of the draft in the first place).  I personally = don't mind at all the second mechanism, as I'm a big fan of out-of-band par= ameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. &= nbsp;I do not like the first option due to its variable, and possibly subst= antial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32 <= br> To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <= avtext@ietf.org>, "rtcweb@ie= tf.org" <rtcweb@ietf.org= >
Subject: Re: [rtcweb] Fwd: New Vers= ion Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard_= aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For e= xample, for H.264/SVC which can support temporal, spatial and quality scala= bility, you would need the quality_id and dependency_id in addition to the = temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline= .me
To: bernard_= aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with = any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline= .me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on = WebRTC services and have found that while developing services that forward = VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer infor= mation from the RTP header which requires us to decrypt the SRTP packets. T= his is undesirable both because the middle-box needs to have access to the = keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP he= ader extension that will allow us to use the VP8 temporal layer information= included in the header extension and therefore do forwarding without SRTP = decryption. Comments welcome.

Regards,=
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-0= 0.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com><= /td> 


A new version of I-D, dr=
aft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-=
00.txt
Status:          http://datatr=
acker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ie=
tf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--=20
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


 --_000_CE0E9F569F89Bstewesteweorg_-- From csp@csperkins.org Fri Jul 19 13:34:16 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877811E8184 for ; Fri, 19 Jul 2013 13:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDq4gFLI26uf for ; Fri, 19 Jul 2013 13:34:11 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0111E80D3 for ; Fri, 19 Jul 2013 13:34:11 -0700 (PDT) Received: from [81.187.2.149] (port=40535 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V0HNQ-0006AD-Jx for avtext@ietf.org; Fri, 19 Jul 2013 21:34:10 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06AD4E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 19 Jul 2013 21:34:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <381F511C-3377-4D3E-848F-50CC1D7DD017@csperkins.org> References: <949EF20990823C4C85C18D59AA11AD8B06AD4E@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "avtext@ietf.org" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:34:16 -0000 On 16 Jul 2013, at 15:53, wrote: > (As AVTEXT WG cochair) >=20 > The latest version of the taxonomy draft has been submitted >=20 > = https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonom= y/=20 >=20 > This document was allocated to AVTEXT by dispatch, and we have created = a milestone for it in AVTEXT. >=20 > This draft is not yet a working group document. >=20 > We do expect to spend some significant time discussing the contents in = the AVTEXT meeting in Berlin, so please start raising your issues on the = AVTEXT list. This looks like a very useful document, that will hopefully avoid some = confusion in future. Some brief comments: - Section 2.4.2 incorrectly expands RTCP as "Real-time Transport Control = Protocol", and should be "RTP Control Protocol". - Section 2.6.2, 2nd bullet: it might be useful to explain that multiple = RTP sessions can only be multiplexed over a single transport flow if = some sort of shim is included in the packets to distinguish the sessions = (the referenced draft-westerlund-avtcore-transport-multiplexing = describes why this has to be the case in detail, but I think the = high-level point is important to cover in this draft too). I also think = the term "session multiplexing" is unclear about what is multiplexed, = and would prefer it not be used. - Section 2.9.1: I'm not sure an m=3D line description the configuration = required to decode a media stream. It might be better to say the = combination of an m=3D line, the associated payload format mapping in = the associated a=3Drtpmap: lines, and the payload format parameters in = a=3Dfmtp: lines define the configuration required to decode a media = stream. Just the m=3D line is only sufficient for the trivial static = payload types. - Section 2.10: what's the relationship between a "participant" and an = "end point"? - Section 2.11.2: I'm not sure an RTCP CNAME can identify a participant = in an RTP multimedia session; the RTCP CNAME describes a synchronisation = context, but a participant can generate multiple unsynchronised media = streams. - Section 3.1.1: note that RTP uses NTP-format timestamps, but doesn't = require the clock be synchronised to NTP. This section can be mis-read = as requiring the use of NTP, rather than just the timestamp format of = NTP. - Section 4: it might be appropriate to highlight the confusion between = RTCP SDES and RTP security descriptions, since both are referred to as = "SDES" frequently. --=20 Colin Perkins http://csperkins.org/ From fineberg@vline.me Fri Jul 19 15:05:49 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED09221E8095 for ; Fri, 19 Jul 2013 15:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWwHLjKbnO-n for ; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 76C7811E80DF for ; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so4864056pbc.25 for ; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=h6itxt8p4lQshvnI0ZZsAKYZlYdgHCis1fPfG09tCIE=; b=G9yU/Hki/QpIM61ulkiF9R4z2LVf39tVe51oJFxu3wLjPTG5XolJ4kHdslYooJ0ri1 yC7STAYYMX5VV0Z0QZu231hFZOVqVwK8haN4qz6UKc0m+ty/grJh359030/47Tq1AUXg ns5P1GC9yEj8FNjnzapSJ34j5LSVB+7HyklhnV0+slmDf61nGr+FQRHVpSBUylMNPwk2 9fj8M6G8S+QxD2OPB6pCS5x+c/UV1+qwcqU2OAl6ZDNZK3d6ALgZpNdVrZuVMV+AWMTN EfOkwJUkQliRbtVme2205OOCDGCBXgTvk0tYHjNuSj5jz1zgpQVz5oGYlIUeWdz/uTg7 tZKw== X-Received: by 10.66.145.34 with SMTP id sr2mr20314179pab.94.1374271544051; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id nv6sm21574817pbc.6.2013.07.19.15.05.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 15:05:42 -0700 (PDT) Message-ID: <51E9B833.4080405@vline.me> Date: Fri, 19 Jul 2013 15:05:39 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010405070100060106030201" X-Gm-Message-State: ALoCoQmB8gEpsNHuScaygs0lQKO7ZwJSKdcuz4WGV/oO+oApreHQWwTRzW7Ao2Z53ifKgTW7N9pJ Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:05:49 -0000 This is a multi-part message in MIME format. --------------010405070100060106030201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Bernard, I'll take a look at the other codecs to see what fields are needed and how to encode them in the header. Any help is appreciated as I'm not that familiar with H.264 and not at all familiar with H.265. Regards, Adam On 7/18/13 10:56 PM, Bernard Aboba wrote: > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: > >> Bernard, >> >> Are there other codecs you are thinking should be supported? If it's >> generalized I would think we want to be able to cover all known >> scalable codecs. I'll look into the H264/SVC fields to see how to >> encode them in a generalized header. >> >> Regards, >> Adam >> >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>> I think it may be possible to generalize this. For example, for >>> H.264/SVC which can support temporal, spatial and quality >>> scalability, you would need the quality_id and dependency_id in >>> addition to the temporal_id (what you call the temporal layer index). >>> >>> ------------------------------------------------------------------------ >>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>> From: fineberg@vline.me >>> To: bernard_aboba@hotmail.com >>> CC: rtcweb@ietf.org; avtext@ietf.org >>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Bernard, >>> >>> Good question. I'm not familiar enough with the parameter >>> requirements of all other scalable codecs to be able to generalize. >>> If you'd like to help specify them, I'd be fine revising the draft >>> to generalize. >>> >>> Regards, >>> Adam >>> >>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>> >>> Since the need is not codec specific (e.g. it arises with any >>> codec supporting temporal, spatial and quality scalability), why >>> a VP8-specific RTP extension? >>> >>> ------------------------------------------------------------------------ >>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>> From: fineberg@vline.me >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Hi, >>> >>> I'm working on WebRTC services and have found that while >>> developing services that forward VP8 video streams if we want to >>> take advantage of the VP8 temporal scaling we must get the >>> temporal layer information from the RTP header which requires us >>> to decrypt the SRTP packets. This is undesirable both because >>> the middle-box needs to have access to the keys as well as the >>> because of the added overhead of the decrypt/encrypt cycle. This >>> draft proposes an RTP header extension that will allow us to use >>> the VP8 temporal layer information included in the header >>> extension and therefore do forwarding without SRTP decryption. >>> Comments welcome. >>> >>> Regards, >>> Adam Fineberg >>> fineberg at vline.com >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>> From: internet-drafts at ietf.org >>> >>> To: Adam Fineberg >>> >>> >>> >>> >>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>> has been successfully submitted by Adam Fineberg and posted to the >>> IETF repository. >>> >>> Filename: draft-fineberg-avtext-temporal-layer-ext >>> Revision: 00 >>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>> >>> >>> Abstract: >>> This document defines a mechanism by which packets of Real-Time >>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>> indicate, in an RTP header extension, the temporal layer information >>> about the frame encoded in the RTP packet. This information can be >>> used in a middlebox performing bandwidth management of streams >>> without requiring it to decrypt the streams. >>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> -- >>> Regards, >>> Adam >> -- Regards, Adam --------------010405070100060106030201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Bernard,

I'll take a look at the other codecs to see what fields are needed and how to encode them in the header.  Any help is appreciated as I'm not that familiar with H.264 and not at all familiar with H.265.

Regards,
Adam

On 7/18/13 10:56 PM, Bernard Aboba wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam


-- 
Regards,
Adam
--------------010405070100060106030201-- From fineberg@vline.me Fri Jul 19 15:12:58 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9902B21E8091 for ; Fri, 19 Jul 2013 15:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzlKShwIbMbu for ; Fri, 19 Jul 2013 15:12:54 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 351D521E8097 for ; Fri, 19 Jul 2013 15:12:54 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf11so4919172pab.24 for ; Fri, 19 Jul 2013 15:12:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=9GecPUwrpSOQTmG/q+OdLS5or3Gm+3/b/9/ZgxjEoto=; b=O9e73pvIqi9MVvQcMEmiRWyqZeez5hAGEQQQnrX8vaWuDK5C2EFdLKt64qKqAUtdY3 dXIzbrJNJSSE22fxBin7+osAiZDGHmtX+sK6/nactcwkZbSARXWGLZMO8Lwk2f9GLDcO vkTMEhwdqqp1UNl1b350e6tYrMcwCzVKG6W2fdGYwHFYJhpSfVvbAj2XCDBIPVTGwFoX Gm6B6o7yGMUSzQwPkDZXYhblccOJu0pPPEAMnlpYruVHUsiis4YtSkibTwcI/rCvgHWR /lRYRIB1nIFNvIFLuOwkhJ+y8mxfWm7rAfkjRcLUsyQCD3tYkK0/E8LiEdChKS+ZPVSO ndOw== X-Received: by 10.68.197.136 with SMTP id iu8mr19203950pbc.183.1374271973860; Fri, 19 Jul 2013 15:12:53 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id wr9sm21596801pbc.7.2013.07.19.15.12.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 15:12:52 -0700 (PDT) Message-ID: <51E9B9E1.3070006@vline.me> Date: Fri, 19 Jul 2013 15:12:49 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303050707070804040104" X-Gm-Message-State: ALoCoQk0hbcVuC1LRmyfNnMMJVmcAIsdxfQav12isX9qtlx47rTVFCHCSGBsFWqYuZzbFp0nss/s Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:12:58 -0000 This is a multi-part message in MIME format. --------------060303050707070804040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at all familiar with H.265. I'll review the reference and see what I can figure. It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly? There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension. Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: > Hi, > I also believe that 16 bits should be enough. For H.264 and VP8 that > has already been demonstrated. For H.265, some initial thoughts > below. Apologies for the word-count. > > The scalable version of H265 (called SHVC) is currently under > development. The current working draft can be found here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. > Therein, the options for defining layering structures are > considerably more complex. To start, we have 3 bits for the temporal > ID in the NAL unit header of the H.265 version 1 (HEVC) base > specification (temporal scalability is already nicely supported in > version 1). Just like in SVC. In the scalable extension, the NAL > unit header contains a six bit field that points into a data structure > known as "Video Parameter Set" (VPS). Inside the VPS, those six bits > are mapped to to a position in a directed graph (specified through > "dimension_id[][]"), which tells you about the reference relationship > of the layer in question and its parent layer. One can recursively > follow the graph to determine what used to be called dependency_id, > quality_id, view_id, and whatnot. The six bit pointer field can (or: > is to be when possible) organized by the encoder such that it is > prudent for a middle box to throw away NAL units (belonging to layers) > with higher values of the six bit field first, before throwing away > NAL units with lower values. Relying on this feature, 3+6 bits == 9 > bits should be fine for the header extension. > > That said, the ordering by the encoder is just a recommendation, and > there may well be cases where different pruning strategies may be > advisable. For example, a layering structure could be constructed > that expands into two branches, one using 2D scalable tools only, the > other including view_id for multi view coding. By looking at the six > bit field alone, a middle box will not be able to meaningfully remove > NAL units belonging to one of the branches completely while pruning > the other branch. In order to meaningfully deal with that scenario, > there would be two options: one to represent the dimension_id[][] (and > associated control info) in the header extension, or require the > middle box to have access to the VPS and be able to interpret its > content. The further could take considerably more than 16 bits and we > would be talking about a variable length data structure. The latter > requires the middle box to have state and a mechanism to intercept the > VPS (through signaling---as the encrypted in-band VPS would not be > useful under the assumption that the middle box does not have the key > to the media---which is the motivation of the draft in the first > place). I personally don't mind at all the second mechanism, as I'm a > big fan of out-of-band parameter set transmission and any middle box > must be in the signaling path anyway to meaningfully manipulate RTP. > I do not like the first option due to its variable, and possibly > substantial, overhead. > > Stephan > > > From: Justin Uberti > > Date: Friday, 19 July, 2013 06:32 > To: Bernard Aboba > > Cc: "avtext@ietf.org " >, "rtcweb@ietf.org " > > > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Agree those are the right codecs to design for. Since in each case > there are fairly low limits on the number of supported layers (i.e. 3 > spatial layers for SVC), I think it should be possible to pack the > temporal, spatial, quality layer ids into 16 bits. > > > On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > > wrote: > > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: > >> Bernard, >> >> Are there other codecs you are thinking should be supported? If >> it's generalized I would think we want to be able to cover all >> known scalable codecs. I'll look into the H264/SVC fields to see >> how to encode them in a generalized header. >> >> Regards, >> Adam >> >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>> I think it may be possible to generalize this. For example, for >>> H.264/SVC which can support temporal, spatial and quality >>> scalability, you would need the quality_id and dependency_id in >>> addition to the temporal_id (what you call the temporal layer >>> index). >>> >>> ------------------------------------------------------------------------ >>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>> From: fineberg@vline.me >>> To: bernard_aboba@hotmail.com >>> CC: rtcweb@ietf.org ; avtext@ietf.org >>> >>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Bernard, >>> >>> Good question. I'm not familiar enough with the parameter >>> requirements of all other scalable codecs to be able to >>> generalize. If you'd like to help specify them, I'd be fine >>> revising the draft to generalize. >>> >>> Regards, >>> Adam >>> >>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>> >>> Since the need is not codec specific (e.g. it arises with >>> any codec supporting temporal, spatial and quality >>> scalability), why >>> a VP8-specific RTP extension? >>> >>> ------------------------------------------------------------------------ >>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>> From: fineberg@vline.me >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Hi, >>> >>> I'm working on WebRTC services and have found that while >>> developing services that forward VP8 video streams if we >>> want to take advantage of the VP8 temporal scaling we must >>> get the temporal layer information from the RTP header which >>> requires us to decrypt the SRTP packets. This is undesirable >>> both because the middle-box needs to have access to the keys >>> as well as the because of the added overhead of the >>> decrypt/encrypt cycle. This draft proposes an RTP header >>> extension that will allow us to use the VP8 temporal layer >>> information included in the header extension and therefore >>> do forwarding without SRTP decryption. Comments welcome. >>> >>> Regards, >>> Adam Fineberg >>> fineberg at vline.com >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>> From: internet-drafts at ietf.org >>> >>> To: Adam Fineberg >>> >>> >>> >>> >>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>> has been successfully submitted by Adam Fineberg and posted to the >>> IETF repository. >>> >>> Filename: draft-fineberg-avtext-temporal-layer-ext >>> Revision: 00 >>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>> >>> >>> Abstract: >>> This document defines a mechanism by which packets of Real-Time >>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>> indicate, in an RTP header extension, the temporal layer information >>> about the frame encoded in the RTP packet. This information can be >>> used in a middlebox performing bandwidth management of streams >>> without requiring it to decrypt the streams. >>> >>> >>> _______________________________________________ rtcweb >>> mailing list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> -- >>> Regards, >>> Adam >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext -- Regards, Adam --------------060303050707070804040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure.  It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


 

_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext


-- 
Regards,
Adam
--------------060303050707070804040104-- From stewe@stewe.org Fri Jul 19 15:44:20 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C0B11E81AC; Fri, 19 Jul 2013 15:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTa58rRyTcpr; Fri, 19 Jul 2013 15:44:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9B521F94DC; Fri, 19 Jul 2013 15:44:15 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 19 Jul 2013 22:44:13 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.146]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.42]) with mapi id 15.00.0731.000; Fri, 19 Jul 2013 22:44:13 +0000 From: Stephan Wenger To: Adam Fineberg Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOhJVBdM05O/fEXUeQN07SatH6lZlskQqA//+TZwA= Date: Fri, 19 Jul 2013 22:44:12 +0000 Message-ID: In-Reply-To: <51E9B9E1.3070006@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(24454002)(377424004)(13464003)(377454003)(2473001)(189002)(479174003)(51914003)(16236675002)(76786001)(50986001)(83322001)(54316002)(81542001)(31966008)(36756003)(74706001)(53806001)(83072001)(76482001)(56776001)(4396001)(16406001)(69226001)(47976001)(59766001)(8558605003)(80022001)(47736001)(15202345003)(74876001)(81342001)(74502001)(19580405001)(49866001)(63696002)(76796001)(74366001)(56816003)(65816001)(51856001)(19580385001)(54356001)(76176001)(79102001)(77982001)(47446002)(77096001)(74662001)(66066001)(46102001)(19580395003)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB191; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE0F0BEB9F95Dstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:44:20 -0000 --_000_CE0F0BEB9F95Dstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams=97ideally not only for scalab= le video, although that is the main customer today. And second, for each "= payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v= 2 (including scalable and 3D extensions, which are not yet finalized), VP8,= and VP9 (I know little about the latter), plus Daala, and whatnot) a mappi= ng of the bits available in the generic header extension to the bits in the= payload itself (NAL header and VPS in case of H.265, NALU header in SVC, a= nd the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for = VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam --_000_CE0F0BEB9F95Dstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <14B1E0B74D0A2245A736553A748CABFC@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12 <= br> To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>,= "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd:= New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.t= xt

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

StW: Good luck :-)  

It seems though to me that you ar= e suggesting that except in the simple case, that the data for H.265 would = not be well suited to a header extension, am I understanding you correctly?=   There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be = within the scope of this header extension.

StW: well, i= f you would copy the layer_id into your header extension (just as you need = to do for the simple case), a really smart middle box could use this inform= ation just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule = out the second option on technical grounds.  Whether any of the actual= products would bother to do that, ever, is another question.  I think= the case ought to be documented, though.  I can help drafting text.
While we are= at it: doing this right could mean that you need multiple specs.  Fir= st, a generic header extension mechanism dedicated to side information requ= ired for pruning of RTP packet streams=97ideally not only for scalable video, although that is the main customer today. &nb= sp;And second, for each "payload" (at present we are talking abou= t H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions,= which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the b= its available in the generic header extension to the bits in the payload it= self (NAL header and VPS in case of H.265, NALU header in SVC, and the fiel= ds you mention for VP8).

Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 = that has already been demonstrated.  For H.265, some initial thoughts = below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under developm= ent.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_u= ser/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and t= here may well be cases where different pruning strategies may be advisable.=  For example, a layering structure could be constructed that expands = into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By lo= oking at the six bit field alone, a middle box will not be able to meaningf= ully remove NAL units belonging to one of the branches completely while pru= ning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the = dimension_id[][] (and associated control info) in the header extension, or = require the middle box to have access to the VPS and be able to interpret i= ts content.  The further could take considerably more than 16 bits and we would be talking about a variable le= ngth data structure.  The latter requires the middle box to have state= and a mechanism to intercept the VPS (through signaling=97as the encrypted= in-band VPS would not be useful under the assumption that the middle box does not have the key to the media=97wh= ich is the motivation of the draft in the first place).  I personally = don't mind at all the second mechanism, as I'm a big fan of out-of-band par= ameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. &= nbsp;I do not like the first option due to its variable, and possibly subst= antial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com&= gt;
Date: Friday, 19 July, 2013 06:32 <= br> To: Bernard Aboba <bernard_aboba@hotm= ail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, = "rtcweb@ie= tf.org" <rtcweb@iet= f.org>
Subject: Re: [rtcweb] Fwd: New Vers= ion Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vl= ine.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For e= xample, for H.264/SVC which can support temporal, spatial and quality scala= bility, you would need the quality_id and dependency_id in addition to the = temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with = any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on = WebRTC services and have found that while developing services that forward = VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer infor= mation from the RTP header which requires us to decrypt the SRTP packets. T= his is undesirable both because the middle-box needs to have access to the = keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP he= ader extension that will allow us to use the VP8 temporal layer information= included in the header extension and therefore do forwarding without SRTP = decryption. Comments welcome.

Regards,=
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-0= 0.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineb= erg at vline.com> 


A new version of I-D, dr=
aft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-a=
vtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-=
layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer=
-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--=20
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb 



_______________________________________________
avtext mailing list
avtex=
t@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

--=20
Regards,
Adam
 --_000_CE0F0BEB9F95Dstewesteweorg_-- From fineberg@vline.me Fri Jul 19 15:54:15 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B091121F8FF3 for ; Fri, 19 Jul 2013 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx+r7nad2Sxh for ; Fri, 19 Jul 2013 15:54:11 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6D94521F962D for ; Fri, 19 Jul 2013 15:53:43 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so4915863pbc.16 for ; Fri, 19 Jul 2013 15:53:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=kNoA5LxJKZ20LHMjfuI3tGyrQXkybzJXu8+etVBNzk8=; b=lq4KfshnI3yUiBXwE+yDi+ZPSDLeSMpg6n7Fx4b5BEhJpWb33234RCbO7uztwVGIpA V6MUbC0Q91p1QkqEleNhzfV+8cTUsHPKRmucdmtyk3kpdflLcdgNxPXZR4pRB5Z6cy8N VVoSarCMhjel0Vw5Kp00w66MQMN9+AorndcY/l7jMc2u7nrkKEP+DEOyGkGDLvlhSOwe VUv0osDW4aHv/0LILu6LNkdKZRaGwnQlspjoomI9zHlBHIgPwuYgeyxWtvgOSeBlUk/m U7EABD2ohNKObcTDwwhNaIPF6p1F5mia/XDLMGVipL+xG8ixFWyRgMw1Zbo16AGC6KWA zH+g== X-Received: by 10.67.21.229 with SMTP id hn5mr20615088pad.135.1374274421939; Fri, 19 Jul 2013 15:53:41 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id xl3sm21677782pbb.17.2013.07.19.15.53.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 15:53:40 -0700 (PDT) Message-ID: <51E9C371.2090905@vline.me> Date: Fri, 19 Jul 2013 15:53:37 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010603030307070406090203" X-Gm-Message-State: ALoCoQmOzzyXTIFrvdaUIa6p251od0vexDi+b8xbic+26ezDnBmqqwomhtEY+RMFf3IOrt4r6nfq Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:54:15 -0000 This is a multi-part message in MIME format. --------------010603030307070406090203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Stephan, On 7/19/13 3:44 PM, Stephan Wenger wrote: > Hi, > > From: Adam Fineberg > > Date: Friday, 19 July, 2013 15:12 > To: Stephan Wenger > > Cc: Justin Uberti >, > Bernard Aboba >, "avtext@ietf.org > " >, > "rtcweb@ietf.org " > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow as I'm > not at all familiar with H.265. I'll review the reference and see > what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in the > simple case, that the data for H.265 would not be well suited to a > header extension, am I understanding you correctly? There is no > reason the middlebox couldn't get out of band signaling of the VPS as > you mention but that would not be within the scope of this header > extension. > > StW: well, if you would copy the layer_id into your header extension > (just as you need to do for the simple case), a really smart middle > box could use this information just as a decoder uses > it, assuming that it intercepted the VPS in the first place. Insofar, > I wouldn't rule out the second option on technical grounds. Whether > any of the actual products would bother to do that, ever, is another > question. I think the case ought to be documented, though. I can > help drafting text. Any help is appreciated. > While we are at it: doing this right could mean that you need multiple > specs. First, a generic header extension mechanism dedicated to side > information required for pruning of RTP packet streamsideally not > only for scalable video, although that is the main customer today. > And second, for each "payload" (at present we are talking about > H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D > extensions, which are not yet finalized), VP8, and VP9 (I know little > about the latter), plus Daala, and whatnot) a mapping of the bits > available in the generic header extension to the bits in the payload > itself (NAL header and VPS in case of H.265, NALU header in SVC, and > the fields you mention for VP8). I was just thinking about that since it seems like the extension payload maybe completely specific and therefore not suitable for the same spec. The problem in my mind with taking the hierarchical a[[roach you mention is that I'm not sure what if any common data is suitable accross all codecs and since there is already a spec for the general header extension, the generic one you mention might be fairly redundant. I'm certainly open to your thoughts though. Regards, Adam > > Stephan > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: >> Hi, >> I also believe that 16 bits should be enough. For H.264 and VP8 that >> has already been demonstrated. For H.265, some initial thoughts >> below. Apologies for the word-count. >> >> The scalable version of H265 (called SHVC) is currently under >> development. The current working draft can be found here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. >> Therein, the options for defining layering structures are >> considerably more complex. To start, we have 3 bits for the temporal >> ID in the NAL unit header of the H.265 version 1 (HEVC) base >> specification (temporal scalability is already nicely supported in >> version 1). Just like in SVC. In the scalable extension, the NAL >> unit header contains a six bit field that points into a data >> structure known as "Video Parameter Set" (VPS). Inside the VPS, >> those six bits are mapped to to a position in a directed graph >> (specified through "dimension_id[][]"), which tells you about the >> reference relationship of the layer in question and its parent layer. >> One can recursively follow the graph to determine what used to be >> called dependency_id, quality_id, view_id, and whatnot. The six bit >> pointer field can (or: is to be when possible) organized by the >> encoder such that it is prudent for a middle box to throw away NAL >> units (belonging to layers) with higher values of the six bit field >> first, before throwing away NAL units with lower values. Relying on >> this feature, 3+6 bits == 9 bits should be fine for the header extension. >> >> That said, the ordering by the encoder is just a recommendation, and >> there may well be cases where different pruning strategies may be >> advisable. For example, a layering structure could be constructed >> that expands into two branches, one using 2D scalable tools only, the >> other including view_id for multi view coding. By looking at the six >> bit field alone, a middle box will not be able to meaningfully remove >> NAL units belonging to one of the branches completely while pruning >> the other branch. In order to meaningfully deal with that scenario, >> there would be two options: one to represent the dimension_id[][] >> (and associated control info) in the header extension, or require the >> middle box to have access to the VPS and be able to interpret its >> content. The further could take considerably more than 16 bits and >> we would be talking about a variable length data structure. The >> latter requires the middle box to have state and a mechanism to >> intercept the VPS (through signalingas the encrypted in-band VPS >> would not be useful under the assumption that the middle box does not >> have the key to the mediawhich is the motivation of the draft in the >> first place). I personally don't mind at all the second mechanism, >> as I'm a big fan of out-of-band parameter set transmission and any >> middle box must be in the signaling path anyway to meaningfully >> manipulate RTP. I do not like the first option due to its variable, >> and possibly substantial, overhead. >> >> Stephan >> >> >> From: Justin Uberti > >> Date: Friday, 19 July, 2013 06:32 >> To: Bernard Aboba > > >> Cc: "avtext@ietf.org " > >, "rtcweb@ietf.org " >> > >> Subject: Re: [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Agree those are the right codecs to design for. Since in each case >> there are fairly low limits on the number of supported layers (i.e. 3 >> spatial layers for SVC), I think it should be possible to pack the >> temporal, spatial, quality layer ids into 16 bits. >> >> >> On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba >> > wrote: >> >> If we can support VP8/9 as well as H.264/5 SVC >> that would be a start. It seems doable to me. >> >> On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: >> >>> Bernard, >>> >>> Are there other codecs you are thinking should be supported? If >>> it's generalized I would think we want to be able to cover all >>> known scalable codecs. I'll look into the H264/SVC fields to see >>> how to encode them in a generalized header. >>> >>> Regards, >>> Adam >>> >>> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>>> I think it may be possible to generalize this. For example, for >>>> H.264/SVC which can support temporal, spatial and quality >>>> scalability, you would need the quality_id and dependency_id in >>>> addition to the temporal_id (what you call the temporal layer >>>> index). >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>>> From: fineberg@vline.me >>>> To: bernard_aboba@hotmail.com >>>> CC: rtcweb@ietf.org ; avtext@ietf.org >>>> >>>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Bernard, >>>> >>>> Good question. I'm not familiar enough with the parameter >>>> requirements of all other scalable codecs to be able to >>>> generalize. If you'd like to help specify them, I'd be fine >>>> revising the draft to generalize. >>>> >>>> Regards, >>>> Adam >>>> >>>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>>> >>>> Since the need is not codec specific (e.g. it arises with >>>> any codec supporting temporal, spatial and quality >>>> scalability), why >>>> a VP8-specific RTP extension? >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>>> From: fineberg@vline.me >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Hi, >>>> >>>> I'm working on WebRTC services and have found that while >>>> developing services that forward VP8 video streams if we >>>> want to take advantage of the VP8 temporal scaling we must >>>> get the temporal layer information from the RTP header >>>> which requires us to decrypt the SRTP packets. This is >>>> undesirable both because the middle-box needs to have >>>> access to the keys as well as the because of the added >>>> overhead of the decrypt/encrypt cycle. This draft proposes >>>> an RTP header extension that will allow us to use the VP8 >>>> temporal layer information included in the header extension >>>> and therefore do forwarding without SRTP decryption. >>>> Comments welcome. >>>> >>>> Regards, >>>> Adam Fineberg >>>> fineberg at vline.com >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>>> From: internet-drafts at ietf.org >>>> >>>> To: Adam Fineberg >>>> >>>> >>>> >>>> >>>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> has been successfully submitted by Adam Fineberg and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-fineberg-avtext-temporal-layer-ext >>>> Revision: 00 >>>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>>> Creation date: 2013-07-08 >>>> Group: Individual Submission >>>> Number of pages: 6 >>>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>>> >>>> >>>> Abstract: >>>> This document defines a mechanism by which packets of Real-Time >>>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>>> indicate, in an RTP header extension, the temporal layer information >>>> about the frame encoded in the RTP packet. This information can be >>>> used in a middlebox performing bandwidth management of streams >>>> without requiring it to decrypt the streams. >>>> >>>> >>>> _______________________________________________ rtcweb >>>> mailing list rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> -- >>>> Regards, >>>> Adam >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext > > -- > Regards, > Adam -- Regards, Adam --------------010603030307070406090203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Stephan,

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Stephan,

Thanks for the info and the reference. I'm not sure I follow as I'm not at all familiar with H.265. I'll review the reference and see what I can figure.

StW: Good luck :-)

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly? There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it,assumingthat it intercepted the VPS in the first place. Insofar, I wouldn't rule out the second option on technical grounds. Whether any of the actual products would bother to do that, ever, is another question. I think the case ought to be documented, though. I can help drafting text.

Any help is appreciated.

While we are at it: doing this right could mean that you need multiple specs. First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streamsideally not only for scalable video, although that is the main customer today. And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

I was just thinking about that since it seems like the extension payload maybe completely specific and therefore not suitable for the same spec. The problem in my mind with taking the hierarchical a[[roach you mention is that I'm not sure what if any common data is suitable accross all codecs and since there is already a spec for the general header extension, the generic one you mention might be fairly redundant.

I'm certainly open to your thoughts though.

Regards,
Adam


Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough. For H.264 and VP8 that has already been demonstrated. For H.265, some initial thoughts below. Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development. The current working draft can be found here:http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the options for defining layering structures are considerably more complex. To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1). Just like in SVC. In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS). Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer. One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot. The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values. Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable. For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding. By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch. In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content. The further could take considerably more than 16 bits and we would be talking about a variable length data structure. The latter requires the middle box to have state and a mechanism to intercept the VPS (through signalingas the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the mediawhich is the motivation of the draft in the first place). I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported? If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this. For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question. I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize. If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
a VP8-specific RTP extension?

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg<fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

-- 
Regards,
Adam
 

-- 
Regards,
Adam
--------------010603030307070406090203-- From bo.burman@ericsson.com Sat Jul 20 04:38:56 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD921F964C for ; Sat, 20 Jul 2013 04:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRkAtTX1vYwG for ; Sat, 20 Jul 2013 04:38:52 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1414021F9A06 for ; Sat, 20 Jul 2013 04:38:51 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-5b-51ea76ca058e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 69.DC.19388.AC67AE15; Sat, 20 Jul 2013 13:38:50 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.204]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 13:38:49 +0200 From: Bo Burman To: Colin Perkins Thread-Topic: [avtext] Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gCelP+AACPJiuI= Date: Sat, 20 Jul 2013 11:38:47 +0000 Message-ID: <0yq1166w0nju2p2cmsl8ag1j.1374320327478@email.android.com> References: <949EF20990823C4C85C18D59AA11AD8B06AD4E@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <381F511C-3377-4D3E-848F-50CC1D7DD017@csperkins.org> In-Reply-To: <381F511C-3377-4D3E-848F-50CC1D7DD017@csperkins.org> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre6psleBBvOv61p8vHeD1WL5yxOM Dkwe0+7fZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfGtpOTmAv6JCq2PH/F3sB4WbiLkZNDQsBE 4sO1ncwQtpjEhXvr2UBsIYHDjBKvjxhD2EsYJY6eKQax2QQ0JObvuMsIYosIqErsOP4PzGYW UJc4vG8JmC0sICdxo38GO0SNvMSjBR+gbCuJPZ1NYDUsQL1zN8wE2svBwSvgJrH2V1YXIxfQ qn5Gia4ZbawgNZwCjhK9y0+C3cYoICtx//s9Fohd4hKf5z5ggrhZQGLJnvNQ94tKvHz8jxWi Rk/ixtQpbBC2tsSyha/BangFBCVOznzCMoFRdBaSUbOQtMxC0jILScsCRpZVjOy5iZk56eXm mxiBkXBwy2+DHYyb7osdYpTmYFES592sdyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+Mq kZt8EtMsVG8IHmkwOPD77r01x75d17F9eSZb+6ap7dejIkfdxWu4f7y5NKlq/fFMP6b+HLG3 GuF7eJuT2mOUOKV1n93UF9/CfvdkaFL/nFI3e6Z3G6o0J/rnzFyzY1f488VJh9ZKSd+/ccJo d4TZD/GVXob2zv94Ei55urkatjbl5IZeFlBiKc5INNRiLipOBACAxmP8UgIAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 11:38:56 -0000 Thank you for very relevant comments. Corresponding changes will be made in= the next draft version. Cheers, Bo Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr=E5n: Colin Perkins Till: "avtext@ietf.org" Skickat: 2013-07-19 10:34 em =C4mne: Re: [avtext] Taxonomy On 16 Jul 2013, at 15:53, wrote: > (As AVTEXT WG cochair) > > The latest version of the taxonomy draft has been submitted > > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxono= my/ > > This document was allocated to AVTEXT by dispatch, and we have created a = milestone for it in AVTEXT. > > This draft is not yet a working group document. > > We do expect to spend some significant time discussing the contents in th= e AVTEXT meeting in Berlin, so please start raising your issues on the AVTE= XT list. This looks like a very useful document, that will hopefully avoid some conf= usion in future. Some brief comments: - Section 2.4.2 incorrectly expands RTCP as "Real-time Transport Control Pr= otocol", and should be "RTP Control Protocol". - Section 2.6.2, 2nd bullet: it might be useful to explain that multiple RT= P sessions can only be multiplexed over a single transport flow if some sor= t of shim is included in the packets to distinguish the sessions (the refer= enced draft-westerlund-avtcore-transport-multiplexing describes why this ha= s to be the case in detail, but I think the high-level point is important t= o cover in this draft too). I also think the term "session multiplexing" is= unclear about what is multiplexed, and would prefer it not be used. - Section 2.9.1: I'm not sure an m=3D line description the configuration re= quired to decode a media stream. It might be better to say the combination = of an m=3D line, the associated payload format mapping in the associated a= =3Drtpmap: lines, and the payload format parameters in a=3Dfmtp: lines defi= ne the configuration required to decode a media stream. Just the m=3D line = is only sufficient for the trivial static payload types. - Section 2.10: what's the relationship between a "participant" and an "end= point"? - Section 2.11.2: I'm not sure an RTCP CNAME can identify a participant in = an RTP multimedia session; the RTCP CNAME describes a synchronisation conte= xt, but a participant can generate multiple unsynchronised media streams. - Section 3.1.1: note that RTP uses NTP-format timestamps, but doesn't requ= ire the clock be synchronised to NTP. This section can be mis-read as requi= ring the use of NTP, rather than just the timestamp format of NTP. - Section 4: it might be appropriate to highlight the confusion between RTC= P SDES and RTP security descriptions, since both are referred to as "SDES" = frequently. -- Colin Perkins http://csperkins.org/ _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From yekuiw@qti.qualcomm.com Sat Jul 20 08:40:09 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B561F0D1D; Sat, 20 Jul 2013 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.223 X-Spam-Level: X-Spam-Status: No, score=-105.223 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvlecyZaWnQs; Sat, 20 Jul 2013 08:40:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8612411E810C; Sat, 20 Jul 2013 08:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374334801; x=1405870801; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mwm9rSlGv23oC79tliCcSi0rPW/VH8jIcHCJI/itmOQ=; b=YAOPb5KUrIcaDYRuNfosuSZs8aYCkC6eeJvOCOeXgThhKnB9NEZDAtaJ JAZbCXdF55p6K8U0MyzPXOIVTuCbSAcV8Jk8ecjo2vDXXU18CK+cuZWbJ qkuFkTNUgD/77L0JPLiB9l4Pm3Hv78WmXj87yvzUi2AZIWI7Lox+yv0J+ M=; X-IronPort-AV: E=Sophos;i="4.89,708,1367996400"; d="scan'208,217";a="63872191" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 20 Jul 2013 08:40:00 -0700 X-IronPort-AV: E=Sophos;i="4.89,708,1367996400"; d="scan'208,217";a="507750403" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jul 2013 08:39:59 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.02.0318.004; Sat, 20 Jul 2013 08:39:59 -0700 From: "Wang, Ye-Kui" To: Adam Fineberg Thread-Topic: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOhNLztWy6humvgkWzyBwOZk2sn5lttSKU Date: Sat, 20 Jul 2013 15:39:58 +0000 Message-ID: <18EEAD91-00D1-4EA3-AC11-6B54C69FBCE0@qti.qualcomm.com> References: ,<51E9C371.2090905@vline.me> In-Reply-To: <51E9C371.2090905@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 20 Jul 2013 17:19:15 -0700 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 15:40:09 -0000 --_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just to mention that the family of 3D codecs based on H.264, incl. MVC, MVC= +D, 3D-AVC, and even MFC, developed or being developed, should also be take= n into consideration. BR, YK On Jul 19, 2013, at 15:54, "Adam Fineberg" > wrote: Stephan, On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. Any help is appreciated. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams=97ideally not only for scalab= le video, although that is the main customer today. And second, for each "= payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v= 2 (including scalable and 3D extensions, which are not yet finalized), VP8,= and VP9 (I know little about the latter), plus Daala, and whatnot) a mappi= ng of the bits available in the generic header extension to the bits in the= payload itself (NAL header and VPS in case of H.265, NALU header in SVC, a= nd the fields you mention for VP8). I was just thinking about that since it seems like the extension payload ma= ybe completely specific and therefore not suitable for the same spec. The = problem in my mind with taking the hierarchical a[[roach you mention is tha= t I'm not sure what if any common data is suitable accross all codecs and s= ince there is already a spec for the general header extension, the generic = one you mention might be fairly redundant. I'm certainly open to your thoughts though. Regards, Adam Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for = VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just to mention that the family of 3D codecs based on H.264, incl. MVC= , MVC+D, 3D-AVC, and even MFC, developed or being developed, should als= o be taken into consideration.

BR, YK

On Jul 19, 2013, at 15:54, "Adam Fineberg" <fineberg@vline.me> wrote:

Stephan,

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>= ;
Date: Friday, 19 July, 2013 15:12 <= br> To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>= ;, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@iet= f.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd:= New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.t= xt

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

StW: Good luck :-) 

It seems though to me that you ar= e suggesting that except in the simple case, that the data for H.265 would = not be well suited to a header extension, am I understanding you correctly?=   There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be = within the scope of this header extension.

StW: well, i= f you would copy the layer_id into your header extension (just as you need = to do for the simple case), a really smart middle box could use this inform= ation just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule = out the second option on technical grounds.  Whether any of the actual= products would bother to do that, ever, is another question.  I think= the case ought to be documented, though.  I can help drafting text.

Any help is appreciated.

While we are= at it: doing this right could mean that you need multiple specs.  Fir= st, a generic header extension mechanism dedicated to side information requ= ired for pruning of RTP packet streams=97ideally not only for scalable video, although that is the main customer today. &nb= sp;And second, for each "payload" (at present we are talking abou= t H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions,= which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the b= its available in the generic header extension to the bits in the payload it= self (NAL header and VPS in case of H.265, NALU header in SVC, and the fiel= ds you mention for VP8).

I was just thinking about that since it seems like the extension payload ma= ybe completely specific and therefore not suitable for the same spec. = The problem in my mind with taking the hierarchical a[[roach you mention i= s that I'm not sure what if any common data is suitable accross all codecs and since there is already a spec for = the general header extension, the generic one you mention might be fairly r= edundant.

I'm certainly open to your thoughts though.

Regards,
Adam


Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 = that has already been demonstrated.  For H.265, some initial thoughts = below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under developm= ent.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_u= ser/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and t= here may well be cases where different pruning strategies may be advisable.=  For example, a layering structure could be constructed that expands = into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By lo= oking at the six bit field alone, a middle box will not be able to meaningf= ully remove NAL units belonging to one of the branches completely while pru= ning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the = dimension_id[][] (and associated control info) in the header extension, or = require the middle box to have access to the VPS and be able to interpret i= ts content.  The further could take considerably more than 16 bits and we would be talking about a variable le= ngth data structure.  The latter requires the middle box to have state= and a mechanism to intercept the VPS (through signaling=97as the encrypted= in-band VPS would not be useful under the assumption that the middle box does not have the key to the media=97wh= ich is the motivation of the draft in the first place).  I personally = don't mind at all the second mechanism, as I'm a big fan of out-of-band par= ameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. &= nbsp;I do not like the first option due to its variable, and possibly subst= antial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com&= gt;
Date: Friday, 19 July, 2013 06:32 <= br> To: Bernard Aboba <bernard_aboba@hotm= ail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, = "rtcweb@ie= tf.org" <rtcweb@iet= f.org>
Subject: Re: [rtcweb] Fwd: New Vers= ion Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vl= ine.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For e= xample, for H.264/SVC which can support temporal, spatial and quality scala= bility, you would need the quality_id and dependency_id in addition to the = temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with = any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on = WebRTC services and have found that while developing services that forward = VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer infor= mation from the RTP header which requires us to decrypt the SRTP packets. T= his is undesirable both because the middle-box needs to have access to the = keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP he= ader extension that will allow us to use the VP8 temporal layer information= included in the header extension and therefore do forwarding without SRTP = decryption. Comments welcome.

Regards,=
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-0= 0.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineb= erg at vline.com> 


A new version of I-D, dr=
aft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-a=
vtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-=
layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer=
-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--=20
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb 



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

--=20
Regards,
Adam

--=20
Regards,
Adam
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_-- From fineberg@vline.me Tue Jul 23 08:54:06 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89BC11E829F for ; Tue, 23 Jul 2013 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGIqyIQKZeVK for ; Tue, 23 Jul 2013 08:54:02 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id E81F811E82A0 for ; Tue, 23 Jul 2013 08:53:57 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so11790376oag.9 for ; Tue, 23 Jul 2013 08:53:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=53DL/pek2wjS9D9twCG6bXHCH+MA9iHMMldP9bTnib8=; b=ZhGblWCq/EocL/JCBIiDi+81Gc4kmiZpJDp54TCnkis6+sqjI0662yr28O2Fg2nJgj 42O6Tslc22BhLdzhymGIQvxKG916e3ztBjVNIN7Gj6YWp0tuodC4sESN1Uspf7OBXi95 dscCljcD8sg2lvpY3XSa9lak0MC0jl6qAzRsbO0EpBIoflJzMIJe3h+eFDGk41eeR99B 4pFnxphPWSoCm2V/0Lp4IxKhMBidJMO5+hVnVPfHcMU0Iu4bF8tO+PGkZAyCrn0bnAS8 +w6Wd3deVrC+EepkhWGkfyywOcNNNrje0XGI0zMLIA3ZEh/+OLyFHntBD+7AIhGqvLRr 4Mvg== X-Received: by 10.42.76.5 with SMTP id c5mr19070653ick.91.1374594828199; Tue, 23 Jul 2013 08:53:48 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id fu2sm3985149igb.3.2013.07.23.08.53.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 08:53:47 -0700 (PDT) Message-ID: <51EEA709.2020009@vline.me> Date: Tue, 23 Jul 2013 08:53:45 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030303020303070209040705" X-Gm-Message-State: ALoCoQnUkWwjGMUZRm49WnSGVX3gyKrc2VFKXZOCl431lsgdIl9xzyKMi+6VB3tecnwCoENfcRG7 Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:54:06 -0000 This is a multi-part message in MIME format. --------------030303020303070209040705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach. I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: > Hi, > > From: Adam Fineberg > > Date: Friday, 19 July, 2013 15:12 > To: Stephan Wenger > > Cc: Justin Uberti >, > Bernard Aboba >, "avtext@ietf.org > " >, > "rtcweb@ietf.org " > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow as I'm > not at all familiar with H.265. I'll review the reference and see > what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in the > simple case, that the data for H.265 would not be well suited to a > header extension, am I understanding you correctly? There is no > reason the middlebox couldn't get out of band signaling of the VPS as > you mention but that would not be within the scope of this header > extension. > > StW: well, if you would copy the layer_id into your header extension > (just as you need to do for the simple case), a really smart middle > box could use this information just as a decoder uses > it, assuming that it intercepted the VPS in the first place. Insofar, > I wouldn't rule out the second option on technical grounds. Whether > any of the actual products would bother to do that, ever, is another > question. I think the case ought to be documented, though. I can > help drafting text. > While we are at it: doing this right could mean that you need multiple > specs. First, a generic header extension mechanism dedicated to side > information required for pruning of RTP packet streamsideally not > only for scalable video, although that is the main customer today. > And second, for each "payload" (at present we are talking about > H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D > extensions, which are not yet finalized), VP8, and VP9 (I know little > about the latter), plus Daala, and whatnot) a mapping of the bits > available in the generic header extension to the bits in the payload > itself (NAL header and VPS in case of H.265, NALU header in SVC, and > the fields you mention for VP8). > > Stephan > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: >> Hi, >> I also believe that 16 bits should be enough. For H.264 and VP8 that >> has already been demonstrated. For H.265, some initial thoughts >> below. Apologies for the word-count. >> >> The scalable version of H265 (called SHVC) is currently under >> development. The current working draft can be found here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. >> Therein, the options for defining layering structures are >> considerably more complex. To start, we have 3 bits for the temporal >> ID in the NAL unit header of the H.265 version 1 (HEVC) base >> specification (temporal scalability is already nicely supported in >> version 1). Just like in SVC. In the scalable extension, the NAL >> unit header contains a six bit field that points into a data >> structure known as "Video Parameter Set" (VPS). Inside the VPS, >> those six bits are mapped to to a position in a directed graph >> (specified through "dimension_id[][]"), which tells you about the >> reference relationship of the layer in question and its parent layer. >> One can recursively follow the graph to determine what used to be >> called dependency_id, quality_id, view_id, and whatnot. The six bit >> pointer field can (or: is to be when possible) organized by the >> encoder such that it is prudent for a middle box to throw away NAL >> units (belonging to layers) with higher values of the six bit field >> first, before throwing away NAL units with lower values. Relying on >> this feature, 3+6 bits == 9 bits should be fine for the header extension. >> >> That said, the ordering by the encoder is just a recommendation, and >> there may well be cases where different pruning strategies may be >> advisable. For example, a layering structure could be constructed >> that expands into two branches, one using 2D scalable tools only, the >> other including view_id for multi view coding. By looking at the six >> bit field alone, a middle box will not be able to meaningfully remove >> NAL units belonging to one of the branches completely while pruning >> the other branch. In order to meaningfully deal with that scenario, >> there would be two options: one to represent the dimension_id[][] >> (and associated control info) in the header extension, or require the >> middle box to have access to the VPS and be able to interpret its >> content. The further could take considerably more than 16 bits and >> we would be talking about a variable length data structure. The >> latter requires the middle box to have state and a mechanism to >> intercept the VPS (through signalingas the encrypted in-band VPS >> would not be useful under the assumption that the middle box does not >> have the key to the mediawhich is the motivation of the draft in the >> first place). I personally don't mind at all the second mechanism, >> as I'm a big fan of out-of-band parameter set transmission and any >> middle box must be in the signaling path anyway to meaningfully >> manipulate RTP. I do not like the first option due to its variable, >> and possibly substantial, overhead. >> >> Stephan >> >> >> From: Justin Uberti > >> Date: Friday, 19 July, 2013 06:32 >> To: Bernard Aboba > > >> Cc: "avtext@ietf.org " > >, "rtcweb@ietf.org " >> > >> Subject: Re: [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Agree those are the right codecs to design for. Since in each case >> there are fairly low limits on the number of supported layers (i.e. 3 >> spatial layers for SVC), I think it should be possible to pack the >> temporal, spatial, quality layer ids into 16 bits. >> >> >> On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba >> > wrote: >> >> If we can support VP8/9 as well as H.264/5 SVC >> that would be a start. It seems doable to me. >> >> On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: >> >>> Bernard, >>> >>> Are there other codecs you are thinking should be supported? If >>> it's generalized I would think we want to be able to cover all >>> known scalable codecs. I'll look into the H264/SVC fields to see >>> how to encode them in a generalized header. >>> >>> Regards, >>> Adam >>> >>> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>>> I think it may be possible to generalize this. For example, for >>>> H.264/SVC which can support temporal, spatial and quality >>>> scalability, you would need the quality_id and dependency_id in >>>> addition to the temporal_id (what you call the temporal layer >>>> index). >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>>> From: fineberg@vline.me >>>> To: bernard_aboba@hotmail.com >>>> CC: rtcweb@ietf.org ; avtext@ietf.org >>>> >>>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Bernard, >>>> >>>> Good question. I'm not familiar enough with the parameter >>>> requirements of all other scalable codecs to be able to >>>> generalize. If you'd like to help specify them, I'd be fine >>>> revising the draft to generalize. >>>> >>>> Regards, >>>> Adam >>>> >>>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>>> >>>> Since the need is not codec specific (e.g. it arises with >>>> any codec supporting temporal, spatial and quality >>>> scalability), why >>>> a VP8-specific RTP extension? >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>>> From: fineberg@vline.me >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Hi, >>>> >>>> I'm working on WebRTC services and have found that while >>>> developing services that forward VP8 video streams if we >>>> want to take advantage of the VP8 temporal scaling we must >>>> get the temporal layer information from the RTP header >>>> which requires us to decrypt the SRTP packets. This is >>>> undesirable both because the middle-box needs to have >>>> access to the keys as well as the because of the added >>>> overhead of the decrypt/encrypt cycle. This draft proposes >>>> an RTP header extension that will allow us to use the VP8 >>>> temporal layer information included in the header extension >>>> and therefore do forwarding without SRTP decryption. >>>> Comments welcome. >>>> >>>> Regards, >>>> Adam Fineberg >>>> fineberg at vline.com >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>>> From: internet-drafts at ietf.org >>>> >>>> To: Adam Fineberg >>>> >>>> >>>> >>>> >>>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> has been successfully submitted by Adam Fineberg and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-fineberg-avtext-temporal-layer-ext >>>> Revision: 00 >>>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>>> Creation date: 2013-07-08 >>>> Group: Individual Submission >>>> Number of pages: 6 >>>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>>> >>>> >>>> Abstract: >>>> This document defines a mechanism by which packets of Real-Time >>>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>>> indicate, in an RTP header extension, the temporal layer information >>>> about the frame encoded in the RTP packet. This information can be >>>> used in a middlebox performing bandwidth management of streams >>>> without requiring it to decrypt the streams. >>>> >>>> >>>> _______________________________________________ rtcweb >>>> mailing list rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> -- >>>> Regards, >>>> Adam >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext > > -- > Regards, > Adam -- Regards, Adam --------------030303020303070209040705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach. I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Stephan,

Thanks for the info and the reference. I'm not sure I follow as I'm not at all familiar with H.265. I'll review the reference and see what I can figure.

StW: Good luck :-)

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly? There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it,assumingthat it intercepted the VPS in the first place. Insofar, I wouldn't rule out the second option on technical grounds. Whether any of the actual products would bother to do that, ever, is another question. I think the case ought to be documented, though. I can help drafting text.
While we are at it: doing this right could mean that you need multiple specs. First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streamsideally not only for scalable video, although that is the main customer today. And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough. For H.264 and VP8 that has already been demonstrated. For H.265, some initial thoughts below. Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development. The current working draft can be found here:http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the options for defining layering structures are considerably more complex. To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1). Just like in SVC. In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS). Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer. One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot. The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values. Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable. For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding. By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch. In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content. The further could take considerably more than 16 bits and we would be talking about a variable length data structure. The latter requires the middle box to have state and a mechanism to intercept the VPS (through signalingas the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the mediawhich is the motivation of the draft in the first place). I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported? If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this. For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question. I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize. If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
a VP8-specific RTP extension?

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg<fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

-- 
Regards,
Adam
 

-- 
Regards,
Adam
--------------030303020303070209040705-- From bernard_aboba@hotmail.com Tue Jul 23 12:07:28 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C359911E838B; Tue, 23 Jul 2013 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JH9LhxiKR63; Tue, 23 Jul 2013 12:07:24 -0700 (PDT) Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by ietfa.amsl.com (Postfix) with ESMTP id D20AD11E8380; Tue, 23 Jul 2013 12:07:17 -0700 (PDT) Received: from BLU169-W20 ([65.55.111.137]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jul 2013 12:07:16 -0700 X-TMN: [Y5DyEb8sefXyStR6BBh9THoqYNyO9u/j] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_788a735f-7672-45a0-80b1-0a9af35b1860_" From: Bernard Aboba To: Adam Fineberg Date: Tue, 23 Jul 2013 12:07:16 -0700 Importance: Normal In-Reply-To: <51EEA709.2020009@vline.me> References: ,<51EEA709.2020009@vline.me> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2013 19:07:16.0604 (UTC) FILETIME=[D8D773C0:01CE87D7] Cc: "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:07:28 -0000 --_788a735f-7672-45a0-80b1-0a9af35b1860_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I do not think it is necessary to "support all forms of scalability for all= codecs". In fact=2C I would make that an explicit "non-goal". All that = was suggested is to try to create a single extension that supports a few co= mmon cases. If it is possible to handle VP8=2C VP9 and H.264/SVC in a sin= gle extension that would be sufficient. So why not limit it to that?=20 Date: Tue=2C 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com=3B bernard_aboba@hotmail.com=3B avtext@ietf.org=3B r= tcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt =0A= =0A= =0A= =0A= =0A= I've been thinking about this and given the ease at which RFC5285=0A= allows for the specification of a header extension and the=0A= complexity introduced by trying to generalize the header extension=0A= to support all forms of scalability for all codecs that the=0A= generalization might not be the best approach. I'm not sure what we=0A= really gain by trying to capture all this in a single header=0A= extension rather than one per that can succinctly explain the fields=0A= without the complexity of multiplexing the bits. =0A= =20 =0A= Thoughts? =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/19/13 3:44 PM=2C Stephan Wenger=0A= wrote: =0A= =0A= =0A= =0A= Hi=2C=0A= =0A= =20 =0A= =0A= =0A= =0A= From: Adam Fineberg=0A= =0A= Date: Friday=2C 19 July=2C=0A= 2013 15:12=20 =0A= To: Stephan Wenger =0A= Cc: Justin Uberti =2C=0A= Bernard Aboba =2C=0A= "avtext@ietf.org"=0A= =2C=0A= "rtcweb@ietf.org"=0A= =0A= Subject: Re: [avtext]=0A= [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =0A= =20 =0A= =0A= =0A= Stephan=2C =0A= =20 =0A= Thanks for the info and the reference. I'm not sure I=0A= follow as I'm not at all familiar with H.265. I'll review=0A= the reference and see what I can figure. =0A= =0A= =0A= =0A= =20 =0A= =0A= StW: Good luck :-) =0A= =0A= =20 =0A= =0A= =0A= =0A= It seems though to me=0A= that you are suggesting that except in the simple case=2C that= =0A= the data for H.265 would not be well suited to a header=0A= extension=2C am I understanding you correctly? There is no=0A= reason the middlebox couldn't get out of band signaling of=0A= the VPS as you mention but that would not be within the=0A= scope of this header extension.=0A= =0A= =0A= =0A= =20 =0A= =0A= StW:=0A= well=2C if you would copy the layer_id into your header=0A= extension (just as you need to do for the simple case)=2C a=0A= really smart middle box could use this information just as a=0A= decoder uses it=2C assuming that it intercepted the VPS in the= =0A= first place. Insofar=2C I wouldn't rule out the second option= =0A= on technical grounds. Whether any of the actual products=0A= would bother to do that=2C ever=2C is another question. I thin= k=0A= the case ought to be documented=2C though. I can help=0A= drafting text.=0A= While=0A= we are at it: doing this right could mean that you need=0A= multiple specs. First=2C a generic header extension mechanism= =0A= dedicated to side information required for pruning of RTP=0A= packet streams=97ideally not only for scalable video=2C althoug= h=0A= that is the main customer today. And second=2C for each=0A= "payload" (at present we are talking about H.264/SVC=2C=0A= H.265v1 (HEVC)=2C H.265v2 (including scalable and 3D=0A= extensions=2C which are not yet finalized)=2C VP8=2C and VP9 (I= =0A= know little about the latter)=2C plus Daala=2C and whatnot) a= =0A= mapping of the bits available in the generic header=0A= extension to the bits in the payload itself (NAL header and=0A= VPS in case of H.265=2C NALU header in SVC=2C and the fields yo= u=0A= mention for VP8).=0A= =20 =0A= =0A= Stephan=0A= =0A= =0A= =20 =0A= =20 =0A= Any insights are appreciated. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/19/13 8:33 AM=2C Stephan=0A= Wenger wrote: =0A= =0A= =0A= Hi=2C=0A= I also believe that 16 bits should be enough. For=0A= H.264 and VP8 that has already been demonstrated. For=0A= H.265=2C some initial thoughts below. Apologies for the=0A= word-count.=0A= =20 =0A= =0A= The scalable version of H265 (called SHVC) is=0A= currently under development. The current working draft=0A= can be found here: http://phenix.int-evry.fr/jct/doc_end_us= er/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.=0A= Therein=2C the options for defining layering structures=0A= are considerably more complex. To start=2C we have 3 bits= =0A= for the temporal ID in the NAL unit header of the H.265=0A= version 1 (HEVC) base specification (temporal=0A= scalability is already nicely supported in version 1).=0A= Just like in SVC. In the scalable extension=2C the NAL=0A= unit header contains a six bit field that points into a=0A= data structure known as "Video Parameter Set" (VPS).=0A= Inside the VPS=2C those six bits are mapped to to a=0A= position in a directed graph (specified through=0A= "dimension_id[][]")=2C which tells you about the reference= =0A= relationship of the layer in question and its parent=0A= layer. One can recursively follow the graph to=0A= determine what used to be called dependency_id=2C=0A= quality_id=2C view_id=2C and whatnot. The six bit pointer= =0A= field can (or: is to be when possible) organized by the=0A= encoder such that it is prudent for a middle box to=0A= throw away NAL units (belonging to layers) with higher=0A= values of the six bit field first=2C before throwing away= =0A= NAL units with lower values. Relying on this feature=2C=0A= 3+6 bits =3D=3D 9 bits should be fine for the header=0A= extension.=0A= =20 =0A= =0A= That said=2C the ordering by the encoder is just a=0A= recommendation=2C and there may well be cases where=0A= different pruning strategies may be advisable. For=0A= example=2C a layering structure could be constructed that= =0A= expands into two branches=2C one using 2D scalable tools=0A= only=2C the other including view_id for multi view coding.= =0A= By looking at the six bit field alone=2C a middle box=0A= will not be able to meaningfully remove NAL units=0A= belonging to one of the branches completely while=0A= pruning the other branch. In order to meaningfully deal=0A= with that scenario=2C there would be two options: one to=0A= represent the dimension_id[][] (and associated control=0A= info) in the header extension=2C or require the middle box= =0A= to have access to the VPS and be able to interpret its=0A= content. The further could take considerably more than=0A= 16 bits and we would be talking about a variable length=0A= data structure. The latter requires the middle box to=0A= have state and a mechanism to intercept the VPS (through=0A= signaling=97as the encrypted in-band VPS would not be=0A= useful under the assumption that the middle box does not=0A= have the key to the media=97which is the motivation of the= =0A= draft in the first place). I personally don't mind at=0A= all the second mechanism=2C as I'm a big fan of=0A= out-of-band parameter set transmission and any middle=0A= box must be in the signaling path anyway to meaningfully=0A= manipulate RTP. I do not like the first option due to=0A= its variable=2C and possibly substantial=2C overhead.=0A= =20 =0A= =0A= Stephan =0A= =20 =0A= =0A= =20 =0A= =0A= =0A= =0A= From: Justin=0A= Uberti =0A= Date: Friday=2C=0A= 19 July=2C 2013 06:32=20 =0A= To: Bernard=0A= Aboba =0A= Cc: "avtext@ietf.org"=0A= =2C=0A= "rtcweb@ietf.org"=0A= =0A= Subject: Re:=0A= [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =0A= =20 =0A= =0A= =0A= =0A= Agree those are the right codecs to=0A= design for. Since in each case there are fairly=0A= low limits on the number of supported layers (i.e.=0A= 3 spatial layers for SVC)=2C I think it should be=0A= possible to pack the temporal=2C spatial=2C quality= =0A= layer ids into 16 bits.=0A= =20 =0A= =20 =0A= On Fri=2C Jul 19=2C 2013 at=0A= 1:56 AM=2C Bernard Aboba =0A= =0A= wrote: =0A= =0A= =0A= If we can support VP8/9 as well as=0A= H.264/5 SVC=0A= that would be a start. It seems=0A= doable to me.=0A= =0A= =0A= =20 =0A= On Jul 18=2C 2013=2C at 8:34 PM=2C "Ada= m=0A= Fineberg" =0A= wrote: =0A= =20 =0A= =0A= =0A= =0A= Bernard=2C =0A= =20 =0A= Are there other codecs you are=0A= thinking should be supported? =0A= If it's generalized I would=0A= think we want to be able to=0A= cover all known scalable codecs.=0A= I'll look into the H264/SVC=0A= fields to see how to encode them=0A= in a generalized header. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/18/13 7:40 PM=2C Bernard=0A= Aboba wrote: =0A= =0A= =0A= I think it may be=0A= possible to generalize this. =0A= For example=2C for H.264/SVC=0A= which can support temporal=2C=0A= spatial and quality=0A= scalability=2C you would need=0A= the quality_id and=0A= dependency_id in addition to=0A= the temporal_id (what you call=0A= the temporal layer index). =0A= =20 =0A= =20 =0A= =0A= =0A= Date: Thu=2C 18 Jul 2013=0A= 08:45:38 -0700 =0A= From: fineberg@vline.me =0A= To: =0A= bernard_aboba@hotmail.com =0A= CC: rtcweb@ietf.org=3B=0A= avtext@ietf.org =0A= Subject: Re: [rtcweb] Fwd:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =20 =0A= Bernard=2C =0A= =20 =0A= Good question. I'm not=0A= familiar enough with the=0A= parameter requirements of=0A= all other scalable codecs to=0A= be able to generalize. If=0A= you'd like to help specify=0A= them=2C I'd be fine revising=0A= the draft to generalize. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/17/13 8:26 PM=2C=0A= Bernard Aboba wrote: =0A= =0A= =0A= Since the=0A= need is not codec=0A= specific (e.g. it arises=0A= with any codec=0A= supporting temporal=2C=0A= spatial and quality=0A= scalability)=2C why=0A= =20 =0A= a VP8-specific RTP=0A= extension?=20 =0A= =20 =0A= =0A= =0A= Date: Wed=2C 17 Jul 2013= =0A= 17:09:46 -0700 =0A= From: fineberg@vline.me =0A= To: rtcweb@ietf.org =0A= Subject: [rtcweb] Fwd:=0A= New Version=0A= Notification for=0A= draft-fineberg-avtext-tem= poral-layer-ext-00.txt =0A= =20 =0A= Hi=2C=0A= =0A= I'm=0A= working on WebRTC=0A= services and have=0A= found that while=0A= developing services=0A= that forward VP8=0A= video streams if we=0A= want to take=0A= advantage of the VP8=0A= temporal scaling we=0A= must get the=0A= temporal layer=0A= information from the=0A= RTP header which=0A= requires us to=0A= decrypt the SRTP=0A= packets. This is=0A= undesirable both=0A= because the=0A= middle-box needs to=0A= have access to the=0A= keys as well as the=0A= because of the added=0A= overhead of the=0A= decrypt/encrypt=0A= cycle. This draft=0A= proposes an RTP=0A= header extension=0A= that will allow us=0A= to use the VP8=0A= temporal layer=0A= information included=0A= in the header=0A= extension and=0A= therefore do=0A= forwarding without=0A= SRTP decryption.=0A= Comments welcome.=0A= =0A= Regards=2C=0A= Adam=0A= Fineberg=0A= fineberg=0A= at vline.com =0A= =20 =0A= -------- Original=0A= Message --------=0A= =0A= =0A= =0A= Subject:=0A= New=0A= Version=0A= Notification=0A= for=0A= draft-fineberg-av= text-temporal-layer-ext-00.txt=0A= =0A= =0A= Date:=0A= Tue=2C 09=0A= Jul 2013=0A= 10:02:05 -0700=0A= =0A= =0A= From:=0A= internet-drafts= =0A= at ietf.org=0A= =0A= =0A= To:=0A= Adam=0A= Fineberg =0A= =0A= =0A= =0A= =20 =0A= =20 =0A= A new version of I-D=2C= draft-fineberg-avtext-temporal-layer-ext-00.txt=0A= has been successfully submitted by Adam Fineberg and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-fineberg-avtext-temporal-layer-ext=0A= Revision: 00=0A= Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information=0A= Creation date: 2013-07-08=0A= Group: Individual Submission=0A= Number of pages: 6=0A= URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt=0A= Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext=0A= Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00=0A= =0A= =0A= Abstract:=0A= This document defines a mechanism by which packets of Real-Time=0A= Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A= indicate=2C in an RTP header extension=2C the temporal layer information= =0A= about the frame encoded in the RTP packet. This information can be=0A= used in a middlebox performing bandwidth management of streams=0A= without requiring it to decrypt the streams.=0A= =0A= =0A= =20 =0A= _________________________= ______________________=0A= rtcweb mailing list =0A= rtcweb@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam=0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =0A= =0A= =20 =0A= _______________________________________________ =0A= rtcweb mailing list =0A= rtcweb@ietf.org =0A= https://www.ietf.org/mailman/listinfo/rtcweb =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= _______________________________________________=0A= avtext mailing list=0A= avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext=0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam=0A= =0A= =0A= =0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam = --_788a735f-7672-45a0-80b1-0a9af35b1860_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I do not think it is necessary t= o "support all forms of scalability for all codecs". =3B =3B In fac= t=2C I would make that an explicit "non-goal". =3B All that was suggest= ed is to try to create a single extension that supports a few common cases.=  =3B =3B If it is possible to handle VP8=2C VP9 and H.264/SVC in a = single extension that would be sufficient. =3B So why not limit it to t= hat?

Date: Tue=2C 23 Jul 2013 08:53:45= -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@goo= gle.com=3B bernard_aboba@hotmail.com=3B avtext@ietf.org=3B rtcweb@ietf.org<= br>Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-f= ineberg-avtext-temporal-layer-ext-00.txt

=0A= =0A= =0A= =0A= =0A= I've been thinking about this and given the ease at which RFC5285=0A= allows for the specification of a header extension and the=0A= complexity introduced by trying to generalize the header extension=0A= to support all forms of scalability for all codecs that the=0A= generalization might not be the best approach. =3B I'm not sure wha= t we=0A= really gain by trying to capture all this in a single header=0A= extension rather than one per that can succinctly explain the fields=0A= without the complexity of multiplexing the bits.
=0A=
=0A= Thoughts?
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/19/13 3:44 PM=2C Stephan Wenger= =0A= wrote:
=0A=
=0A=
=0A= =0A=
= Hi=2C
=0A=
=0A=
=0A=
=0A= =0A=
=0A= From: Adam Fineberg=0A= <=3Bfineberg@vline.me&= gt=3B
=0A= Date: Friday=2C 19 Jul= y=2C=0A= 2013 15:12
=0A= To: Stephan Wenger <= =3Bstewe@stewe.org>=3B
=0A= Cc: Justin Uberti <= =3Bjuberti@google.com>=3B=2C=0A= Bernard Aboba <=3B= bernard_aboba@hotmail.com>=3B=2C=0A= "avtext@ietf.org"=0A= <=3Bavtext@ietf.org>= =3B=2C=0A= "rtcweb@ietf.org"=0A= <=3Brtcweb@ietf.org>= =3B
=0A= Subject: Re: [avtext]= =0A= [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
=0A=
=0A=

=0A=
=0A=
=0A=
Stephan=2C
=0A=
=0A= Thanks for the info and the reference. =3B I'm not sure I= =0A= follow as I'm not at all familiar with H.265. =3B I'll revi= ew=0A= the reference and see what I can figure. =3B
=0A=
=0A= =0A=
=0A=
=0A=
=0A=
= StW: Good luck :-)  =3B
=0A=
=0A=
=0A=
=0A= =0A=
=0A=
It seems though to me=0A= that you are suggesting that except in the simple case=2C that= =0A= the data for H.265 would not be well suited to a header=0A= extension=2C am I understanding you correctly? =3B There is= no=0A= reason the middlebox couldn't get out of band signaling of=0A= the VPS as you mention but that would not be within the=0A= scope of this header extension.
=0A=
=0A= =0A=
=0A=
=0A=
=0A=
StW:= =0A= well=2C if you would copy the layer_id into your header=0A= extension (just as you need to do for the simple case)=2C a=0A= really smart middle box could use this information just as a=0A= decoder uses it=2C =3Bassuming =3Bthat it intercepted t= he VPS in the=0A= first place.  =3BInsofar=2C I wouldn't rule out the second = option=0A= on technical grounds.  =3BWhether any of the actual product= s=0A= would bother to do that=2C ever=2C is another question.  = =3BI think=0A= the case ought to be documented=2C though.  =3BI can help= =0A= drafting text.
=0A=
Whil= e=0A= we are at it: doing this right could mean that you need=0A= multiple specs.  =3BFirst=2C a generic header extension mec= hanism=0A= dedicated to side information required for pruning of RTP=0A= packet streams=97ideally not only for scalable video=2C althoug= h=0A= that is the main customer today.  =3BAnd second=2C for each= =0A= "payload" (at present we are talking about H.264/SVC=2C=0A= H.265v1 (HEVC)=2C H.265v2 (including scalable and 3D=0A= extensions=2C which are not yet finalized)=2C VP8=2C and VP9 (I= =0A= know little about the latter)=2C plus Daala=2C and whatnot) a= =0A= mapping of the bits available in the generic header=0A= extension to the bits in the payload itself (NAL header and=0A= VPS in case of H.265=2C NALU header in SVC=2C and the fields yo= u=0A= mention for VP8).
=0A=
=
=0A=
=0A=
= Stephan
=0A= =0A=
=0A=

=0A=
=0A= Any insights are appreciated.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/19/13 8:33 AM=2C Stephan= =0A= Wenger wrote:
=0A=
=0A=
=0A=
Hi=2C
=0A=
I also believe that 16 bits should be enough.  =3BFo= r=0A= H.264 and VP8 that has already been demonstrated.  =3BF= or=0A= H.265=2C some initial thoughts below.  =3BApologies for= the=0A= word-count.
=0A=

=0A=
=0A=
The scalable version of H265 (called SHVC) is=0A= currently under development.  =3BThe current working dr= aft=0A= can be found here: =3Bhttp://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon= /wg11/JCTVC-M1008-v3.zip.=0A=  =3BTherein=2C the options for defining layering struct= ures=0A= are considerably more complex.  =3BTo start=2C we have = 3 bits=0A= for the temporal ID in the NAL unit header of the H.265=0A= version 1 (HEVC) base specification (temporal=0A= scalability is already nicely supported in version 1).=0A=  =3BJust like in SVC.  =3BIn the scalable extension= =2C the NAL=0A= unit header contains a six bit field that points into a=0A= data structure known as "Video Parameter Set" (VPS).=0A=  =3BInside the VPS=2C those six bits are mapped to to a= =0A= position in a directed graph (specified through=0A= "dimension_id[][]")=2C which tells you about the reference= =0A= relationship of the layer in question and its parent=0A= layer.  =3BOne can recursively follow the graph to=0A= determine what used to be called dependency_id=2C=0A= quality_id=2C view_id=2C and whatnot.  =3BThe six bit p= ointer=0A= field can (or: is to be when possible) organized by the=0A= encoder such that it is prudent for a middle box to=0A= throw away NAL units (belonging to layers) with higher=0A= values of the six bit field first=2C before throwing away= =0A= NAL units with lower values.  =3BRelying on this featur= e=2C=0A= 3+6 bits =3D=3D 9 bits should be fine for the header=0A= extension.
=0A=

=0A=
=0A=
That said=2C the ordering by the encoder is just a=0A= recommendation=2C and there may well be cases where=0A= different pruning strategies may be advisable.  =3BFor= =0A= example=2C a layering structure could be constructed that= =0A= expands into two branches=2C one using 2D scalable tools=0A= only=2C the other including view_id for multi view coding.= =0A=  =3BBy looking at the six bit field alone=2C a middle b= ox=0A= will not be able to meaningfully remove NAL units=0A= belonging to one of the branches completely while=0A= pruning the other branch.  =3BIn order to meaningfully = deal=0A= with that scenario=2C there would be two options: one to=0A= represent the dimension_id[][] (and associated control=0A= info) in the header extension=2C or require the middle box= =0A= to have access to the VPS and be able to interpret its=0A= content.  =3BThe further could take considerably more t= han=0A= 16 bits and we would be talking about a variable length=0A= data structure.  =3BThe latter requires the middle box = to=0A= have state and a mechanism to intercept the VPS (through=0A= signaling=97as the encrypted in-band VPS would not be=0A= useful under the assumption that the middle box does not=0A= have the key to the media=97which is the motivation of the= =0A= draft in the first place).  =3BI personally don't mind = at=0A= all the second mechanism=2C as I'm a big fan of=0A= out-of-band parameter set transmission and any middle=0A= box must be in the signaling path anyway to meaningfully=0A= manipulate RTP.  =3BI do not like the first option due = to=0A= its variable=2C and possibly substantial=2C overhead.
= =0A=

=0A=
=0A=
Stephan  =3B =3B
=0A=

=0A=
=0A=

=0A=
=0A= =0A= =0A=

=0A=
=0A=
=0A=
=0A=
Agree those are the right codecs to=0A= design for. Since in each case there are fairly=0A= low limits on the number of supported layers (i.e.=0A= 3 spatial layers for SVC)=2C I think it should be=0A= possible to pack the temporal=2C spatial=2C quality= =0A= layer ids into 16 bits.=0A=

=0A=
=0A=
On Fri=2C Jul 19=2C 2= 013 at=0A= 1:56 AM=2C Bernard Aboba =0A= <=3Bbernard_aboba@hotmail.com>=3B=0A= wrote:
=0A=
=0A=
=0A=
If we can support VP8/9 as well as=0A= H.264/5 SVC
=0A=
that would be a start. It seems=0A= doable to me.
=0A=
=0A=
=0A=

=0A= On Jul 18=2C 2013=2C at 8:34 PM=2C "Ada= m=0A= Fineberg" <=3Bfineberg@vline.me>=3B=0A= wrote:
=0A=
=0A=
=0A=
=0A=
=0A=
Bernard=2C
=0A=
=0A= Are there other codecs you are=0A= thinking should be supported? = =3B=0A= If it's generalized I would=0A= think we want to be able to=0A= cover all known scalable codecs.=0A= I'll look into the H264/SVC=0A= fields to see how to encode them=0A= in a generalized header.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A= On 7/18/13 7:40 PM=2C Bernard=0A= Aboba wrote:
=0A=
=0A=
=0A=
I think it may be= =0A= possible to generalize this. = =3B=0A= For example=2C for H.264/SVC=0A= which can support temporal=2C=0A= spatial and quality=0A= scalability=2C you would need=0A= the quality_id and=0A= dependency_id in addition to=0A= the temporal_id (what you call=0A= the temporal layer index).  = =3B =3B=0A=
=0A=
=0A=
=0A=
=0A= Date: Thu=2C 18 Jul 2013=0A= 08:45:38 -0700
=0A= From: fineberg@vline.me
=0A= To: =0A= bernard_aboba@hotmail.com=
=0A= CC: rtcweb@ietf.org=3B=0A= avtext@ietf.org
=0A= Subject: Re: [rtcweb] Fwd:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
=0A=
=0A= Bernard=2C
=0A=
=0A= Good question. =3B I'm not= =0A= familiar enough with the=0A= parameter requirements of=0A= all other scalable codecs to=0A= be able to generalize. =3B = If=0A= you'd like to help specify=0A= them=2C I'd be fine revising=0A= the draft to generalize.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/17/13 8:26 PM=2C=0A= Bernard Aboba wrote:
=0A=
=0A=
=0A=
Since the=0A= need is not codec=0A= specific (e.g. it arises=0A= with any codec=0A= supporting temporal=2C=0A= spatial and quality=0A= scalability)=2C why=0A=
=0A=  =3Ba VP8-specific RTP= =0A= extension?
=0A=  =3B
=0A=
=0A=
=0A= Date: Wed=2C 17 Jul 2013= =0A= 17:09:46 -0700
=0A= From: fineberg@vline.me
=0A= To: rtcweb@ietf.org
=0A= Subject: [rtcweb] Fwd:=0A= New Version=0A= Notification for=0A= draft-fineberg-avtext-tem= poral-layer-ext-00.txt
=0A=
=0A= Hi=2C
=0A=
=0A= I'm=0A= working on WebRTC=0A= services and have=0A= found that while=0A= developing services=0A= that forward VP8=0A= video streams if we=0A= want to take=0A= advantage of the VP8=0A= temporal scaling we=0A= must get the=0A= temporal layer=0A= information from the=0A= RTP header which=0A= requires us to=0A= decrypt the SRTP=0A= packets. This is=0A= undesirable both=0A= because the=0A= middle-box needs to=0A= have access to the=0A= keys as well as the=0A= because of the added=0A= overhead of the=0A= decrypt/encrypt=0A= cycle. This draft=0A= proposes an RTP=0A= header extension=0A= that will allow us=0A= to use the VP8=0A= temporal layer=0A= information included=0A= in the header=0A= extension and=0A= therefore do=0A= forwarding without=0A= SRTP decryption.=0A= Comments welcome.
=0A=
=0A= Regards=2C
=0A= Adam=0A= Fineberg
=0A=
fineberg=0A= at vline.com
= =0A=
=0A= -------- Original=0A= Message --------=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Subject:New=0A= Version=0A= Notification=0A= for=0A= draft-fineberg-av= text-temporal-layer-ext-00.txt
Date:Tue=2C 09=0A= Jul 2013=0A= 10:02:05 -0700=0A=
From:in= ternet-drafts=0A= at ietf.org=0A=
To:Adam=0A= Fineberg&nb= sp=3B<=3Bfineberg at vline.com>=3B
=0A=
=0A=
=0A= 
A new version of I-D=2C draft-fineberg-avt=
ext-temporal-layer-ext-00.txt=0A=
has been successfully submitted by Adam Fineberg and posted to the=0A=
IETF repository.=0A=
=0A=
Filename:	 draft-fineberg-avtext-temporal-layer-ext=0A=
Revision:	 00=0A=
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information=0A=
Creation date:	 2013-07-08=0A=
Group:		 Individual Submission=0A=
Number of pages: 6=0A=
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-=
00.txt=0A=
Status:          http://datatr=
acker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext=0A=
Htmlized:        http://tools.ie=
tf.org/html/draft-fineberg-avtext-temporal-layer-ext-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a mechanism by which packets of Real-Time=0A=
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A=
   indicate=2C in an RTP header extension=2C the temporal layer information=
=0A=
   about the frame encoded in the RTP packet.  This information can be=0A=
   used in a middlebox performing bandwidth management of streams=0A=
   without requiring it to decrypt the streams.=0A=
=0A=
=0A=
=0A= _________________________= ______________________=0A= rtcweb mailing list =0A= rtcweb@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/rtcweb
=0A=
=0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= _______________________________________________
=0A= rtcweb mailing list
=0A= rtcweb@ietf.org
=0A= https://www.ietf.org/mailman/listinfo/rtcweb
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= 
_______________________________________________=0A=
avtext mailing list=0A=
av=
text@ietf.orghttps://www.ietf.org/ma=
ilman/listinfo/avtext
=0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
=0A=
=0A=
=0A= =0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
= --_788a735f-7672-45a0-80b1-0a9af35b1860_-- From fineberg@vline.me Wed Jul 24 10:08:32 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD61511E8101 for ; Wed, 24 Jul 2013 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJuQAvUQUKHd for ; Wed, 24 Jul 2013 10:08:31 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3011E824A for ; Wed, 24 Jul 2013 10:08:26 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md4so2063019pbc.35 for ; Wed, 24 Jul 2013 10:08:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=kzFjS8rBEitbb8WFI/eV3xjweZ6I4U5R7WweBP81QzM=; b=VjQ/ZtlcVZiVVHMLJ5et1bsFWDGk4ejxAzirFKFVWcjhDuzoZ7BrXlkrn1dvArCWA6 lygaLaz46T8rNQh85wyxwOshnX8P2DNLoBt/AQPXdp79KaEAeYwzrx7ynvbg+AXm8SNT Ngvq/t2BljD0E789j96PSG+qZ4hUuIHUj2/fv7AZmyyIfFFSyG2M/3dA+IqhLqyafC6y UnhICYz8P7UozaOKZwoL89bTnxgb8gAek9Z1ZEI1sasnBNpYN6CIienn9g/4rzz37Sno TLTwhoQ3il5uu0+QmkxlKi5xwOAQr9Sx2jUdno3GyBf13U+n856sOFPpb3Hg44OOXaCQ p+rg== X-Received: by 10.67.21.229 with SMTP id hn5mr44856320pad.135.1374685704639; Wed, 24 Jul 2013 10:08:24 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id wf7sm52553503pac.20.2013.07.24.10.08.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 10:08:23 -0700 (PDT) Message-ID: <51F00A02.3060204@vline.me> Date: Wed, 24 Jul 2013 10:08:18 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: , <51EEA709.2020009@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010308000106040700070801" X-Gm-Message-State: ALoCoQkceRmbghe84R1S8P7KQMbIPNDhrk4uNK6p4tPIUoM6OTThdFAKtZsXUul9v9BzS6In6hjM Cc: "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:08:32 -0000 This is a multi-part message in MIME format. --------------010308000106040700070801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Bernard, I apologize if I come across as being difficult here but I stil am not seeing the benefits. Since the fields are not the same for the codecs, we will be multiplexing the bits and that seems to me to add complexity rather than add clarity. Also, I can't find an IETF VP9 document for the payload format to reference. If the group thinks generalization is the right approach I would appreciate some collaboration on getting the right bit definitions for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: > I do not think it is necessary to "support all forms of scalability > for all codecs". In fact, I would make that an explicit "non-goal". > All that was suggested is to try to create a single extension that > supports a few common cases. If it is possible to handle VP8, VP9 and > H.264/SVC in a single extension that would be sufficient. So why not > limit it to that? > > ------------------------------------------------------------------------ > Date: Tue, 23 Jul 2013 08:53:45 -0700 > From: fineberg@vline.me > To: stewe@stewe.org > CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; > rtcweb@ietf.org > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > I've been thinking about this and given the ease at which RFC5285 > allows for the specification of a header extension and the complexity > introduced by trying to generalize the header extension to support all > forms of scalability for all codecs that the generalization might not > be the best approach. I'm not sure what we really gain by trying to > capture all this in a single header extension rather than one per that > can succinctly explain the fields without the complexity of > multiplexing the bits. > > Thoughts? > > Regards, > Adam > > On 7/19/13 3:44 PM, Stephan Wenger wrote: > > Hi, > > From: Adam Fineberg > > Date: Friday, 19 July, 2013 15:12 > To: Stephan Wenger > > Cc: Justin Uberti >, Bernard Aboba > >, > "avtext@ietf.org " >, "rtcweb@ietf.org > " > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow as > I'm not at all familiar with H.265. I'll review the reference and > see what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in the > simple case, that the data for H.265 would not be well suited to a > header extension, am I understanding you correctly? There is no > reason the middlebox couldn't get out of band signaling of the VPS > as you mention but that would not be within the scope of this > header extension. > > StW: well, if you would copy the layer_id into your header > extension (just as you need to do for the simple case), a really > smart middle box could use this information just as a decoder uses > it, assuming that it intercepted the VPS in the first place. > Insofar, I wouldn't rule out the second option on technical > grounds. Whether any of the actual products would bother to do > that, ever, is another question. I think the case ought to be > documented, though. I can help drafting text. > While we are at it: doing this right could mean that you need > multiple specs. First, a generic header extension mechanism > dedicated to side information required for pruning of RTP packet > streamsideally not only for scalable video, although that is the > main customer today. And second, for each "payload" (at present > we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including > scalable and 3D extensions, which are not yet finalized), VP8, and > VP9 (I know little about the latter), plus Daala, and whatnot) a > mapping of the bits available in the generic header extension to > the bits in the payload itself (NAL header and VPS in case of > H.265, NALU header in SVC, and the fields you mention for VP8). > > Stephan > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: > > Hi, > I also believe that 16 bits should be enough. For H.264 and > VP8 that has already been demonstrated. For H.265, some > initial thoughts below. Apologies for the word-count. > > The scalable version of H265 (called SHVC) is currently under > development. The current working draft can be found here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. > Therein, the options for defining layering structures are > considerably more complex. To start, we have 3 bits for the > temporal ID in the NAL unit header of the H.265 version 1 > (HEVC) base specification (temporal scalability is already > nicely supported in version 1). Just like in SVC. In the > scalable extension, the NAL unit header contains a six bit > field that points into a data structure known as "Video > Parameter Set" (VPS). Inside the VPS, those six bits are > mapped to to a position in a directed graph (specified through > "dimension_id[][]"), which tells you about the reference > relationship of the layer in question and its parent layer. > One can recursively follow the graph to determine what used > to be called dependency_id, quality_id, view_id, and whatnot. > The six bit pointer field can (or: is to be when possible) > organized by the encoder such that it is prudent for a middle > box to throw away NAL units (belonging to layers) with higher > values of the six bit field first, before throwing away NAL > units with lower values. Relying on this feature, 3+6 bits == > 9 bits should be fine for the header extension. > > That said, the ordering by the encoder is just a > recommendation, and there may well be cases where different > pruning strategies may be advisable. For example, a layering > structure could be constructed that expands into two branches, > one using 2D scalable tools only, the other including view_id > for multi view coding. By looking at the six bit field alone, > a middle box will not be able to meaningfully remove NAL units > belonging to one of the branches completely while pruning the > other branch. In order to meaningfully deal with that > scenario, there would be two options: one to represent the > dimension_id[][] (and associated control info) in the header > extension, or require the middle box to have access to the VPS > and be able to interpret its content. The further could take > considerably more than 16 bits and we would be talking about a > variable length data structure. The latter requires the > middle box to have state and a mechanism to intercept the VPS > (through signalingas the encrypted in-band VPS would not be > useful under the assumption that the middle box does not have > the key to the mediawhich is the motivation of the draft in > the first place). I personally don't mind at all the second > mechanism, as I'm a big fan of out-of-band parameter set > transmission and any middle box must be in the signaling path > anyway to meaningfully manipulate RTP. I do not like the > first option due to its variable, and possibly substantial, > overhead. > > Stephan > > > From: Justin Uberti > > Date: Friday, 19 July, 2013 06:32 > To: Bernard Aboba > > Cc: "avtext@ietf.org " > >, "rtcweb@ietf.org > " > > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Agree those are the right codecs to design for. Since in each > case there are fairly low limits on the number of supported > layers (i.e. 3 spatial layers for SVC), I think it should be > possible to pack the temporal, spatial, quality layer ids into > 16 bits. > > > On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > > > wrote: > > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: > > Bernard, > > Are there other codecs you are thinking should be > supported? If it's generalized I would think we want > to be able to cover all known scalable codecs. I'll > look into the H264/SVC fields to see how to encode > them in a generalized header. > > Regards, > Adam > > On 7/18/13 7:40 PM, Bernard Aboba wrote: > > I think it may be possible to generalize this. > For example, for H.264/SVC which can support > temporal, spatial and quality scalability, you > would need the quality_id and dependency_id in > addition to the temporal_id (what you call the > temporal layer index). > > ------------------------------------------------------------------------ > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > > CC: rtcweb@ietf.org ; > avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version > Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the > parameter requirements of all other scalable > codecs to be able to generalize. If you'd like to > help specify them, I'd be fine revising the draft > to generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it > arises with any codec supporting temporal, > spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version > Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found > that while developing services that forward > VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the > temporal layer information from the RTP header > which requires us to decrypt the SRTP packets. > This is undesirable both because the > middle-box needs to have access to the keys as > well as the because of the added overhead of > the decrypt/encrypt cycle. This draft proposes > an RTP header extension that will allow us to > use the VP8 temporal layer information > included in the header extension and therefore > do forwarding without SRTP decryption. > Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > > -------- Original Message -------- > Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > Date: Tue, 09 Jul 2013 10:02:05 -0700 > From: internet-drafts at ietf.org > > To: Adam Fineberg > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb > mailing list rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Regards, > Adam > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext > > > -- > Regards, > Adam > > > -- > Regards, > Adam -- Regards, Adam --------------010308000106040700070801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Bernard,

I apologize if I come across as being difficult here but I stil am not seeing the benefits. Since the fields are not the same for the codecs, we will be multiplexing the bits and that seems to me to add complexity rather than add clarity. Also, I can't find an IETF VP9 document for the payload format to reference. If the group thinks generalization is the right approach I would appreciate some collaboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:
I do not think it is necessary to "support all forms of scalability for all codecs". In fact, I would make that an explicit "non-goal". All that was suggested is to try to create a single extension that supports a few common cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single extension that would be sufficient. So why not limit it to that?

Date: Tue, 23 Jul 2013 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach. I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Stephan,

Thanks for the info and the reference. I'm not sure I follow as I'm not at all familiar with H.265. I'll review the reference and see what I can figure.

StW: Good luck :-)

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly? There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it,assumingthat it intercepted the VPS in the first place. Insofar, I wouldn't rule out the second option on technical grounds. Whether any of the actual products would bother to do that, ever, is another question. I think the case ought to be documented, though. I can help drafting text.
While we are at it: doing this right could mean that you need multiple specs. First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streamsideally not only for scalable video, although that is the main customer today. And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough. For H.264 and VP8 that has already been demonstrated. For H.265, some initial thoughts below. Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development. The current working draft can be found here:http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the options for defining layering structures are considerably more complex. To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1). Just like in SVC. In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS). Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer. One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot. The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values. Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable. For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding. By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch. In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content. The further could take considerably more than 16 bits and we would be talking about a variable length data structure. The latter requires the middle box to have state and a mechanism to intercept the VPS (through signalingas the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the mediawhich is the motivation of the draft in the first place). I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported? If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this. For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question. I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize. If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
a VP8-specific RTP extension?

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg<fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

-- 
Regards,
Adam
 

-- 
Regards,
Adam

-- 
Regards,
Adam
--------------010308000106040700070801-- From yekuiw@qti.qualcomm.com Wed Jul 24 15:32:12 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62A811E8115; Wed, 24 Jul 2013 15:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GWUS1+CHGq1; Wed, 24 Jul 2013 15:32:04 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3521F84E3; Wed, 24 Jul 2013 15:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374705123; x=1406241123; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+UAmFS/l7qp1jhmKa+QEOSqufvCd136bCkp1ZeqpPE8=; b=s356ViqaUbDWbEHMEIDfVTYwDn4H/0yY+o6ie/nmUEKhZwvfBeabCK2K kQnX9YJwUfX47yj7F5fmsBqjKT5zj43mif4tPpzgjoG9VbY1h//elk/mG 0lfq3+/j86aF0d2c2U99V5i6wnxXO0WisQRBPBgH56ueYYbzUUkAfV/Vu c=; X-IronPort-AV: E=Sophos;i="4.89,737,1367996400"; d="scan'208,217";a="48055484" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 24 Jul 2013 15:32:02 -0700 X-IronPort-AV: E=Sophos;i="4.89,737,1367996400"; d="scan'208,217";a="484769105" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jul 2013 15:32:02 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 15:32:02 -0700 From: "Wang, Ye-Kui" To: Adam Fineberg , Bernard Aboba Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiJCjclj0bx0Iw0WEq1cynbFWSZl0aUGA Date: Wed, 24 Jul 2013 22:32:01 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> In-Reply-To: <51F00A02.3060204@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 24 Jul 2013 15:35:13 -0700 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:32:12 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the group is to specify something generic, naturally it should be generi= c enough to cover at least all existing standard scalable video codecs if p= ossible. And I personally think that is possible and not difficult at all. = Thus, why limit to only a few scalable video codecs? I could provide some help here too if needed. BR, YK From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Adam Fineberg Sent: Wednesday, July 24, 2013 10:08 AM To: Bernard Aboba Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Bernard, I apologize if I come across as being difficult here but I stil am not seei= ng the benefits. Since the fields are not the same for the codecs, we will= be multiplexing the bits and that seems to me to add complexity rather tha= n add clarity. Also, I can't find an IETF VP9 document for the payload for= mat to reference. If the group thinks generalization is the right approach= I would appreciate some collaboration on getting the right bit definitions= for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: I do not think it is necessary to "support all forms of scalability for all= codecs". In fact, I would make that an explicit "non-goal". All that wa= s suggested is to try to create a single extension that supports a few comm= on cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single = extension that would be sufficient. So why not limit it to that? ________________________________ Date: Tue, 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com; bernard_aboba@hotmail.co= m; avtext@ietf.org; rtcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach. = I'm not sure what we really gain by trying to capture all this in a single = header extension rather than one per that can succinctly explain the fields= without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams-ideally not only for scalable= video, although that is the main customer today. And second, for each "pa= yload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 = (including scalable and 3D extensions, which are not yet finalized), VP8, a= nd VP9 (I know little about the latter), plus Daala, and whatnot) a mapping= of the bits available in the generic header extension to the bits in the p= ayload itself (NAL header and VPS in case of H.265, NALU header in SVC, and= the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling-as the encrypted in-band VPS would not be useful under the assump= tion that the middle box does not have the key to the media-which is the mo= tivation of the draft in the first place). I personally don't mind at all = the second mechanism, as I'm a big fan of out-of-band parameter set transmi= ssion and any middle box must be in the signaling path anyway to meaningful= ly manipulate RTP. I do not like the first option due to its variable, and= possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for= VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam -- Regards, Adam --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the group is to specif= y something generic, naturally it should be generic enough to cover at leas= t all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, wh= y limit to only a few scalable video codecs?

 <= /p>

I could provide some help= here too if needed.

 <= /p>

BR, YK<= /p>

 <= /p>

From:= avtext-bounces@ietf= .org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seei= ng the benefits.  Since the fields are not the same for the codecs, we= will be multiplexing the bits and that seems to me to add complexity rathe= r than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the gro= up thinks generalization is the right approach I would appreciate some coll= aboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:=

I do not think it is = necessary to "support all forms of scalability for all codecs".&n= bsp;  In fact, I would make that an explicit "non-goal".&nbs= p; All that was suggested is to try to create a single extension that suppo= rts a few common cases.   If it is possible to handle VP8, VP9 and H= .264/SVC in a single extension that would be sufficient.  So why not l= imit it to that?

Date: Tue, 23 Jul 201= 3 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ie= tf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by = trying to capture all this in a single header extension rather than one per= that can succinctly explain the fields without the complexity of multiplex= ing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:=

Hi,=

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stew= e.org>
Cc: Justin Uberti <juberti@= google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <a= vtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are sugg= esting that except in the simple case, that the data for H.265 would not be= well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band= signaling of the VPS as you mention but that would not be within the scope= of this header extension.

 

StW: well, if you would copy the layer_id int= o your header extension (just as you need to do for the simple case), a rea= lly smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the f= irst place.  Insofar, I wouldn't rule out the second option on technic= al grounds.  Whether any of the actual products would bother to do tha= t, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could me= an that you need multiple specs.  First, a generic header extension me= chanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although tha= t is the main customer today.  And second, for each "payload"= ; (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (incl= uding scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a = mapping of the bits available in the generic header extension to the bits i= n the payload itself (NAL header and VPS in case of H.265, NALU header in S= VC, and the fields you mention for VP8).

 

Stephan<= o:p>



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrot= e:

Hi,

I also believe that 16 bits should be e= nough.  For H.264 and VP8 that has already been demonstrated.  Fo= r H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SH= VC) is currently under development.  The current working draft can be = found here: http://phenix.i= nt-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

 

That said, the ordering by the encoder = is just a recommendation, and there may well be cases where different pruni= ng strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2= D scalable tools only, the other including view_id for multi view coding. &= nbsp;By looking at the six bit field alone, a middle box will not be able t= o meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In= order to meaningfully deal with that scenario, there would be two options:= one to represent the dimension_id[][] (and associated control info) in the= header extension, or require the middle box to have access to the VPS and be able to interpret its content.  = The further could take considerably more than 16 bits and we would be talki= ng about a variable length data structure.  The latter requires the mi= ddle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS wo= uld not be useful under the assumption that the middle box does not have th= e key to the media—which is the motivation of the draft in the first = place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmissi= on and any middle box must be in the signaling path anyway to meaningfully = manipulate RTP.  I do not like the first option due to its variable, a= nd possibly substantial, overhead.

 

Stephan   <= /p>

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <b= ernard_aboba@hotmail.com>
Cc: "avtext@ietf.org&quo= t; <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-finebe= rg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to des= ign for. Since in each case there are fairly low limits on the number of su= pported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids int= o 16 bits.

&nb= sp;

On Fri, Jul 19, 2013 at 1:56 AM, Bernar= d Aboba <= bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.26= 4/5 SVC

that would be a start. It seems doable = to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think = it may be possible to generalize this.  For example, for H.264/SVC whi= ch can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what= you call the temporal layer index).   

Date: Th= u, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline= .me
To: bernard_= aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote= :

Since the need is not codec specific (e= .g. it arises with any codec supporting temporal, spatial and quality scala= bility), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline= .me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to= have access to the keys as well as the because of the added overhead of th= e decrypt/encrypt cycle. This draft proposes an RTP header extension that w= ill allow us to use the VP8 temporal layer information included in the header extension and therefore do forwar= ding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subjec= t:

New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Date:<= o:p>

Tue, 09 Jul 2013 10:02:05 -0700

From:<= o:p>

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com><= /p> 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt<=
o:p>
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-av=
text-temporal-layer-ext
Revision:         00

Title:            A =
Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer =
Information


Creation date:    2013-07-08


Group:            In=
dividual Submission


Number of pages: 6


URL:           =
  http://www.ietf.org/internet-=
drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt


Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-=
temporal-layer-ext


Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext=
-00


 


 


Abstract:


   This document defines a mechanism by which packets of Rea=
l-Time


   Tranport Protocol (RTP) video streams encoded with the VP=
8 codec can


   indicate, in an RTP header extension, the temporal layer =
information


   about the frame encoded in the RTP packet.  This inf=
ormation can be


   used in a middlebox performing bandwidth management of st=
reams


   without requiring it to decrypt the streams.


_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

 

-- 
Regards,
Adam

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

 



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf=
.org/mailman/listinfo/avtext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam



-- 
Regards,
Adam
--_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_-- From fineberg@vline.me Wed Jul 24 15:55:03 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2983D11E8158 for ; Wed, 24 Jul 2013 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocQL22Mj5JjI for ; Wed, 24 Jul 2013 15:54:51 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9D11E812D for ; Wed, 24 Jul 2013 15:54:45 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so2534401oag.37 for ; Wed, 24 Jul 2013 15:54:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=VS+ZwlJursITT/5OjN/vg5RNwOlSruohaYVgzvz2juE=; b=OiNJ9kt7tXBXi4BzHsb5WRRg3vonPbhMRj63O6FTQiJKssb6bDz1ABJ7ZLJtQghSgI O9bjMFJUtXgySMT8y1D60fnfW85+aUV/aZDtpeow24BU0jqcHFgfM8cLVZMRdgkIl2C1 QYormaOx9sDDBIaTLM4caVV6wjVW25QPuo9miTl+5uAbtqoDt3UZ9p4XhbT1nf8OuFPy BJcLfYaPAPPYqm5bjnCOx3i9x0u+AUGTO7kcIZPjaoVIMzflkz5rqDTFGyRpGx+Jcm82 uL46R+UbalkjPMBa/7RG9xoz8dbkwvRddxf2TcZEox8Mv9qEkZCtBuTQTRmB16/5AnQl j8bg== X-Received: by 10.50.164.167 with SMTP id yr7mr711148igb.22.1374706483543; Wed, 24 Jul 2013 15:54:43 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id z15sm8747igp.0.2013.07.24.15.54.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 15:54:42 -0700 (PDT) Message-ID: <51F05B32.5080401@vline.me> Date: Wed, 24 Jul 2013 15:54:42 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Wang, Ye-Kui" References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> Content-Type: multipart/alternative; boundary="------------060504090401040709000905" X-Gm-Message-State: ALoCoQmC4+fYh/ijou/xutzs4CaCAuzYQ4J5Q6cK2EhKZavWqqQHgoaMixjyxGc40kMYkp+nnOzn Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:55:03 -0000 This is a multi-part message in MIME format. --------------060504090401040709000905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit YK, I would appreciate your collaboration. Which codecs are you referring to when you say "all existing standard scalable video codecs"? Regards, Adam On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: > > If the group is to specify something generic, naturally it should be > generic enough to cover at least all existing standard scalable video > codecs if possible. And I personally think that is possible and not > difficult at all. Thus, why limit to only a few scalable video codecs? > > I could provide some help here too if needed. > > BR, YK > > *From:*avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] *On > Behalf Of *Adam Fineberg > *Sent:* Wednesday, July 24, 2013 10:08 AM > *To:* Bernard Aboba > *Cc:* avtext@ietf.org; rtcweb@ietf.org; Justin Uberti > *Subject:* Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > I apologize if I come across as being difficult here but I stil am not > seeing the benefits. Since the fields are not the same for the > codecs, we will be multiplexing the bits and that seems to me to add > complexity rather than add clarity. Also, I can't find an IETF VP9 > document for the payload format to reference. If the group thinks > generalization is the right approach I would appreciate some > collaboration on getting the right bit definitions for the other codecs. > > Regards, > Adam > > On 7/23/13 12:07 PM, Bernard Aboba wrote: > > I do not think it is necessary to "support all forms of > scalability for all codecs". In fact, I would make that an > explicit "non-goal". All that was suggested is to try to create a > single extension that supports a few common cases. If it is > possible to handle VP8, VP9 and H.264/SVC in a single extension > that would be sufficient. So why not limit it to that? > > ------------------------------------------------------------------------ > > Date: Tue, 23 Jul 2013 08:53:45 -0700 > From: fineberg@vline.me > To: stewe@stewe.org > CC: juberti@google.com ; > bernard_aboba@hotmail.com ; > avtext@ietf.org ; rtcweb@ietf.org > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > I've been thinking about this and given the ease at which RFC5285 > allows for the specification of a header extension and the > complexity introduced by trying to generalize the header extension > to support all forms of scalability for all codecs that the > generalization might not be the best approach. I'm not sure what > we really gain by trying to capture all this in a single header > extension rather than one per that can succinctly explain the > fields without the complexity of multiplexing the bits. > > Thoughts? > > Regards, > Adam > > On 7/19/13 3:44 PM, Stephan Wenger wrote: > > Hi, > > *From: *Adam Fineberg > > *Date: *Friday, 19 July, 2013 15:12 > *To: *Stephan Wenger > > *Cc: *Justin Uberti >, Bernard Aboba > >, "avtext@ietf.org > " >, "rtcweb@ietf.org > " > > *Subject: *Re: [avtext] [rtcweb] Fwd: New Version Notification > for draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow > as I'm not at all familiar with H.265. I'll review the > reference and see what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in > the simple case, that the data for H.265 would not be well > suited to a header extension, am I understanding you > correctly? There is no reason the middlebox couldn't get out > of band signaling of the VPS as you mention but that would not > be within the scope of this header extension. > > StW: well, if you would copy the layer_id into your header > extension (just as you need to do for the simple case), a > really smart middle box could use this information just as a > decoder uses it, assuming that it intercepted the VPS in the > first place. Insofar, I wouldn't rule out the second option > on technical grounds. Whether any of the actual products > would bother to do that, ever, is another question. I think > the case ought to be documented, though. I can help drafting > text. > > While we are at it: doing this right could mean that you need > multiple specs. First, a generic header extension mechanism > dedicated to side information required for pruning of RTP > packet streams---ideally not only for scalable video, although > that is the main customer today. And second, for each > "payload" (at present we are talking about H.264/SVC, H.265v1 > (HEVC), H.265v2 (including scalable and 3D extensions, which > are not yet finalized), VP8, and VP9 (I know little about the > latter), plus Daala, and whatnot) a mapping of the bits > available in the generic header extension to the bits in the > payload itself (NAL header and VPS in case of H.265, NALU > header in SVC, and the fields you mention for VP8). > > Stephan > > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: > > Hi, > > I also believe that 16 bits should be enough. For H.264 > and VP8 that has already been demonstrated. For H.265, > some initial thoughts below. Apologies for the word-count. > > The scalable version of H265 (called SHVC) is currently > under development. The current working draft can be found > here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. > Therein, the options for defining layering structures are > considerably more complex. To start, we have 3 bits for > the temporal ID in the NAL unit header of the H.265 > version 1 (HEVC) base specification (temporal scalability > is already nicely supported in version 1). Just like in > SVC. In the scalable extension, the NAL unit header > contains a six bit field that points into a data structure > known as "Video Parameter Set" (VPS). Inside the VPS, > those six bits are mapped to to a position in a directed > graph (specified through "dimension_id[][]"), which tells > you about the reference relationship of the layer in > question and its parent layer. One can recursively follow > the graph to determine what used to be called > dependency_id, quality_id, view_id, and whatnot. The six > bit pointer field can (or: is to be when possible) > organized by the encoder such that it is prudent for a > middle box to throw away NAL units (belonging to layers) > with higher values of the six bit field first, before > throwing away NAL units with lower values. Relying on > this feature, 3+6 bits == 9 bits should be fine for the > header extension. > > That said, the ordering by the encoder is just a > recommendation, and there may well be cases where > different pruning strategies may be advisable. For > example, a layering structure could be constructed that > expands into two branches, one using 2D scalable tools > only, the other including view_id for multi view coding. > By looking at the six bit field alone, a middle box will > not be able to meaningfully remove NAL units belonging to > one of the branches completely while pruning the other > branch. In order to meaningfully deal with that scenario, > there would be two options: one to represent the > dimension_id[][] (and associated control info) in the > header extension, or require the middle box to have access > to the VPS and be able to interpret its content. The > further could take considerably more than 16 bits and we > would be talking about a variable length data structure. > The latter requires the middle box to have state and a > mechanism to intercept the VPS (through signaling---as the > encrypted in-band VPS would not be useful under the > assumption that the middle box does not have the key to > the media---which is the motivation of the draft in the > first place). I personally don't mind at all the second > mechanism, as I'm a big fan of out-of-band parameter set > transmission and any middle box must be in the signaling > path anyway to meaningfully manipulate RTP. I do not like > the first option due to its variable, and possibly > substantial, overhead. > > Stephan > > *From: *Justin Uberti > > *Date: *Friday, 19 July, 2013 06:32 > *To: *Bernard Aboba > > *Cc: *"avtext@ietf.org " > >, > "rtcweb@ietf.org " > > > *Subject: *Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Agree those are the right codecs to design for. Since in > each case there are fairly low limits on the number of > supported layers (i.e. 3 spatial layers for SVC), I think > it should be possible to pack the temporal, spatial, > quality layer ids into 16 bits. > > On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > > wrote: > > If we can support VP8/9 as well as H.264/5 SVC > > that would be a start. It seems doable to me. > > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: > > Bernard, > > Are there other codecs you are thinking should be > supported? If it's generalized I would think we want > to be able to cover all known scalable codecs. I'll > look into the H264/SVC fields to see how to encode > them in a generalized header. > > Regards, > Adam > > On 7/18/13 7:40 PM, Bernard Aboba wrote: > > I think it may be possible to generalize this. For > example, for H.264/SVC which can support temporal, > spatial and quality scalability, you would need > the quality_id and dependency_id in addition to > the temporal_id (what you call the temporal layer > index). > > ------------------------------------------------------------------------ > > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > > CC: rtcweb@ietf.org ; > avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version > Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the > parameter requirements of all other scalable > codecs to be able to generalize. If you'd like to > help specify them, I'd be fine revising the draft > to generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it > arises with any codec supporting temporal, > spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version > Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found > that while developing services that forward > VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the > temporal layer information from the RTP header > which requires us to decrypt the SRTP packets. > This is undesirable both because the > middle-box needs to have access to the keys as > well as the because of the added overhead of > the decrypt/encrypt cycle. This draft proposes > an RTP header extension that will allow us to > use the VP8 temporal layer information > included in the header extension and therefore > do forwarding without SRTP decryption. > Comments welcome. > > Regards, > Adam Fineberg > > fineberg at vline.com > > > -------- Original Message -------- > > *Subject:* > > > > New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > *Date:* > > > > Tue, 09 Jul 2013 10:02:05 -0700 > > *From:* > > > > internet-drafts at ietf.org > > > *To:* > > > > Adam Fineberg > > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > > has been successfully submitted by Adam Fineberg and posted to the > > IETF repository. > > > > Filename: draft-fineberg-avtext-temporal-layer-ext > > Revision: 00 > > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > > Creation date: 2013-07-08 > > Group: Individual Submission > > Number of pages: 6 > > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > > > > Abstract: > > This document defines a mechanism by which packets of Real-Time > > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > > indicate, in an RTP header extension, the temporal layer information > > about the frame encoded in the RTP packet. This information can be > > used in a middlebox performing bandwidth management of streams > > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb > mailing list rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > -- > > Regards, > > Adam > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext > > -- > > Regards, > > Adam > > -- > > Regards, > > Adam > > > > -- > Regards, > Adam -- Regards, Adam --------------060504090401040709000905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit YK,

I would appreciate your collaboration.  Which codecs are you referring to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specify something generic, naturally it should be generic enough to cover at least all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, why limit to only a few scalable video codecs?

 

I could provide some help here too if needed.

 

BR, YK

 

From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seeing the benefits.  Since the fields are not the same for the codecs, we will be multiplexing the bits and that seems to me to add complexity rather than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the group thinks generalization is the right approach I would appreciate some collaboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:

I do not think it is necessary to "support all forms of scalability for all codecs".   In fact, I would make that an explicit "non-goal".  All that was suggested is to try to create a single extension that supports a few common cases.   If it is possible to handle VP8, VP9 and H.264/SVC in a single extension that would be sufficient.  So why not limit it to that?

Date: Tue, 23 Jul 2013 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

 

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule out the second option on technical grounds.  Whether any of the actual products would bother to do that, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could mean that you need multiple specs.  First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although that is the main customer today.  And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:

Hi,

I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

 

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

 

Stephan   

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC

that would be a start. It seems doable to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:

Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com>

 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-avtext-temporal-layer-ext
Revision:         00
Title:            A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:    2013-07-08
Group:            Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
 
 
Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.


_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

 

-- 
Regards,
Adam

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam



-- 
Regards,
Adam

-- 
Regards,
Adam
--------------060504090401040709000905-- From yekuiw@qti.qualcomm.com Thu Jul 25 00:29:00 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4144721F99A2; Thu, 25 Jul 2013 00:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eHQ7K2qUssw; Thu, 25 Jul 2013 00:28:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5A21F99AB; Thu, 25 Jul 2013 00:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374737324; x=1406273324; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EStTDljTOU1upMqJbbA9iFcRFXp6j330ZJ0LXoHuUZw=; b=ksDPQTwA33PTkWG/DzevUJ60Sx/7YILIdsn7A9eokZyrC2487adbkruG dy57T2UXmX82oL8vKd4AvxNJycft7sjFBWcaNYazWY5d6m+pCfvTkXord CzgJf7cC4G2UgRTznjqG+8ir03Zf/jUNQ48R5A/gr0edwEJTSq68sANp4 4=; X-IronPort-AV: E=Sophos;i="4.89,741,1367996400"; d="scan'208,217";a="48084619" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 25 Jul 2013 00:28:42 -0700 Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Jul 2013 00:28:41 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Jul 2013 00:28:41 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 00:28:41 -0700 From: "Wang, Ye-Kui" To: Adam Fineberg Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiMDQ739D5cVyN02oHm4OkyMkjZl0/z2g Date: Thu, 25 Jul 2013 07:28:40 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384A0F8F@nasanexd02f.na.qualcomm.com> References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> <51F05B32.5080401@vline.me> In-Reply-To: <51F05B32.5080401@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_" MIME-Version: 1.0 Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:29:00 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, I meant the scalable codecs mentioned so far by everyone, including H.265/H= EVC and its extensions, and H.264/AVC and its extensions. BR, YK From: Adam Fineberg [mailto:fineberg@vline.me] Sent: Wednesday, July 24, 2013 3:55 PM To: Wang, Ye-Kui Cc: Bernard Aboba; avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt YK, I would appreciate your collaboration. Which codecs are you referring to w= hen you say "all existing standard scalable video codecs"? Regards, Adam On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: If the group is to specify something generic, naturally it should be generi= c enough to cover at least all existing standard scalable video codecs if p= ossible. And I personally think that is possible and not difficult at all. = Thus, why limit to only a few scalable video codecs? I could provide some help here too if needed. BR, YK From: avtext-bounces@ietf.org [mailto:avtex= t-bounces@ietf.org] On Behalf Of Adam Fineberg Sent: Wednesday, July 24, 2013 10:08 AM To: Bernard Aboba Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Bernard, I apologize if I come across as being difficult here but I stil am not seei= ng the benefits. Since the fields are not the same for the codecs, we will= be multiplexing the bits and that seems to me to add complexity rather tha= n add clarity. Also, I can't find an IETF VP9 document for the payload for= mat to reference. If the group thinks generalization is the right approach= I would appreciate some collaboration on getting the right bit definitions= for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: I do not think it is necessary to "support all forms of scalability for all= codecs". In fact, I would make that an explicit "non-goal". All that wa= s suggested is to try to create a single extension that supports a few comm= on cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single = extension that would be sufficient. So why not limit it to that? ________________________________ Date: Tue, 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com; bernard_aboba@hotmail.co= m; avtext@ietf.org; rtcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach. = I'm not sure what we really gain by trying to capture all this in a single = header extension rather than one per that can succinctly explain the fields= without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams-ideally not only for scalable= video, although that is the main customer today. And second, for each "pa= yload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 = (including scalable and 3D extensions, which are not yet finalized), VP8, a= nd VP9 (I know little about the latter), plus Daala, and whatnot) a mapping= of the bits available in the generic header extension to the bits in the p= ayload itself (NAL header and VPS in case of H.265, NALU header in SVC, and= the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling-as the encrypted in-band VPS would not be useful under the assump= tion that the middle box does not have the key to the media-which is the mo= tivation of the draft in the first place). I personally don't mind at all = the second mechanism, as I'm a big fan of out-of-band parameter set transmi= ssion and any middle box must be in the signaling path anyway to meaningful= ly manipulate RTP. I do not like the first option due to its variable, and= possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for= VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam -- Regards, Adam -- Regards, Adam --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam,

 <= /p>

I meant the scalable code= cs mentioned so far by everyone, including H.265/HEVC and its extensions, a= nd H.264/AVC and its extensions.

 <= /p>

BR, YK<= /p>

 <= /p>

From:= Adam Fineberg [mail= to:fineberg@vline.me]
Sent: Wednesday, July 24, 2013 3:55 PM
To: Wang, Ye-Kui
Cc: Bernard Aboba; avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

YK,

I would appreciate your collaboration.  Which codecs are you referring= to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specif= y something generic, naturally it should be generic enough to cover at leas= t all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, wh= y limit to only a few scalable video codecs?

 <= /p>

I could provide some help= here too if needed.

 <= /p>

BR, YK<= /p>

 <= /p>

From:= avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seei= ng the benefits.  Since the fields are not the same for the codecs, we= will be multiplexing the bits and that seems to me to add complexity rathe= r than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the gro= up thinks generalization is the right approach I would appreciate some coll= aboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:=

I do not think it is = necessary to "support all forms of scalability for all codecs".&n= bsp;  In fact, I would make that an explicit "non-goal".&nbs= p; All that was suggested is to try to create a single extension that suppo= rts a few common cases.   If it is possible to handle VP8, VP9 and H= .264/SVC in a single extension that would be sufficient.  So why not l= imit it to that?

Date: Tue, 23 Jul 201= 3 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ie= tf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by = trying to capture all this in a single header extension rather than one per= that can succinctly explain the fields without the complexity of multiplex= ing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:=

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stew= e.org>
Cc: Justin Uberti <juberti@= google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <a= vtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are sugg= esting that except in the simple case, that the data for H.265 would not be= well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band= signaling of the VPS as you mention but that would not be within the scope= of this header extension.

 

StW: well, if you would copy the layer_id int= o your header extension (just as you need to do for the simple case), a rea= lly smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the f= irst place.  Insofar, I wouldn't rule out the second option on technic= al grounds.  Whether any of the actual products would bother to do tha= t, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could me= an that you need multiple specs.  First, a generic header extension me= chanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although tha= t is the main customer today.  And second, for each "payload"= ; (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (incl= uding scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a = mapping of the bits available in the generic header extension to the bits i= n the payload itself (NAL header and VPS in case of H.265, NALU header in S= VC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrot= e:

Hi,

I also believe that 16 bits should be e= nough.  For H.264 and VP8 that has already been demonstrated.  Fo= r H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SH= VC) is currently under development.  The current working draft can be = found here: http://phenix.i= nt-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

 

That said, the ordering by the encoder = is just a recommendation, and there may well be cases where different pruni= ng strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2= D scalable tools only, the other including view_id for multi view coding. &= nbsp;By looking at the six bit field alone, a middle box will not be able t= o meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In= order to meaningfully deal with that scenario, there would be two options:= one to represent the dimension_id[][] (and associated control info) in the= header extension, or require the middle box to have access to the VPS and be able to interpret its content.  = The further could take considerably more than 16 bits and we would be talki= ng about a variable length data structure.  The latter requires the mi= ddle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS wo= uld not be useful under the assumption that the middle box does not have th= e key to the media—which is the motivation of the draft in the first = place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmissi= on and any middle box must be in the signaling path anyway to meaningfully = manipulate RTP.  I do not like the first option due to its variable, a= nd possibly substantial, overhead.

 

Stephan   <= /p>

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <b= ernard_aboba@hotmail.com>
Cc: "avtext@ietf.org&quo= t; <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-finebe= rg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to des= ign for. Since in each case there are fairly low limits on the number of su= pported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids int= o 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernar= d Aboba <= bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.26= 4/5 SVC

that would be a start. It seems doable = to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think = it may be possible to generalize this.  For example, for H.264/SVC whi= ch can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what= you call the temporal layer index).   

Date: Th= u, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline= .me
To: bernard_= aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote= :

Since the need is not codec specific (e= .g. it arises with any codec supporting temporal, spatial and quality scala= bility), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline= .me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to= have access to the keys as well as the because of the added overhead of th= e decrypt/encrypt cycle. This draft proposes an RTP header extension that w= ill allow us to use the VP8 temporal layer information included in the header extension and therefore do forwar= ding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subjec= t:

New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Date:<= /b>

Tue, 09 Jul 2013 10:02:05 -0700

From:<= /b>

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com><= /p> 





A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt<=
o:p>
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-finebe=
rg-avtext-temporal-layer-ext
Revision:         00
Title:          &nbs=
p; A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal L=
ayer Information
Creation date:    2013-07-08
Group:          &nbs=
p; Individual Submission
Number of pages: 6
URL:           =
  http://www.ietf.org/internet-=
drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-=
temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext=
-00
 
 
Abstract:
   This document defines a mechanism by which packets of Rea=
l-Time
   Tranport Protocol (RTP) video streams encoded with the VP=
8 codec can
   indicate, in an RTP header extension, the temporal layer =
information
   about the frame encoded in the RTP packet.  This inf=
ormation can be
   used in a middlebox performing bandwidth management of st=
reams
   without requiring it to decrypt the streams.


_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

 

-- 
Regards,
Adam

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

 




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf=
.org/mailman/listinfo/avtext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam




-- 
Regards,
Adam



-- 
Regards,
Adam
--_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_-- From stewe@stewe.org Thu Jul 25 00:45:14 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D42B21F9287; Thu, 25 Jul 2013 00:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILC7xfcMpgrG; Thu, 25 Jul 2013 00:45:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99021F99CE; Thu, 25 Jul 2013 00:45:06 -0700 (PDT) Received: from BN1PR07MB183.namprd07.prod.outlook.com (10.242.216.148) by BN1PR07MB182.namprd07.prod.outlook.com (10.242.216.153) with Microsoft SMTP Server (TLS) id 15.0.731.12; Thu, 25 Jul 2013 07:44:58 +0000 Received: from BN1PR07MB183.namprd07.prod.outlook.com ([169.254.9.26]) by BN1PR07MB183.namprd07.prod.outlook.com ([169.254.9.54]) with mapi id 15.00.0731.000; Thu, 25 Jul 2013 07:44:51 +0000 From: Stephan Wenger To: Adam Fineberg , "Wang, Ye-Kui" Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiQrYv+z3B69wuEOSedMUp37hRw== Date: Thu, 25 Jul 2013 07:44:50 +0000 Message-ID: In-Reply-To: <51F05B32.5080401@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.202.153.34] x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(51914003)(377424004)(13464003)(51444003)(2473001)(479174003)(377454003)(24454002)(189002)(199002)(49866001)(19580385001)(47976001)(74662001)(19580405001)(4396001)(74502001)(31966008)(66066001)(47736001)(50986001)(65816001)(83322001)(59766001)(79102001)(77982001)(51856001)(63696002)(56816003)(76786001)(15202345003)(36756003)(74706001)(76482001)(77096001)(16236675002)(81542001)(56776001)(80022001)(53806001)(76176001)(76796001)(46102001)(8558605003)(69226001)(83072001)(47446002)(74876001)(74366001)(19580395003)(81342001)(54316002)(54356001)(16406001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR07MB182; H:BN1PR07MB183.namprd07.prod.outlook.com; CLIP:195.202.153.34; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE169EA79FC3Cstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:45:14 -0000 --_000_CE169EA79FC3Cstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I thought about this a bit more. I think that one sensible document struct= ure may be as follows: (1) generic structure of scalability/pruning information to an RTP header e= xtension (to be worked on in avtext). (2) mapping of codec-specific features to the generic structure. As a loca= tion, I would suggest that (for new codecs) the RTP payload specs are the r= ight document. For codecs with existing RTP payload specs, a short doc tha= t updates the payload spec would be the right place, or a revision of the p= ayload spec itself if that needs to be done anyway. This would bundle all = the codec-specifics to one document. This document structure, and the philosophy behind it, would allow the desi= gn of a generic RTP stack that could take advantage of scalability features= independently of the scalable codec actually in use. I believe that such = an advantage outweighs the possible advantage of quick standardization of a= more specific approach as proposed in Adam's draft. That said, we need to= get the design of the generic structure right such that it is indeed usefu= l, ideally for all present and hopefully for a large subset of future codec= s. As for the specs involved: -H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably stable dr= afts. -No one uses H.263 and MPEG-2 scalability, so we can ignore those two. -As Adam, I'm also not aware of a VP9 payload spec draft. However, my unde= rstanding is that VP9 will include a number of scalability features enabled= by multiple reference pictures and reference picture resampling. The latt= er is a somewhat different approach compared to the traditional scalability= implementations. I think that google planned to freeze the VP9 bitstream = a few weeks go, but I don't know whether that has happened. Without a stab= le spec and/or input from google/webm folks it will indeed be hard to addre= ss VP9's specific needs, if any. -There are a bunch of audio codecs that claim to be scalable. We should ha= ve a scope discussion on whether those need to be included here. Stephan From: Adam Fineberg > Date: Thursday, 25 July, 2013 00:54 To: "Wang, Ye-Kui" = > Cc: Bernard Aboba >, "avtext@ietf.org" >, "rtcweb@ietf.org" >, Justin Uberti > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt YK, I would appreciate your collaboration. Which codecs are you referring to w= hen you say "all existing standard scalable video codecs"? Regards, Adam On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: If the group is to specify something generic, naturally it should be generi= c enough to cover at least all existing standard scalable video codecs if p= ossible. And I personally think that is possible and not difficult at all. = Thus, why limit to only a few scalable video codecs? I could provide some help here too if needed. BR, YK From:avtext-bounces@ietf.org [mailto:avtext= -bounces@ietf.org] On Behalf Of Adam Fineberg Sent: Wednesday, July 24, 2013 10:08 AM To: Bernard Aboba Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Bernard, I apologize if I come across as being difficult here but I stil am not seei= ng the benefits. Since the fields are not the same for the codecs, we will= be multiplexing the bits and that seems to me to add complexity rather tha= n add clarity. Also, I can't find an IETF VP9 document for the payload for= mat to reference. If the group thinks generalization is the right approach= I would appreciate some collaboration on getting the right bit definitions= for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: I do not think it is necessary to "support all forms of scalability for all= codecs". In fact, I would make that an explicit "non-goal". All that wa= s suggested is to try to create a single extension that supports a few comm= on cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single = extension that would be sufficient. So why not limit it to that? ________________________________ Date: Tue, 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com; bernard_aboba@hotmail.co= m; avtext@ietf.org; rtcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach. = I'm not sure what we really gain by trying to capture all this in a single = header extension rather than one per that can succinctly explain the fields= without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams=97ideally not only for scalab= le video, although that is the main customer today. And second, for each "= payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v= 2 (including scalable and 3D extensions, which are not yet finalized), VP8,= and VP9 (I know little about the latter), plus Daala, and whatnot) a mappi= ng of the bits available in the generic header extension to the bits in the= payload itself (NAL header and VPS in case of H.265, NALU header in SVC, a= nd the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for= VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam -- Regards, Adam -- Regards, Adam --_000_CE169EA79FC3Cstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <446B66DD7F4F094BA036DA39D17EBCF7@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
I thought about this a bit more.  I think that one sensible docum= ent structure may be as follows:

(1) generic structure of scalability/pruning information to an RTP hea= der extension (to be worked on in avtext).
(2) mapping of codec-specific features to the generic structure.  = ;As a location, I would suggest that (for new codecs) the RTP payload specs= are the right document.  For codecs with existing RTP payload specs, = a short doc that updates the payload spec would be the right place, or a revision of the payload spec itself if that= needs to be done anyway.  This would bundle all the codec-specifics t= o one document.

This document structure, and the philosophy behind it, would allow the= design of a generic RTP stack that could take advantage of scalability fea= tures independently of the scalable codec actually in use.  I believe = that such an advantage outweighs the possible advantage of quick standardization of a more specific approach as= proposed in Adam's draft.  That said, we need to get the design of th= e generic structure right such that it is indeed useful, ideally for all pr= esent and hopefully for a large subset of future codecs.

As for the specs involved:
-H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably stab= le drafts.
-No one uses H.263 and MPEG-2 scalability, so we can ignore those two.=
-As Adam, I'm also not aware of a VP9 payload spec draft.  Howeve= r, my understanding is that VP9 will include a number of scalability featur= es enabled by multiple reference pictures and reference picture resampling.=  The latter is a somewhat different approach compared to the traditional scalability implementations.  I = think that google planned to freeze the VP9 bitstream a few weeks go, but I= don't know whether that has happened.  Without a stable spec and/or i= nput from google/webm folks it will indeed be hard to address VP9's specific needs, if any.
-There are a bunch of audio codecs that claim to be scalable.  We= should have a scope discussion on whether those need to be included here.<= /div>

Stephan



From: Adam Fineberg <fineberg@vline.me>
Date: Thursday, 25 July, 2013 00:54=
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Justin Ube= rti <juberti@google.com> Subject: Re: [avtext] [rtcweb] Fwd:= New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.t= xt

YK,

I would appreciate your collaboration.  Which codecs are you referring= to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specify somethi= ng generic, naturally it should be generic enough to cover at least all exi= sting standard scalable video codecs if possible. And I personally think that is possible and not difficult at = all. Thus, why limit to only a few scalable video codecs?=

 

I could provide some help here too= if needed.

 

BR, YK

 

From:avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcwe= b@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seei= ng the benefits.  Since the fields are not the same for the codecs, we= will be multiplexing the bits and that seems to me to add complexity rathe= r than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the gro= up thinks generalization is the right approach I would appreciate some coll= aboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:=

I do not think it is = necessary to "support all forms of scalability for all codecs".&n= bsp;  In fact, I would make that an explicit "non-goal".&nbs= p; All that was suggested is to try to create a single extension that suppo= rts a few common cases.   If it is possible to handle VP8, VP9 and H= .264/SVC in a single extension that would be sufficient.  So why not l= imit it to that?

Date: Tue, 23 Jul 201= 3 08:53:45 -0700
From: fineber= g@vline.me
To: stewe@stewe= .org
CC: juberti@= google.com; berna= rd_aboba@hotmail.com; avtext@ietf.org= ; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by = trying to capture all this in a single header extension rather than one per= that can succinctly explain the fields without the complexity of multiplex= ing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:=

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hot= mail.com>, "avtext@ietf.org" <avtext@iet= f.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are suggesting that except= in the simple case, that the data for H.265 would not be well suited to a = header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of = band signaling of the VPS as you mention but that would not be within the s= cope of this header extension.

 

StW: well, if you would copy the layer_id into your header exte= nsion (just as you need to do for the simple case), a really smart middle b= ox could use this information just as a decoder uses it, assuming that it intercepted the VPS in the f= irst place.  Insofar, I wouldn't rule out the second option on technic= al grounds.  Whether any of the actual products would bother to do tha= t, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could mean that you need m= ultiple specs.  First, a generic header extension mechanism dedicated = to side information required for pruning of RTP packet streams=97ideally not only for scalable video, although that= is the main customer today.  And second, for each "payload"= (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (inclu= ding scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and= whatnot) a mapping of the bits available in the generic header extension t= o the bits in the payload itself (NAL header and VPS in case of H.265, NALU= header in SVC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:

Hi,

I also believe that 16 bits should be enough.  For H= .264 and VP8 that has already been demonstrated.  For H.265, some init= ial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SHVC) is currently u= nder development.  The current working draft can be found here: <= a moz-do-not-send=3D"true" href=3D"http://phenix.int-evry.fr/jct/doc_end_us= er/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip" target=3D"_blank">http://p= henix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3= .zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

 

That said, the ordering by the encoder is just a recommen= dation, and there may well be cases where different pruning strategies may = be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2= D scalable tools only, the other including view_id for multi view coding. &= nbsp;By looking at the six bit field alone, a middle box will not be able t= o meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In= order to meaningfully deal with that scenario, there would be two options:= one to represent the dimension_id[][] (and associated control info) in the= header extension, or require the middle box to have access to the VPS and be able to interpret its content.  = The further could take considerably more than 16 bits and we would be talki= ng about a variable length data structure.  The latter requires the mi= ddle box to have state and a mechanism to intercept the VPS (through signaling=97as the encrypted in-band VPS would = not be useful under the assumption that the middle box does not have the ke= y to the media=97which is the motivation of the draft in the first place). =  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmissi= on and any middle box must be in the signaling path anyway to meaningfully = manipulate RTP.  I do not like the first option due to its variable, a= nd possibly substantial, overhead.

 

Stephan   

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-finebe= rg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to design for. Since in = each case there are fairly low limits on the number of supported layers (i.= e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids int= o 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC=

that would be a start. It seems doable to me.<= /span>


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vl= ine.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think it may be possible= to generalize this.  For example, for H.264/SVC which can support tem= poral, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id= (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:= 45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:

Since the need is not codec specific (e.g. it arises with= any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to= have access to the keys as well as the because of the added overhead of th= e decrypt/encrypt cycle. This draft proposes an RTP header extension that w= ill allow us to use the VP8 temporal layer information included in the header extension and therefore do forwar= ding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subjec= t:

New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Date:<= o:p>

Tue, 09 Jul 2013 10:02:05 -0700

From:<= o:p>

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vli= ne.com>

 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt<=
o:p>
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-av=
text-temporal-layer-ext
Revision:         00

Title:            A =
Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer =
Information


Creation date:    2013-07-08


Group:            In=
dividual Submission


Number of pages: 6


URL:           =
  http=
://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00=
.txt


Status:          http://datatracker.ietf.org/do=
c/draft-fineberg-avtext-temporal-layer-ext


Htmlized:        http://tools.ietf.org/html/draft-fineberg-=
avtext-temporal-layer-ext-00


 


 


Abstract:


   This document defines a mechanism by which packets of Rea=
l-Time


   Tranport Protocol (RTP) video streams encoded with the VP=
8 codec can


   indicate, in an RTP header extension, the temporal layer =
information


   about the frame encoded in the RTP packet.  This inf=
ormation can be


   used in a middlebox performing bandwidth management of st=
reams


   without requiring it to decrypt the streams.


_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

 

-- 
Regards,
Adam

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 



_______________________________________________
avtext mailing list
avtext@iet=
f.orghttps://www.ietf.org/mailman/listinfo/avt=
ext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam



-- 
Regards,
Adam

--=20
Regards,
Adam
 --_000_CE169EA79FC3Cstewesteweorg_-- From jonathan@vidyo.com Thu Jul 25 09:49:53 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA3121F969F; Thu, 25 Jul 2013 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQMyqRYVj-vQ; Thu, 25 Jul 2013 09:49:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5971721F965B; Thu, 25 Jul 2013 09:49:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DA71F5563E1; Thu, 25 Jul 2013 12:49:21 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2DA70556197; Thu, 25 Jul 2013 12:49:21 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 25 Jul 2013 12:48:58 -0400 From: Jonathan Lennox To: Adam Fineberg , "avtext@ietf.org" , "rtcweb@ietf.org" Date: Thu, 25 Jul 2013 12:49:25 -0400 Thread-Topic: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: Ac6JU0u1DNwZuFpiQNmbMxDYxbXH3gAAWYOQ Message-ID: References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> <51E71C82.7090608@vline.me> In-Reply-To: <51E71C82.7090608@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_" MIME-Version: 1.0 Subject: Re: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:49:53 -0000 --_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFkYW0g4oCTDQoNCihTcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsLikNCg0KSSB0aGluayB0 aGVyZeKAmXMgYSBwcm9ibGVtIHdpdGggdGhlIHVzZSBjYXNlIGFzIHlvdeKAmXZlIGRlc2NyaWJl ZCBoZXJlLCB3aGljaCBJIHRoaW5rIGNhbGxzIGludG8gcXVlc3Rpb24gdGhlIHVzZWZ1bG5lc3Mg b2YgdGhlIHdob2xlIG1lY2hhbmlzbS4NCg0KQXMgSSB1bmRlcnN0YW5kIHlvdSwgeW914oCZcmUg cGxhbm5pbmcgdG8gc2VuZCBhIHNpbmdsZSBWUDggc3RyZWFtIGNvbnRhaW5pbmcgYWxsIHRoZSBs YXllcnMsIGFuZCB0aGVuIGhhdmUgYSBtZWRpYS1hd2FyZSBtaWRkbGVib3ggc2VsZWN0aXZlbHkg ZHJvcCBzb21lIG9mIHRoZSBzdHJlYW3igJlzIHBhY2tldHMgdG8gZG8gdGVtcG9yYWwgc2NhbGlu ZyB3aXRob3V0IG5lZWRpbmcgdGhlIG1pZGRsZWJveCB0byBiZSBpbiB0aGUgY3J5cHRvIGNvbnRl eHQuDQoNClVuZm9ydHVuYXRlbHksIFJUUCBkb2VzbuKAmXQgcmVhbGx5IGxldCB5b3UgZG8gdGhp cy4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgYnkganVzdCBkcm9wcGluZyBwYWNrZXRzIHdpdGhvdXQg cmV3cml0aW5nIFJUUCBzZXF1ZW5jZSBudW1iZXJzIG9yIFJUQ1Agc2VuZGVyIHJlcG9ydHMsIHRo aXMgaXMgZ29pbmcgdG8gbG9vayBsaWtlIGVub3Jtb3VzIHBhY2tldCBsb3NzIHRvIFJUUCAod2hp Y2gsIGluIGEgc2Vuc2UsIGl0IGlzKS4gIEEgbWlkZGxlYm94IGxpa2UgdGhpcyDigJMgd2hpY2gg aXMgYWN0aW5nIGFzIGEgbWVkaWEtbW9kaWZ5aW5nIFJUUCB0cmFuc2xhdG9yLCBpbiBSVFAgdGVy bWlub2xvZ3kg4oCTIG5lZWRzIHRvIHJld3JpdGUgUlRQIGhlYWRlcnMgYW5kIFJUQ1Agc2VuZGVy IHJlcG9ydHMgaW4gb3JkZXIgdG8ga2VlcCB0aGUgc3RyZWFtIGFuZCBpdHMgbWV0YWRhdGEgY29u c2lzdGVudCBhbmQgdmFsaWQuDQoNClVuZm9ydHVuYXRlbHksIHRoZSB0cmFuc2xhdG9yIG5lZWRz IHRvIGhhdmUgdGhlIGNyeXB0byBrZXlzIGluIG9yZGVyIHRvIG1ha2UgdGhlc2UgbW9kaWZpY2F0 aW9ucywgc28gSeKAmW0gbm90IHN1cmUgdGhpcyBoZWFkZXIgZXh0ZW5zaW9uIGFkZHMgbXVjaCBi ZW5lZml0IG92ZXIganVzdCB2YWxpZGF0aW5nIHRoZSBhdXRoZW50aWNhdGlvbiwgZGVjcnlwdGlu ZyAoc2F5KSB0aGUgaW5pdGlhbCBibG9jayBvZiB0aGUgcGFja2V0ICh3aGVyZXZlciB0aGUgdGVt cG9yYWwgbGF5ZXIgaW5mb3JtYXRpb24gaXMga25vd24gdG8gYmUpLCBtb2RpZnlpbmcgdGhlIGhl YWRlcnMsIGFuZCB0aGVuIHJlLWF1dGhlbnRpY2F0aW5nIHRoZSBwYWNrZXQuDQoNCklzIHRoZXJl IHNvbWV0aGluZyBJ4oCZbSBtaXNzaW5nIGhlcmU/DQoNCkZyb206IEFkYW0gRmluZWJlcmcgW21h aWx0bzpmaW5lYmVyZ0B2bGluZS5tZV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyA2 OjM3IFBNDQpUbzogYXZ0ZXh0QGlldGYub3JnDQpTdWJqZWN0OiBbYXZ0ZXh0XSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxh eWVyLWV4dC0wMC50eHQNCg0KSGksDQoNCkknbSB3b3JraW5nIG9uIFdlYlJUQyBzZXJ2aWNlcyBh bmQgaGF2ZSBmb3VuZCB0aGF0IHdoaWxlIGRldmVsb3Bpbmcgc2VydmljZXMgdGhhdCBmb3J3YXJk IFZQOCB2aWRlbyBzdHJlYW1zIGlmIHdlIHdhbnQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIFZQ OCB0ZW1wb3JhbCBzY2FsaW5nIHdlIG11c3QgZ2V0IHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1h dGlvbiBmcm9tIHRoZSBSVFAgaGVhZGVyIHdoaWNoIHJlcXVpcmVzIHVzIHRvIGRlY3J5cHQgdGhl IFNSVFAgcGFja2V0cy7vv73Cge+/vSBUaGlzIGlzIHVuZGVzaXJhYmxlIGJvdGggYmVjYXVzZSB0 aGUgbWlkZGxlYm94IG5lZWRzIHRvIGhhdmUgYWNlc3NzIHRvIHRoZSBrZXlzIGFzIHdlbGwgYXMg dGhlIGJlY2F1c2Ugb2YgdGhlIGFkZGVkIG92ZXJoZWFkIG9mIHRoZSBkZWNyeXB0L2VuY3J5cHQg Y3ljbGUu77+9woHvv70gVGhpcyBkcmFmdCBwcm9wb3NlcyBhbiBSVFAgaGVhZGVyIGV4dGVuc2lv biB0aGF0IHdpbGwgYWxsb3cgdXMgdG8gdXNlIHRoZSBWUDggdGVtcG9yYWwgbGF5ZXIgaW5mb3Jt YXRpb24gaW5jbHVkZWQgaW4gdGhlIGhlYWRlciBleHRlbnNpb24gYW5kIHRoZXJlZm9yZSBkbyBm b3J3YXJkaW5nIHdpdGhvdXQgU1JUUCBkZWNyeXB0aW9uLu+/vcKB77+9IENvbW1lbnRzIHdlbGNv bWUuDQoNClJlZ2FyZHMsDQpBZGFtIEZpbmViZXJnDQpmaW5lYmVyZ0B2bGluZS5jb208bWFpbHRv OmZpbmViZXJnQHZsaW5lLmNvbT4NCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0t LQ0KU3ViamVjdDoNCg0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW5lYmVy Zy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dA0KDQpEYXRlOg0KDQpUdWUsIDA5IEp1 bCAyMDEzIDEwOjAyOjA1IC0wNzAwDQoNCkZyb206DQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KQWRhbSBGaW5lYmVy ZyA8ZmluZWJlcmdAdmxpbmUuY29tPjxtYWlsdG86ZmluZWJlcmdAdmxpbmUuY29tPg0KDQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXll ci1leHQtMDAudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRhbSBG aW5lYmVyZyBhbmQgcG9zdGVkIHRvIHRoZQ0KDQpJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpGaWxl bmFtZTogICAgICAgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dA0KDQpS ZXZpc2lvbjogICAgICAgMDANCg0KVGl0bGU6ICAgICAgICAgIEEgUmVhbC1UaW1lIFRyYW5zcG9y dCBQcm90b2NvbCAoUlRQKSBIZWFkZXIgRXh0ZW5zaW9uIGZvciBWUDggVGVtcG9yYWwgTGF5ZXIg SW5mb3JtYXRpb24NCg0KQ3JlYXRpb24gZGF0ZTogIDIwMTMtMDctMDgNCg0KR3JvdXA6ICAgICAg ICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpOdW1iZXIgb2YgcGFnZXM6IDYNCg0KVVJMOiAg ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW5l YmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dA0KDQpTdGF0dXM6ICAgICAgICAg IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRl bXBvcmFsLWxheWVyLWV4dA0KDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDANCg0KDQoN Cg0KDQpBYnN0cmFjdDoNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5 IHdoaWNoIHBhY2tldHMgb2YgUmVhbC1UaW1lDQoNCiAgIFRyYW5wb3J0IFByb3RvY29sIChSVFAp IHZpZGVvIHN0cmVhbXMgZW5jb2RlZCB3aXRoIHRoZSBWUDggY29kZWMgY2FuDQoNCiAgIGluZGlj YXRlLCBpbiBhbiBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgdGhlIHRlbXBvcmFsIGxheWVyIGluZm9y bWF0aW9uDQoNCiAgIGFib3V0IHRoZSBmcmFtZSBlbmNvZGVkIGluIHRoZSBSVFAgcGFja2V0LiAg VGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUNCg0KICAgdXNlZCBpbiBhIG1pZGRsZWJveCBwZXJmb3Jt aW5nIGJhbmR3aWR0aCBtYW5hZ2VtZW50IG9mIHN0cmVhbXMNCg0KICAgd2l0aG91dCByZXF1aXJp bmcgaXQgdG8gZGVjcnlwdCB0aGUgc3RyZWFtcy4NCg0KDQoNCg0KDQoNCg0KDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0KDQo= --_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGksIEFkYW0g4oCTPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4oU3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbC4pPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHRoaW5r IHRoZXJl4oCZcyBhIHByb2JsZW0gd2l0aCB0aGUgdXNlIGNhc2UgYXMgeW914oCZdmUgZGVzY3Jp YmVkIGhlcmUsIHdoaWNoIEkgdGhpbmsgY2FsbHMgaW50byBxdWVzdGlvbiB0aGUgdXNlZnVsbmVz cyBvZiB0aGUgd2hvbGUgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMgSSB1bmRlcnN0 YW5kIHlvdSwgeW914oCZcmUgcGxhbm5pbmcgdG8gc2VuZCBhIHNpbmdsZSBWUDggc3RyZWFtIGNv bnRhaW5pbmcgYWxsIHRoZSBsYXllcnMsIGFuZCB0aGVuIGhhdmUgYSBtZWRpYS1hd2FyZSBtaWRk bGVib3ggc2VsZWN0aXZlbHkgZHJvcCBzb21lIG9mIHRoZSBzdHJlYW3igJlzIHBhY2tldHMgdG8g ZG8gdGVtcG9yYWwgc2NhbGluZyB3aXRob3V0IG5lZWRpbmcgdGhlIG1pZGRsZWJveCB0byBiZSBp biB0aGUgY3J5cHRvIGNvbnRleHQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VW5mb3J0dW5hdGVseSwg UlRQIGRvZXNu4oCZdCByZWFsbHkgbGV0IHlvdSBkbyB0aGlzLsKgIFRoZSBwcm9ibGVtIGlzIHRo YXQgYnkganVzdCBkcm9wcGluZyBwYWNrZXRzIHdpdGhvdXQgcmV3cml0aW5nIFJUUCBzZXF1ZW5j ZSBudW1iZXJzIG9yIFJUQ1Agc2VuZGVyIHJlcG9ydHMsIHRoaXMgaXMgZ29pbmcgdG8gbG9vayBs aWtlIGVub3Jtb3VzIHBhY2tldCBsb3NzIHRvIFJUUCAod2hpY2gsIGluIGEgc2Vuc2UsIGl0IGlz KS7CoCBBIG1pZGRsZWJveCBsaWtlIHRoaXMg4oCTIHdoaWNoIGlzIGFjdGluZyBhcyBhIG1lZGlh LW1vZGlmeWluZyBSVFAgdHJhbnNsYXRvciwgaW4gUlRQIHRlcm1pbm9sb2d5IOKAkyBuZWVkcyB0 byByZXdyaXRlIFJUUCBoZWFkZXJzIGFuZCBSVENQIHNlbmRlciByZXBvcnRzIGluIG9yZGVyIHRv IGtlZXAgdGhlIHN0cmVhbSBhbmQgaXRzIG1ldGFkYXRhIGNvbnNpc3RlbnQgYW5kIHZhbGlkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VW5mb3J0dW5hdGVseSwgdGhlIHRyYW5zbGF0b3IgbmVlZHMgdG8g aGF2ZSB0aGUgY3J5cHRvIGtleXMgaW4gb3JkZXIgdG8gbWFrZSB0aGVzZSBtb2RpZmljYXRpb25z LCBzbyBJ4oCZbSBub3Qgc3VyZSB0aGlzIGhlYWRlciBleHRlbnNpb24gYWRkcyBtdWNoIGJlbmVm aXQgb3ZlciBqdXN0IHZhbGlkYXRpbmcgdGhlIGF1dGhlbnRpY2F0aW9uLCBkZWNyeXB0aW5nIChz YXkpIHRoZSBpbml0aWFsIGJsb2NrIG9mIHRoZSBwYWNrZXQgKHdoZXJldmVyIHRoZSB0ZW1wb3Jh bCBsYXllciBpbmZvcm1hdGlvbiBpcyBrbm93biB0byBiZSksIG1vZGlmeWluZyB0aGUgaGVhZGVy cywgYW5kIHRoZW4gcmUtYXV0aGVudGljYXRpbmcgdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPklzIHRoZXJlIHNvbWV0aGluZyBJ4oCZbSBtaXNzaW5nIGhlcmU/PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0 Jz4gQWRhbSBGaW5lYmVyZyBbbWFpbHRvOmZpbmViZXJnQHZsaW5lLm1lXSA8YnI+PGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyA2OjM3IFBNPGJyPjxiPlRvOjwvYj4gYXZ0ZXh0 QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbYXZ0ZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0w MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5IaSw8YnI+PGJyPkknbSB3 b3JraW5nIG9uIFdlYlJUQyBzZXJ2aWNlcyBhbmQgaGF2ZSBmb3VuZCB0aGF0IHdoaWxlIGRldmVs b3Bpbmcgc2VydmljZXMgdGhhdCBmb3J3YXJkIFZQOCB2aWRlbyBzdHJlYW1zIGlmIHdlIHdhbnQg dG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIFZQOCB0ZW1wb3JhbCBzY2FsaW5nIHdlIG11c3QgZ2V0 IHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1hdGlvbiBmcm9tIHRoZSBSVFAgaGVhZGVyIHdoaWNo IHJlcXVpcmVzIHVzIHRvIGRlY3J5cHQgdGhlIFNSVFAgcGFja2V0cy48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+woE8c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+IFRoaXMgaXMgdW5k ZXNpcmFibGUgYm90aCBiZWNhdXNlIHRoZSBtaWRkbGVib3ggbmVlZHMgdG8gaGF2ZSBhY2Vzc3Mg dG8gdGhlIGtleXMgYXMgd2VsbCBhcyB0aGUgYmVjYXVzZSBvZiB0aGUgYWRkZWQgb3ZlcmhlYWQg b2YgdGhlIGRlY3J5cHQvZW5jcnlwdCBjeWNsZS48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+woE8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+IFRoaXMgZHJhZnQgcHJvcG9zZXMgYW4g UlRQIGhlYWRlciBleHRlbnNpb24gdGhhdCB3aWxsIGFsbG93IHVzIHRvIHVzZSB0aGUgVlA4IHRl bXBvcmFsIGxheWVyIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoZSBoZWFkZXIgZXh0ZW5zaW9u IGFuZCB0aGVyZWZvcmUgZG8gZm9yd2FyZGluZyB3aXRob3V0IFNSVFAgZGVjcnlwdGlvbi48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+woE8 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+ IENvbW1lbnRzIHdlbGNvbWUuPGJyPjxicj5SZWdhcmRzLDxicj5BZGFtIEZpbmViZXJnPG86cD48 L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0ibWFpbHRvOmZpbmViZXJn QHZsaW5lLmNvbSI+ZmluZWJlcmdAdmxpbmUuY29tPC9hPjxicj48YnI+LS0tLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFs VGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wPjx0cj48dGQgbm93cmFw IHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPlN1YmplY3Q6IDxv OnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4n PjxwIGNsYXNzPU1zb05vcm1hbD5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZp bmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDAudHh0PG86cD48L286cD48L3A+PC90 ZD48L3RyPjx0cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246 cmlnaHQnPjxiPkRhdGU6IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGlu ZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5UdWUsIDA5IEp1bCAyMDEzIDEw OjAyOjA1IC0wNzAwPG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgbm93cmFwIHZhbGln bj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwg YWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPkZyb206IDxvOnA+PC9vOnA+ PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbD48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQg bm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPlRvOiA8 bzpwPjwvbzpwPjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWw+QWRhbSBGaW5lYmVyZyA8YSBocmVmPSJtYWlsdG86ZmluZWJl cmdAdmxpbmUuY29tIj4mbHQ7ZmluZWJlcmdAdmxpbmUuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwv cD48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48cHJlPkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dDxvOnA+PC9v OnA+PC9wcmU+PHByZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkYW0gRmlu ZWJlcmcgYW5kIHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+SUVURiByZXBvc2l0 b3J5LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Rmls ZW5hbWU6wqDCoMKgwqDCoCAgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4 dDxvOnA+PC9vOnA+PC9wcmU+PHByZT5SZXZpc2lvbjrCoMKgwqDCoMKgICAwMDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5UaXRsZTrCoMKgwqDCoMKgwqDCoMKgICBBIFJlYWwtVGltZSBUcmFuc3BvcnQg UHJvdG9jb2wgKFJUUCkgSGVhZGVyIEV4dGVuc2lvbiBmb3IgVlA4IFRlbXBvcmFsIExheWVyIElu Zm9ybWF0aW9uPG86cD48L286cD48L3ByZT48cHJlPkNyZWF0aW9uIGRhdGU6ICAyMDEzLTA3LTA4 PG86cD48L286cD48L3ByZT48cHJlPkdyb3VwOsKgwqDCoMKgwqDCoMKgwqAgIEluZGl2aWR1YWwg U3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT5OdW1iZXIgb2YgcGFnZXM6IDY8bzpwPjwv bzpwPjwvcHJlPjxwcmU+VVJMOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW5lYmVyZy1hdnRleHQtdGVt cG9yYWwtbGF5ZXItZXh0LTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0wMC50eHQ8L2E+PG86 cD48L286cD48L3ByZT48cHJlPlN0YXR1czrCoMKgwqDCoMKgwqDCoMKgwqAgPGEgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9y YWwtbGF5ZXItZXh0Ij5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbmVi ZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQ8L2E+PG86cD48L286cD48L3ByZT48cHJlPkh0 bWxpemVkOsKgwqDCoMKgwqDCoMKgIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDAiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQt MDA8L2E+PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT48cHJl PsKgwqAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHBhY2tldHMg b2YgUmVhbC1UaW1lPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgVHJhbnBvcnQgUHJvdG9jb2wg KFJUUCkgdmlkZW8gc3RyZWFtcyBlbmNvZGVkIHdpdGggdGhlIFZQOCBjb2RlYyBjYW48bzpwPjwv bzpwPjwvcHJlPjxwcmU+wqDCoCBpbmRpY2F0ZSwgaW4gYW4gUlRQIGhlYWRlciBleHRlbnNpb24s IHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKg IGFib3V0IHRoZSBmcmFtZSBlbmNvZGVkIGluIHRoZSBSVFAgcGFja2V0LsKgIFRoaXMgaW5mb3Jt YXRpb24gY2FuIGJlPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgdXNlZCBpbiBhIG1pZGRsZWJv eCBwZXJmb3JtaW5nIGJhbmR3aWR0aCBtYW5hZ2VtZW50IG9mIHN0cmVhbXM8bzpwPjwvbzpwPjwv cHJlPjxwcmU+wqDCoCB3aXRob3V0IHJlcXVpcmluZyBpdCB0byBkZWNyeXB0IHRoZSBzdHJlYW1z LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_-- From fineberg@vline.me Thu Jul 25 20:35:17 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1421F8C66; Thu, 25 Jul 2013 20:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-att3ZLJR-P; Thu, 25 Jul 2013 20:35:16 -0700 (PDT) Received: from cat2.kjsl.com (cat2.kjsl.com [IPv6:2001:1868:2001::30]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA121F8476; Thu, 25 Jul 2013 20:35:14 -0700 (PDT) Received: from Adam-Finebergs-MacBook-Pro-2.local (75-25-130-225.lightspeed.sjcpca.sbcglobal.net [75.25.130.225]) (Authenticated sender: fineberg) by cat2.kjsl.com (Postfix) with ESMTP id B38AC12550A; Thu, 25 Jul 2013 23:35:11 -0400 (EDT) Message-ID: <51F1EE6E.4060408@vline.me> Date: Thu, 25 Jul 2013 20:35:10 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Lennox References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> <51E71C82.7090608@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090908010601070603080408" Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 03:35:17 -0000 This is a multi-part message in MIME format. --------------090908010601070603080408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Jonathan, Thanks for the feedback. You are of course correct, I'm not sure why I forgot about the authentication of the RTP header. The intent was not to have to perform the crypto on the payload of course but it would still require header changes which therefore needs the header re-authenticated. Regards, Adam On 7/25/13 9:49 AM, Jonathan Lennox wrote: > > Hi, Adam – > > (Speaking as an individual.) > > I think there’s a problem with the use case as you’ve described here, > which I think calls into question the usefulness of the whole mechanism. > > As I understand you, you’re planning to send a single VP8 stream > containing all the layers, and then have a media-aware middlebox > selectively drop some of the stream’s packets to do temporal scaling > without needing the middlebox to be in the crypto context. > > Unfortunately, RTP doesn’t really let you do this. The problem is > that by just dropping packets without rewriting RTP sequence numbers > or RTCP sender reports, this is going to look like enormous packet > loss to RTP (which, in a sense, it is). A middlebox like this – which > is acting as a media-modifying RTP translator, in RTP terminology – > needs to rewrite RTP headers and RTCP sender reports in order to keep > the stream and its metadata consistent and valid. > > Unfortunately, the translator needs to have the crypto keys in order > to make these modifications, so I’m not sure this header extension > adds much benefit over just validating the authentication, decrypting > (say) the initial block of the packet (wherever the temporal layer > information is known to be), modifying the headers, and then > re-authenticating the packet. > > Is there something I’m missing here? > > *From:*Adam Fineberg [mailto:fineberg@vline.me] > *Sent:* Wednesday, July 17, 2013 6:37 PM > *To:* avtext@ietf.org > *Subject:* [avtext] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the temporal layer information > from the RTP header which requires us to decrypt the SRTP packets.�� > This is undesirable both because the middlebox needs to have acesss to > the keys as well as the because of the added overhead of the > decrypt/encrypt cycle.�� This draft proposes an RTP header extension > that will allow us to use the VP8 temporal layer information included > in the header extension and therefore do forwarding without SRTP > decryption.�� Comments welcome. > > Regards, > Adam Fineberg > > fineberg@vline.com > > -------- Original Message -------- > > *Subject: * > > > > New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > *Date: * > > > > Tue, 09 Jul 2013 10:02:05 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Adam Fineberg > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > > > The IETF Secretariat > > --------------090908010601070603080408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Jonathan,

Thanks for the feedback.  You are of course correct, I'm not sure why I forgot about the authentication of the RTP header.  The intent was not to have to perform the crypto on the payload of course but it would still require header changes which therefore needs the header re-authenticated.

Regards,
Adam

On 7/25/13 9:49 AM, Jonathan Lennox wrote:

Hi, Adam –

 

(Speaking as an individual.)

 

I think there’s a problem with the use case as you’ve described here, which I think calls into question the usefulness of the whole mechanism.

 

As I understand you, you’re planning to send a single VP8 stream containing all the layers, and then have a media-aware middlebox selectively drop some of the stream’s packets to do temporal scaling without needing the middlebox to be in the crypto context.

 

Unfortunately, RTP doesn’t really let you do this.  The problem is that by just dropping packets without rewriting RTP sequence numbers or RTCP sender reports, this is going to look like enormous packet loss to RTP (which, in a sense, it is).  A middlebox like this – which is acting as a media-modifying RTP translator, in RTP terminology – needs to rewrite RTP headers and RTCP sender reports in order to keep the stream and its metadata consistent and valid.

 

Unfortunately, the translator needs to have the crypto keys in order to make these modifications, so I’m not sure this header extension adds much benefit over just validating the authentication, decrypting (say) the initial block of the packet (wherever the temporal layer information is known to be), modifying the headers, and then re-authenticating the packet.

 

Is there something I’m missing here?

                                                                                                                                                                                                                                                        

From: Adam Fineberg [mailto:fineberg@vline.me]
Sent: Wednesday, July 17, 2013 6:37 PM
To: avtext@ietf.org
Subject: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets.�� This is undesirable both because the middlebox needs to have acesss to the keys as well as the because of the added overhead of the decrypt/encrypt cycle.�� This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption.�� Comments welcome.

Regards,
Adam Fineberg

fineberg@vline.com

-------- Original Message --------

Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

internet-drafts@ietf.org

To:

Adam Fineberg <fineberg@vline.com>

 

A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:       draft-fineberg-avtext-temporal-layer-ext
Revision:       00
Title:          A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:  2013-07-08
Group:          Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
 
 
Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.
 
                                                                                  
 
 
The IETF Secretariat
 

 


--------------090908010601070603080408-- From fineberg@vline.me Fri Jul 26 06:14:32 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2621F95DC; Fri, 26 Jul 2013 06:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTfy3wD58am0; Fri, 26 Jul 2013 06:14:29 -0700 (PDT) Received: from cat2.kjsl.com (cat2.kjsl.com [IPv6:2001:1868:2001::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4A01221F95BD; Fri, 26 Jul 2013 06:14:29 -0700 (PDT) Received: from Adam-Finebergs-MacBook-Pro-2.local (75-25-130-225.lightspeed.sjcpca.sbcglobal.net [75.25.130.225]) (Authenticated sender: fineberg) by cat2.kjsl.com (Postfix) with ESMTP id 453A212550C; Fri, 26 Jul 2013 09:14:26 -0400 (EDT) Message-ID: <51F27631.7060709@vline.me> Date: Fri, 26 Jul 2013 06:14:25 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040608040800000106080000" Cc: Bernard Aboba , "avtext@ietf.org" , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:14:32 -0000 This is a multi-part message in MIME format. --------------040608040800000106080000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Stephan, This seems like a reasonable approach. I like your point about designing the RTP stack to generically handle scalability features. My concern is complexity and overhead for what should be a very lightweight process however generalizing seems to be the consensus so that should be the direction forward. Regards, Adam On 7/25/13 12:44 AM, Stephan Wenger wrote: > Hi, > I thought about this a bit more. I think that one sensible document > structure may be as follows: > > (1) generic structure of scalability/pruning information to an RTP > header extension (to be worked on in avtext). > (2) mapping of codec-specific features to the generic structure. As a > location, I would suggest that (for new codecs) the RTP payload specs > are the right document. For codecs with existing RTP payload specs, a > short doc that updates the payload spec would be the right place, or a > revision of the payload spec itself if that needs to be done anyway. > This would bundle all the codec-specifics to one document. > > This document structure, and the philosophy behind it, would allow the > design of a generic RTP stack that could take advantage of scalability > features independently of the scalable codec actually in use. I > believe that such an advantage outweighs the possible advantage of > quick standardization of a more specific approach as proposed in > Adam's draft. That said, we need to get the design of the generic > structure right such that it is indeed useful, ideally for all present > and hopefully for a large subset of future codecs. > > As for the specs involved: > -H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably > stable drafts. > -No one uses H.263 and MPEG-2 scalability, so we can ignore those two. > -As Adam, I'm also not aware of a VP9 payload spec draft. However, my > understanding is that VP9 will include a number of scalability > features enabled by multiple reference pictures and reference picture > resampling. The latter is a somewhat different approach compared to > the traditional scalability implementations. I think that google > planned to freeze the VP9 bitstream a few weeks go, but I don't know > whether that has happened. Without a stable spec and/or input from > google/webm folks it will indeed be hard to address VP9's specific > needs, if any. > -There are a bunch of audio codecs that claim to be scalable. We > should have a scope discussion on whether those need to be included here. > > Stephan > > > > From: Adam Fineberg > > Date: Thursday, 25 July, 2013 00:54 > To: "Wang, Ye-Kui" > > Cc: Bernard Aboba >, "avtext@ietf.org > " >, > "rtcweb@ietf.org " >, Justin Uberti > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > YK, > > I would appreciate your collaboration. Which codecs are you referring > to when you say "all existing standard scalable video codecs"? > > Regards, > Adam > > On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: >> >> If the group is to specify something generic, naturally it should be >> generic enough to cover at least all existing standard scalable video >> codecs if possible. And I personally think that is possible and not >> difficult at all. Thus, why limit to only a few scalable video codecs? >> >> I could provide some help here too if needed. >> >> BR, YK >> >> *From:*avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] *On >> Behalf Of *Adam Fineberg >> *Sent:* Wednesday, July 24, 2013 10:08 AM >> *To:* Bernard Aboba >> *Cc:* avtext@ietf.org; rtcweb@ietf.org; Justin Uberti >> *Subject:* Re: [avtext] [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Bernard, >> >> I apologize if I come across as being difficult here but I stil am >> not seeing the benefits. Since the fields are not the same for the >> codecs, we will be multiplexing the bits and that seems to me to add >> complexity rather than add clarity. Also, I can't find an IETF VP9 >> document for the payload format to reference. If the group thinks >> generalization is the right approach I would appreciate some >> collaboration on getting the right bit definitions for the other codecs. >> >> Regards, >> Adam >> >> On 7/23/13 12:07 PM, Bernard Aboba wrote: >> >> I do not think it is necessary to "support all forms of >> scalability for all codecs". In fact, I would make that an >> explicit "non-goal". All that was suggested is to try to create >> a single extension that supports a few common cases. If it is >> possible to handle VP8, VP9 and H.264/SVC in a single extension >> that would be sufficient. So why not limit it to that? >> >> ------------------------------------------------------------------------ >> >> Date: Tue, 23 Jul 2013 08:53:45 -0700 >> From: fineberg@vline.me >> To: stewe@stewe.org >> CC: juberti@google.com ; >> bernard_aboba@hotmail.com ; >> avtext@ietf.org ; rtcweb@ietf.org >> >> Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> I've been thinking about this and given the ease at which RFC5285 >> allows for the specification of a header extension and the >> complexity introduced by trying to generalize the header >> extension to support all forms of scalability for all codecs that >> the generalization might not be the best approach. I'm not sure >> what we really gain by trying to capture all this in a single >> header extension rather than one per that can succinctly explain >> the fields without the complexity of multiplexing the bits. >> >> Thoughts? >> >> Regards, >> Adam >> >> On 7/19/13 3:44 PM, Stephan Wenger wrote: >> >> Hi, >> >> *From: *Adam Fineberg > > >> *Date: *Friday, 19 July, 2013 15:12 >> *To: *Stephan Wenger > >> *Cc: *Justin Uberti > >, Bernard Aboba >> > >, "avtext@ietf.org >> " > >, "rtcweb@ietf.org >> " > > >> *Subject: *Re: [avtext] [rtcweb] Fwd: New Version >> Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Stephan, >> >> Thanks for the info and the reference. I'm not sure I follow >> as I'm not at all familiar with H.265. I'll review the >> reference and see what I can figure. >> >> StW: Good luck :-) >> >> It seems though to me that you are suggesting that except in >> the simple case, that the data for H.265 would not be well >> suited to a header extension, am I understanding you >> correctly? There is no reason the middlebox couldn't get out >> of band signaling of the VPS as you mention but that would >> not be within the scope of this header extension. >> >> StW: well, if you would copy the layer_id into your header >> extension (just as you need to do for the simple case), a >> really smart middle box could use this information just as a >> decoder uses it, assuming that it intercepted the VPS in the >> first place. Insofar, I wouldn't rule out the second option >> on technical grounds. Whether any of the actual products >> would bother to do that, ever, is another question. I think >> the case ought to be documented, though. I can help drafting >> text. >> >> While we are at it: doing this right could mean that you need >> multiple specs. First, a generic header extension mechanism >> dedicated to side information required for pruning of RTP >> packet streamsideally not only for scalable video, although >> that is the main customer today. And second, for each >> "payload" (at present we are talking about H.264/SVC, H.265v1 >> (HEVC), H.265v2 (including scalable and 3D extensions, which >> are not yet finalized), VP8, and VP9 (I know little about the >> latter), plus Daala, and whatnot) a mapping of the bits >> available in the generic header extension to the bits in the >> payload itself (NAL header and VPS in case of H.265, NALU >> header in SVC, and the fields you mention for VP8). >> >> Stephan >> >> >> >> Any insights are appreciated. >> >> Regards, >> Adam >> >> On 7/19/13 8:33 AM, Stephan Wenger wrote: >> >> Hi, >> >> I also believe that 16 bits should be enough. For H.264 >> and VP8 that has already been demonstrated. For H.265, >> some initial thoughts below. Apologies for the word-count. >> >> The scalable version of H265 (called SHVC) is currently >> under development. The current working draft can be >> found here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. >> Therein, the options for defining layering structures >> are considerably more complex. To start, we have 3 bits >> for the temporal ID in the NAL unit header of the H.265 >> version 1 (HEVC) base specification (temporal scalability >> is already nicely supported in version 1). Just like in >> SVC. In the scalable extension, the NAL unit header >> contains a six bit field that points into a data >> structure known as "Video Parameter Set" (VPS). Inside >> the VPS, those six bits are mapped to to a position in a >> directed graph (specified through "dimension_id[][]"), >> which tells you about the reference relationship of the >> layer in question and its parent layer. One can >> recursively follow the graph to determine what used to be >> called dependency_id, quality_id, view_id, and whatnot. >> The six bit pointer field can (or: is to be when >> possible) organized by the encoder such that it is >> prudent for a middle box to throw away NAL units >> (belonging to layers) with higher values of the six bit >> field first, before throwing away NAL units with lower >> values. Relying on this feature, 3+6 bits == 9 bits >> should be fine for the header extension. >> >> That said, the ordering by the encoder is just a >> recommendation, and there may well be cases where >> different pruning strategies may be advisable. For >> example, a layering structure could be constructed that >> expands into two branches, one using 2D scalable tools >> only, the other including view_id for multi view coding. >> By looking at the six bit field alone, a middle box will >> not be able to meaningfully remove NAL units belonging to >> one of the branches completely while pruning the other >> branch. In order to meaningfully deal with that >> scenario, there would be two options: one to represent >> the dimension_id[][] (and associated control info) in the >> header extension, or require the middle box to have >> access to the VPS and be able to interpret its content. >> The further could take considerably more than 16 bits >> and we would be talking about a variable length data >> structure. The latter requires the middle box to have >> state and a mechanism to intercept the VPS (through >> signalingas the encrypted in-band VPS would not be >> useful under the assumption that the middle box does not >> have the key to the mediawhich is the motivation of the >> draft in the first place). I personally don't mind at >> all the second mechanism, as I'm a big fan of out-of-band >> parameter set transmission and any middle box must be in >> the signaling path anyway to meaningfully manipulate RTP. >> I do not like the first option due to its variable, and >> possibly substantial, overhead. >> >> Stephan >> >> *From: *Justin Uberti > > >> *Date: *Friday, 19 July, 2013 06:32 >> *To: *Bernard Aboba > > >> *Cc: *"avtext@ietf.org " >> >, >> "rtcweb@ietf.org " >> > >> *Subject: *Re: [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Agree those are the right codecs to design for. Since in >> each case there are fairly low limits on the number of >> supported layers (i.e. 3 spatial layers for SVC), I think >> it should be possible to pack the temporal, spatial, >> quality layer ids into 16 bits. >> >> On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba >> > > wrote: >> >> If we can support VP8/9 as well as H.264/5 SVC >> >> that would be a start. It seems doable to me. >> >> >> On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" >> > wrote: >> >> Bernard, >> >> Are there other codecs you are thinking should be >> supported? If it's generalized I would think we want >> to be able to cover all known scalable codecs. I'll >> look into the H264/SVC fields to see how to encode >> them in a generalized header. >> >> Regards, >> Adam >> >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >> >> I think it may be possible to generalize this. >> For example, for H.264/SVC which can support >> temporal, spatial and quality scalability, you >> would need the quality_id and dependency_id in >> addition to the temporal_id (what you call the >> temporal layer index). >> >> ------------------------------------------------------------------------ >> >> Date: Thu, 18 Jul 2013 08:45:38 -0700 >> From: fineberg@vline.me >> To: bernard_aboba@hotmail.com >> >> CC: rtcweb@ietf.org ; >> avtext@ietf.org >> Subject: Re: [rtcweb] Fwd: New Version >> Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Bernard, >> >> Good question. I'm not familiar enough with the >> parameter requirements of all other scalable >> codecs to be able to generalize. If you'd like to >> help specify them, I'd be fine revising the draft >> to generalize. >> >> Regards, >> Adam >> >> On 7/17/13 8:26 PM, Bernard Aboba wrote: >> >> Since the need is not codec specific (e.g. it >> arises with any codec supporting temporal, >> spatial and quality scalability), why >> a VP8-specific RTP extension? >> >> ------------------------------------------------------------------------ >> >> Date: Wed, 17 Jul 2013 17:09:46 -0700 >> From: fineberg@vline.me >> >> To: rtcweb@ietf.org >> Subject: [rtcweb] Fwd: New Version >> Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Hi, >> >> I'm working on WebRTC services and have found >> that while developing services that forward >> VP8 video streams if we want to take >> advantage of the VP8 temporal scaling we must >> get the temporal layer information from the >> RTP header which requires us to decrypt the >> SRTP packets. This is undesirable both >> because the middle-box needs to have access >> to the keys as well as the because of the >> added overhead of the decrypt/encrypt cycle. >> This draft proposes an RTP header extension >> that will allow us to use the VP8 temporal >> layer information included in the header >> extension and therefore do forwarding without >> SRTP decryption. Comments welcome. >> >> Regards, >> Adam Fineberg >> >> fineberg at vline.com >> >> >> -------- Original Message -------- >> >> *Subject:* >> >> >> >> New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> *Date:* >> >> >> >> Tue, 09 Jul 2013 10:02:05 -0700 >> >> *From:* >> >> >> >> internet-drafts at ietf.org >> >> >> *To:* >> >> >> >> Adam Fineberg >> >> >> >> >> >> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> has been successfully submitted by Adam Fineberg and posted to the >> >> IETF repository. >> >> >> >> Filename: draft-fineberg-avtext-temporal-layer-ext >> >> Revision: 00 >> >> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >> >> Creation date: 2013-07-08 >> >> Group: Individual Submission >> >> Number of pages: 6 >> >> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >> >> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >> >> >> >> >> >> Abstract: >> >> This document defines a mechanism by which packets of Real-Time >> >> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >> >> indicate, in an RTP header extension, the temporal layer information >> >> about the frame encoded in the RTP packet. This information can be >> >> used in a middlebox performing bandwidth management of streams >> >> without requiring it to decrypt the streams. >> >> >> _______________________________________________ >> rtcweb mailing list rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> -- >> >> Regards, >> >> Adam >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> >> avtext mailing list >> >> avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext >> >> --------------040608040800000106080000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Stephan,

This seems like a reasonable approach. I like your point about designing the RTP stack to generically handle scalability features. My concern is complexity and overhead for what should be a very lightweight process however generalizing seems to be the consensus so that should be the direction forward.

Regards,
Adam

On 7/25/13 12:44 AM, Stephan Wenger wrote:
Hi,
I thought about this a bit more. I think that one sensible document structure may be as follows:

(1) generic structure of scalability/pruning information to an RTP header extension (to be worked on in avtext).
(2) mapping of codec-specific features to the generic structure. As a location, I would suggest that (for new codecs) the RTP payload specs are the right document. For codecs with existing RTP payload specs, a short doc that updates the payload spec would be the right place, or a revision of the payload spec itself if that needs to be done anyway. This would bundle all the codec-specifics to one document.

This document structure, and the philosophy behind it, would allow the design of a generic RTP stack that could take advantage of scalability features independently of the scalable codec actually in use. I believe that such an advantage outweighs the possible advantage of quick standardization of a more specific approach as proposed in Adam's draft. That said, we need to get the design of the generic structure right such that it is indeed useful, ideally for all present and hopefully for a large subset of future codecs.

As for the specs involved:
-H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably stable drafts.
-No one uses H.263 and MPEG-2 scalability, so we can ignore those two.
-As Adam, I'm also not aware of a VP9 payload spec draft. However, my understanding is that VP9 will include a number of scalability features enabled by multiple reference pictures and reference picture resampling. The latter is a somewhat different approach compared to the traditional scalability implementations. I think that google planned to freeze the VP9 bitstream a few weeks go, but I don't know whether that has happened. Without a stable spec and/or input from google/webm folks it will indeed be hard to address VP9's specific needs, if any.
-There are a bunch of audio codecs that claim to be scalable. We should have a scope discussion on whether those need to be included here.

Stephan



From: Adam Fineberg <fineberg@vline.me>
Date: Thursday, 25 July, 2013 00:54
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Justin Uberti <juberti@google.com>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

YK,

I would appreciate your collaboration. Which codecs are you referring to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specify something generic, naturally it should be generic enough to cover at least all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, why limit to only a few scalable video codecs?

I could provide some help here too if needed.

BR, YK

From:avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

I apologize if I come across as being difficult here but I stil am not seeing the benefits. Since the fields are not the same for the codecs, we will be multiplexing the bits and that seems to me to add complexity rather than add clarity. Also, I can't find an IETF VP9 document for the payload format to reference. If the group thinks generalization is the right approach I would appreciate some collaboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:

I do not think it is necessary to "support all forms of scalability for all codecs". In fact, I would make that an explicit "non-goal". All that was suggested is to try to create a single extension that supports a few common cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single extension that would be sufficient. So why not limit it to that?

Date: Tue, 23 Jul 2013 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach. I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:

Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Stephan,

Thanks for the info and the reference. I'm not sure I follow as I'm not at all familiar with H.265. I'll review the reference and see what I can figure.

StW: Good luck :-)

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly? There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it,assumingthat it intercepted the VPS in the first place. Insofar, I wouldn't rule out the second option on technical grounds. Whether any of the actual products would bother to do that, ever, is another question. I think the case ought to be documented, though. I can help drafting text.

While we are at it: doing this right could mean that you need multiple specs. First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streamsideally not only for scalable video, although that is the main customer today. And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:

Hi,

I also believe that 16 bits should be enough. For H.264 and VP8 that has already been demonstrated. For H.265, some initial thoughts below. Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development. The current working draft can be found here:http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the options for defining layering structures are considerably more complex. To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1). Just like in SVC. In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS). Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer. One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot. The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values. Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable. For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding. By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch. In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content. The further could take considerably more than 16 bits and we would be talking about a variable length data structure. The latter requires the middle box to have state and a mechanism to intercept the VPS (through signalingas the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the mediawhich is the motivation of the draft in the first place). I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.

On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC

that would be a start. It seems doable to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported? If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think it may be possible to generalize this. For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question. I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize. If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:

Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
a VP8-specific RTP extension?

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

internet-drafts at ietf.org

To:

Adam Fineberg<fineberg at vline.com>

 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
Filename:  draft-fineberg-avtext-temporal-layer-ext
Revision:  00
Title:  A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:  2013-07-08
Group:  Individual Submission
Number of pages: 6
URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
Abstract:
 This document defines a mechanism by which packets of Real-Time
 Tranport Protocol (RTP) video streams encoded with the VP8 codec can
 indicate, in an RTP header extension, the temporal layer information
 about the frame encoded in the RTP packet. This information can be
 used in a middlebox performing bandwidth management of streams
 without requiring it to decrypt the streams.


_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Regards,
Adam


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext


--------------040608040800000106080000-- From mzanaty@cisco.com Wed Jul 31 08:12:11 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0D321F9B53; Wed, 31 Jul 2013 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crxvJhCYbkC6; Wed, 31 Jul 2013 08:12:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 14F3021F9B5B; Wed, 31 Jul 2013 08:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2567; q=dns/txt; s=iport; t=1375283523; x=1376493123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vGBY5Jhpd5WRoEd+yQYLrG/ATVpelP2Al+Fq9xjb2BM=; b=jG9gYusNqdzf/NyougxhmhLaLJfSduNk+p7afyeRbcvBS4+uFmzVVnjT vsf4kxVOeljSHBDuW8I4npvqyxkDvyO5iqLQXZ2GqrBd+FWRxl2yJxqPV 13NPYt5983I8kl4oHzMRK7puBqv+/lmTlASIcquVrUeGhUZVSbXvHEdYB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAJgo+VGtJXG8/2dsb2JhbABRCoMGNVC+HYEYFnSCJAEBAQR3AgwEAgEIEQMBAgsZCzIdCAIEDgUIAYgHDLhxjkWBETEHBoMScwOIcpAWkCSBW4E5gio X-IronPort-AV: E=Sophos;i="4.89,788,1367971200"; d="scan'208";a="241789237" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 15:12:02 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VFC2tU001532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 15:12:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 10:12:02 -0500 From: "Mo Zanaty (mzanaty)" To: Adam Fineberg Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiJCjF97CHVLHtESLPGspt4xmi5l0Hkhg Date: Wed, 31 Jul 2013 15:12:01 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4C75F3@xmb-rcd-x14.cisco.com> References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> In-Reply-To: <51F00A02.3060204@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.165.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:12:11 -0000 Hi Adam, Why do you include PictureID? I can understand how the "Y" bit for base lay= er sync can be useful to include. But how does including PictureID help ide= ntify temporal layers? Regards, Mo ________________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message --------=20 Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg=A0 A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. --=20 Regards, Adam