Subject: Re: [video-codec] Charter issues from BoF - optimized for the internet

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 18 Jan 2013 06:36:18 -0800

>>> 2. Be clear about "optimized for the internet"
 >>
 >> This was left somewhat vague because we're still getting feedback on
 >> precisely what "the internet" (i.e., the IETF) thinks is important,
 >> but there are certainly a number of specific examples of ways we
 >> could improve on existing codecs:
 >>
 >> 1) Fast/flexible congestion control (e.g., resolution changes without
 >> keyframes, etc.)
 >
 > I don't think we need resolution changes without keyframes if that
 > costs in overall average bandwidth - I think we need smooth
 > transition of nitrates over a 2 order of magnitude range.

I don't understand why you think it would... this could be as simple as 
resampling the reference frames on a resolution change, which has no 
bandwidth impact if the resolution doesn't change (i.e., assuming a 
non-stupid encoder it should be strictly superior to not doing that). 
The whole point of this, however, is to _allow_ smooth transitions in 
bitrates over 2 orders of magnitude without sending image quality off a 
cliff as your bits per pixel drops below the point the codec was 
designed to operate at.

 >> 2) Simplify the interaction of packet loss recovery with reference
 >> frame re-ordering (should we even use such re-ordering... if we
 >> don't, the interaction is _very_ simple).
 >
 >> 3) "Fast channel switching", i.e., the ability to join broadcast
 >> streams without waiting for a keyframe.
 >
 > I may not understand with 2 and 3 but these seem to be better phrased
 > in the what we will do

Happy to discuss this on the call, but people don't seem to understand 
the "designed for the internet" language even if there's lots of 
examples of decisions that this objective influenced (see Opus), so I 
hoped that putting examples right next to it would help clarify what we 
mean.

 >> 4) Support for screen captures (remote services, desktop sharing,
 >> etc.), which may require special coding tools, non-subsampled chroma
 >> (a feature notably lacking from VP8), etc.
 >
 > I'm in favor of a codec for displaying desktop screen captures or
 > slides but I think that is a pretty different set of requirements

To get the best possible codec, sure... but I think we can do something 
substantially better than normal transform codecs with the addition of a 
few simple tools.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Jan 2013 06:43:19 -0800

On Fri, Jan 18, 2013 at 6:36 AM, Timothy B. Terriberry <[email-masked]>wrote:

> non-stupid encoder it should be strictly superior to not doing that). The
> whole point of this, however, is to _allow_ smooth transitions in bitrates
> over 2 orders of magnitude without sending image quality off a cliff as
> your bits per pixel drops below the point the codec was designed to operate
> at.
>

As a non-video expert, what if we just wrote "_allow_ smooth transitions in
bitrates over 2 orders of magnitude"?

-Ekr

> Happy to discuss this on the call, but people don't seem to understand the
> "designed for the internet" language even if there's lots of examples of
> decisions that this objective influenced (see Opus), so I hoped that
> putting examples right next to it would help clarify what we mean.
>
> ______________________________**_________________
> video-codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/video-codec<https://www.ietf.org/mailman/listinfo/video-codec>
>