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

From: [email-masked]
Date: Wed, 10 Jul 2013 08:50:18 -0700

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/

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 10 Jul 2013 20:28:02 +0000

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

>_______________________________________________
>payload mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/payload

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Jul 2013 16:06:17 +0200

On 07/10/2013 10:28 PM, Stephan Wenger wrote:
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 13:17:49 -0700

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. 

On Jul 17, 2013, at 7:06 AM, Harald Alvestrand <[email-masked]> wrote:

> 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:
> 
> We did not see a compelling reason to make non-compliant the present applications that do not use these parameters.
> 
> 
> 
>>  Is