Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00

["Timothy B. Terriberry" <[e-mail]>]

John Koleszar wrote:
> can pipeline the encode with the camera. Even if you only get a whole
> frame at the encoder, it could be valuable to be able to ship the data
> as soon as you can fill an RTP packet, rather than waiting until the
> whole frame is encoded. There are also pipelining considerations where

Also a format capable of subframe latency encoding generally has good 
cache coherency. I'm not sure how much software engineering effort I 
would want to expend into proving this out, though, as long as we ensure 
the format doesn't compromise this unnecessarily.

>> Section 4, fifth paragraph, bullet 2:
>>
>> This is great for storage but, I'm not convinced this is helpful for
>> networks. For network operations, lower average bitrates with higher
>> unpredictability may be worse than higher average bitrates with greater
>> predictability.
>
> This is more of an issue for VOD applications rather than
> teleconferencing. The rate variance you can accept is governed by how
> much you can prebuffer. Taking advantage of this where possible can
> get you substantial quality gains vs constant bitrate, for the same
> average bitrate.

An important point about quality: people will often judge quality of a 
segment by that of the _worst_ frame. So, while I understand that 
keeping a consistent flow bandwidth helps when competing in a link 
bottleneck somewhere, the value of the extra bits (the ones used to 
boost the quality of the other frames above that of the worst one) is 
actually fairly low, in terms of its effect on perception.

This is something I hope rmcat will explore in more detail, though I 
recognize it's hard to evaluate. One idea that occurs to me is actually 
using VBR video and padding it with FEC data to get something closer to 
CBR. That might actually be a better use of the bits.