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> <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
>
>