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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/payload






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]