Subject: Re: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for VP8 Video) to Proposed Standard

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Jul 2013 00:12:12 +0000

Resent on different list …

I would like to raise an issue interoperability with this payload specification that we are currently having with WebRTC implementations. In WebRTC, and many other places, you want SDP to be able to control the resolution of the image (or at least the outer limits of the resolution). Yes, I realize there are applications where you know the resolution vis a some out of band mechanisms but O/A SDP is not one of the where this is guaranteed. We do need to specify how this works for use with O/A SDP. 

Some implementations think that if you want the resolution to by 720 lines by 1280, you control the resolution of codec with a SDP line something like 

 m=video 62537 RTP/SAVPF 96   
 a=rtpmap:96 VP8/90000
 a=ssrc:5 imageattr:* [1280, 720]

Some other implementers think you control the resolution using RFC 6236 with something like 

  m=video 62537 RTP/SAVPF 96 
  a=rtpmap:96 VP8/90000
  a=imageattr:96 [x=1280,y=720]

There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using 

  m=video 62537 RTP/SAVPF 96 
  a=rtpmap:96 VP8/90000
  a=fmtp:96 max-fr=30;max-fs=3600

What resolution do you think "max-fs=3600" is? I have no idea. It is not possible to implement so it is not surprising no one is doing  it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr. 

I raised this in the WG and the WG came to consensus that current draft is fine. So I actually believe that current draft does represent IETF consensus and that I was merely in the rough on that consensus. I had decided to just ignore it in LC because I was under the impressing that all the implementations would just ignore the RFC and do "a=imageattr:96 [x=1280,y=720]". However, when it came to my attention that many were doing  "a=imageattr:96 [x=1280,y=720]" but some where doing the non interoperable "a=ssrc:5 imageattr:* [1280, 720]", I decided that this problem actually needed to be fixed. 

I think this draft is broken and will create interoperability problems for years to come. I encourage the IESG to fix it. I don't care how it is resolved, I care that there is a way to for O/A to sort out the resolution and since the approach used be SDP to do this is codec specific, it needs to be in this draft. 

Cullen

On Jun 4, 2013, at 3:25 PM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from the Audio/Video Transport Payloads
> WG (payload) to consider the following document:
> - 'RTP Payload Format for VP8 Video'
>  <draft-ietf-payload-vp8-08.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-06-18. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> 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 file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>   http://datatracker.ietf.org/ipr/1622/
> 
> 
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 24 Jul 2013 03:57:30 -0700

> What resolution do you think "max-fs=3600" is? I have no idea. It is not possible to implement so it is not surprising no one is doing  it. However, this draft-ietf-payload-vp8 draft says the resol…

I can't speak for other implementations, but here at Mozilla, our 
interpretation of RFC 6236 was that the values specified in imageattr 
can be completely ignored by either side, if they so choose. That leaves 
max-fs and max-fr as the only mechanism to indicate a resource 
constraint that cannot be ignored, and we plan to use it as such.

See <https://bugzilla.mozilla.org/show_bug.cgi?id=881935> for details.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 28 Jul 2013 08:43:35 +0000

So do you expect your implementations on devices with hardware acceleration to have any limits on resolution of images they can decode?  I can't imagine how I could implement the frame buffers in VP8 in VLSI without having an upper limit on both the width and height of the image. How do you deal with that?

I don't know if you ever got the Google VHDL code for VP8 but I have never got it so I don't know what it does but if you do, that would be great. 

On Jul 24, 2013, at 12:57 PM, Timothy B. Terriberry <[email-masked]> wrote:

> I can't speak for other implementations, but here at Mozilla, our interpretation of RFC 6236 was that the values specified in imageattr can be completely ignored by either side, if they so choose. That leaves max-fs and max-fr as the only mechanism to indicate a resource constraint that cannot be ignored, and we plan to use it as such.
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 30 Jul 2013 20:42:59 -0700

Cullen Jennings (fluffy) wrote:
> I can't imagine how I could implement the frame buffers in VP8 in VLSI without having an upper limit on both the width and height of the image. How do you deal with that?

The one hardware VP8 decoder I have any experience with so far is mostly 
throughput-limited, not resolution limited (nor even limited by the 
number of streams... I was surprised to find this out, too). There are 
width/height limits, I'm sure, just because the size of the addresses 
must be finite, but they're not the bottleneck on any video you'd 
actually want to send. I could easily see how that might not be true on 
all (or even most) hardware implementations, however.

> I don't know if you ever got the Google VHDL code for VP8 but I have never got it so I don't know what it does but if you do, that would be great.

No, I dropped the ball here, so I don't know what it does either.