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

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