Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Adam Fineberg <fineberg@vline.me> Fri, 19 July 2013 22:05 UTC

Return-Path: <fineberg@vline.me>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA521E8097 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 15:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.94
X-Spam-Level:
X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=-0.342, 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 w8H43rf73+QM for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 15:05:44 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0511E8198 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 15:05:44 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id z10so4733221pdj.17 for <rtcweb@ietf.org>; 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=Jazys0a5eRrz7zpEJX9YL4SxWcmrsuhguTKL3zn0SKgOH8H6/Ua+A+LdJ5GJolNJI/ 3bMVKAmraSbVT9VVAfLZe+c9y177CLuqUZfdDTcy2CqN2eCzopU0W8E/ZokSReabUdvu 1oq74pN3PJrMBaOoGtv3TsfmHUWntxvY6w7NTC1uzIZpX3Lax4SRAiIHj6iQSpXXOLha EdANDgOlqFFEjcm2i1uuPRkbLwtzXYR/Vihw5v2B8YarMbND/MRV2bkaF3DOcEBjDi6i X7k8AqxQ0sTfJUHlS3kdgZ2gfXXZ0fsgQyE1PrB1aax9nrubDEnaZrTevnqLKuEQxDFU VOtA==
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 <multiple recipients> (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 <fineberg@vline.me>
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 <bernard_aboba@hotmail.com>
References: <51E7324A.3090405@vline.me> <BLU169-W1238F58A9A258620DA2FE0F93620@phx.gbl> <51E80DA2.4030500@vline.me> <BLU169-W107EA5AE4A7E9D3DB6AFD0893630@phx.gbl> <51E8B3B8.3090502@vline.me> <BLU401-EAS75C2417EF2B049AF14CDF893630@phx.gbl>
In-Reply-To: <BLU401-EAS75C2417EF2B049AF14CDF893630@phx.gbl>
Content-Type: multipart/alternative; boundary="------------010405070100060106030201"
X-Gm-Message-State: ALoCoQm+RZUmjv352Y5oj0rpWSLX2/haYaiK2C2iEfg46pG7DWKfguzw9Pefghl5l3vt/iLlfi4g
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
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 22:05:49 -0000

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 
> <mailto: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 <mailto:fineberg@vline.me>
>>>     To: rtcweb@ietf.org <mailto: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 <mailto:fineberg%20at%20vline.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
>>>     <mailto:internet-drafts%20at%20ietf.org>
>>>     To: 	Adam Fineberg<fineberg at vline.com>
>>>     <mailto:fineberg%20at%20vline.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 <mailto:rtcweb@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>> -- 
>>> Regards,
>>> Adam
>>

-- 
Regards,
Adam