Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Oct 2013 13:28:58 +0200

Version -10 is now submitted.

After discussing for a while internally what the default value should 
be, we reached the opposite conclusion of our first one: It is easier to 
accomodate future change if we make these parameters mandatory.

So -10 has them as mandatory. Please review and comment if the language 
is adequate!

              Harald

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Oct 2013 16:32:00 -0600

How do I signal that the max frame size I can receive is 640 x 480. 

My preference as the answer to this question is to say that for VP8 (not other codecs) you need to support  a=imageattr 

On Aug 14, 2013, at 6:28 AM, Harald Alvestrand <[email-masked]> wrote:

> On 07/19/2013 10:17 PM, Cullen Jennings wrote:
>> These can't be optional otherwise a device that is hardware limited can't know that the other side will use them. Thus there is no way to build solutions that interoperate by design instead of luck.
> 
> 
> A device that has announced a=imageattr:97 recv [x:640,y:480] and a=framerate:60 has stated that max-fr is >= 60 and that max-fs is >=  1200.
> 
> These parameters were added because people on this list asked for them.
> So far, I do not think they have been added to any existing implementation, and we don't seem to be seeing many interoperability problems because of that.
> 
> I don't think this is because of "luck". I think it's because these are not the constraints that are the most constraining in most practical situations - other constraints make sure we never reach the limits that might have been encoded using max-fr and max-fs.
> 
> 
>>  
>> 
>> On Jul 17, 2013, at 7:06 AM, Harald Alvestrand <[email-masked]> wrote:
>> 
>>> On 07/10/2013 10:28 PM, Stephan Wenger wrote:
>>>> Hi,
>>>> I read through the diff file.  The main change seems to be to reduce the
>>>> PartitionID field by one bit, which is now reserved.  This is fine.
>>>> While reading through the diff file (without checking against the main
>>>> text--too lazy or too busy, take your choice :-), I noticed that max_fr
>>>> and max_fs are optional, and could not see a default being defined.
>>> The theory is that there would be external constraints (such as an application-wide configuration, or an out-of-SDP signalling mechanism) that gave the constraints in question.
>>> 
>>> Quote from 6.2.2:
>>> 
>>>  In many practical applications, the max frame size and
>>>  max frame rate are known from other information; if they are not
>>>  constrained by other means, the max-fs and max-fr parameters MUST be
>>>  used to establish these limits.
>>> 
>>> We did not see a compelling reason to make non-compliant the present applications that do not use these parameters.
>>> 
>>> 
>>> 
>>>>  Is
>>>> this prudent?  How does a decoding system decide whether it is able to
>>>> decode a stream without any indication of the complexity of the stream?
>>>> Start decoding and reject once the header tells you that this stream is
>>>> beyond your capacity?
>>>> Stephan
>>>> 
>>>> On 7.10.2013 08:50 , "[email-masked]" <[email-masked]>
>>>> wrote:
>>>> 
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> This draft is a work item of the Audio/Video Transport Payloads Working
>>>>> Group of the IETF.
>>>>> 
>>>>> 	Title           : RTP Payload Format for VP8 Video
>>>>> 	Author(s)       : Patrik Westin
>>>>>                         Henrik F Lundin
>>>>>                         Michael Glover
>>>>>                         Justin Uberti
>>>>>                         Frank Galligan
>>>>> 	Filename        : draft-ietf-payload-vp8-09.txt
>>>>> 	Pages           : 30
>>>>> 	Date            : 2013-07-10
>>>>> 
>>>>> Abstract:
>>>>>  This memo describes an RTP payload format for the VP8 video codec.
>>>>>  The payload format has wide applicability, as it supports
>>>>>  applications from low bit-rate peer-to-peer usage, to high bit-rate
>>>>>  video conferences.
>>>>> 
>>>>> 
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8
>>>>> 
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09
>>>>> 
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-09
>>>>> 
>>>>> 
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>> 
>>>>> _______________________________________________
>>>>> payload mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>> _______________________________________________
>>>> payload mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/payload
>>> _______________________________________________
>>> payload mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 12 Oct 2013 08:14:54 +0200

