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

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