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

Justin Uberti <juberti@google.com> Fri, 19 July 2013 13:32 UTC

Return-Path: <juberti@google.com>
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 D106811E8120 for <rtcweb@ietfa.amsl.com>; 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.706
X-Spam-Level:
X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.271, 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 8OTJdTYlaP4g for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 06:32:44 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76D11E8117 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 06:32:44 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id k13so9533134iea.32 for <rtcweb@ietf.org>; 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=P54wb+nYz2Yf0wSe4Kh1DQ2BrEgl/j1og8VnONoL5vxp5186dWNgctpD3jyQSfsh1j elFKTCRfpp7pAsKNiLdop37/VpaezVn5EAqUvjIvShCdRBmL6hfjrFGAzevcRw4UBGiv 7mdIDygiKSkP4Kubxwhp/iV/kAM4w0sob8YnnIt8GnaaB2AFoRUEzL4cfpei6szU4bAO Ly32rj29VFE/rMyLUc3wQAt7hflXV2hCpnDg8DBnnd1zyi0x8bBnneijPMgZGTxRb4hJ 728k1Yc8bJVrjYBjI0n31RDYD0eBaLizQuzITDIQC8hTcovLZjwrrUEOR7Frja8rSg8K D1+w==
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: <BLU401-EAS75C2417EF2B049AF14CDF893630@phx.gbl>
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>
From: Justin Uberti <juberti@google.com>
Date: Fri, 19 Jul 2013 09:32:23 -0400
Message-ID: <CAOJ7v-0N+hRA6HP9ePS4bW8eV3cpF3JZdsstp2rv+es3JjPJtg@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary=20cf303bf8be90697404e1dd5c94
X-Gm-Message-State: ALoCoQl50Lk6KC46dU8jn5YTHuMF7GYp3K8DCXTp/bDZkuK4LUWQUPsnSnQfrP1MyvlFv1x2mw6YXJve3Z2YeyH6NgKnQiKyjOgfpiObbAWk6JMFAzhtRxhjoF/ZwYAvQ1lHS3HzNAMLPxCMxGmiuDXrWu+jNsfs6QLBIayNEj7l5GpMtdhYFTCCNyFJJC5erPQqFR6coCk/
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 13:32:46 -0000

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> <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 https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Regards,
> Adam
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>