> My preference as the answer to this question is to say that for VP8 (not other codecs) you need to support  a=imageattr 

My preference is not to do this, and leave it as is.

We suggested a solution based on an optional imageattr at first (-08
timeframe), but the comments by Stefan Wenger and Tim Terriberry led us
to propose this solution instead - the comments we received were of type
"either this solution or that solution", never "both solutions".

The codec parameters are intended to guard against streams of too high
complexity, because too complex streams might overload the decoder.

We have not seen any indication up to now that there exist devices for
which decoding 640x480@30 is reasonable, but decoding 480x640@30 is not.

There are many reasons to negotiate picture sizes, and the imageattr
mechanism is available for doing so. But once max-fs is present and
mandatory, I think it's not reasonable to require more mandatory
parameters in order to avoid codec overruns.

Can you live with the current version?

          Harald

-- 
Surveillance is pervasive. Go Dark.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 22 Oct 2013 07:32:38 -0400

> My preference is not to do this, and leave it as is.

But leaving it as is does not work and it's causing interoperability problems in the real world. 

> which decoding 640x480@30 is reasonable, but decoding 480x640@30 is not.

I have. 

And lets dig into that a bit deeper - you claim your hardware implementation is freely available. Show me how in the google hardware implementation you manage the allocation of the images buffers needed in a way where there are no limits on the aspect ratio. I'm very serious here, google keeps saying that the hardware implementation is available. Show it to me, or at least this part of it. 

> parameters in order to avoid codec overruns.

I'm not arguing agains max-fs, I'm saying it is not enough. 

> Can you live with the current version?

no - it won't work in environments where we need to be able to control transcoding to existing codecs.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Oct 2013 13:43:56 +0200

> But leaving it as is does not work and it's causing interoperability problems in the real world.

Where?

> And lets dig into that a bit deeper - you claim your hardware implementation is freely available. Show me how in the google hardware implementation you manage the allocation of the images buffers n…

Cullen, you know that Cisco refused to sign the agreement that Google 
required in order to get to see the hardware implementation. This 
hardware design is made available free of charge, not without conditions.

> no - it won't work in environments where we need to be able to control transcoding to existing codecs.

This is a new requirement (transcoding to existing codecs).

I would like the chairs to state an opinion on whether that's a 
reasonable requirement.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 22 Oct 2013 12:49:06 +0000

I am guessing below by transcoding you mean changing the resolution not necessarily the codec itself. Is that so?

> On Oct 22, 2013, at 2:44 PM, "Harald Alvestrand" <[email-masked]> wrote:
> 
> Cullen, you know that Cisco refused to sign the agreement that Google required in order to get to see the hardware implementation. This hardware design is made available free of charge, not without conditions.
> 
>> 
>> 
> I would like the chairs to state an opinion on whether that's a reasonable requirement.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Oct 2013 14:53:33 +0200

> I am guessing below by transcoding you mean changing the resolution not necessarily the codec itself. Is that so?

I read it  as transcoding to H.264 (or other codecs).

If it is a requirement that one always be able to limit the VP8 sender's
stream to conform to any restriction that can be expressed in H.264
terms, I think that's a new requirement (and an onerous one).

If the transcoder's willing to use cropping or rescaling to achieve the
transcode, I don't think there will be an issue.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 22 Oct 2013 12:29:47 -0600

> I would like the chairs to state an opinion on whether that's a reasonable requirement.

So let me get this right, google is blocking adding the imageattr because they don't want it to be possible to make a system with an RTP transcoder from H.264 to VP8. This just gets better and better

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Oct 2013 21:36:45 +0200

> So let me get this right, google is blocking adding the imageattr because they don't want it to be possible to make a system with an RTP transcoder from H.264 to VP8. This just gets better and bett…
That's an interesting interpretation!

Cullen, I think we need to chat about this directly.