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

[Eric Rescorla <[e-mail]>]

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

> >>> 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.
>

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

-Ekr

>> 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.
> ______________________________**_________________
> video-codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/video-codec<https://www.ietf.org/mailman/listinfo/video-codec>
>