ietf
[Top] [All Lists]

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

2013-07-28 03:44:05

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 
<tterribe(_at_)xiph(_dot_)org> wrote:

Cullen Jennings (fluffy) wrote:
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 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.
_______________________________________________
payload mailing list
payload(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/payload