Re: [video-codec] Strategy for an RF video codec

Cullen,

This is a really interesting idea.

Can you give me some sense of how you envisioned the negotiation happening?
Traditionally, IETF uses one of three types of negotiation:

- One side offers some list of non-categorized features and the other side
picks
a subset. ("extensions")
- We have a bunch of feature categories and one side offers a list of which
ones if supports in each category. The other side picks one from each column
("chinese menu}")
- We have a fixed number of feature combinations and one side offers
a list of the combinations it supports and the other side picks one
("suites")
- We have a list of features and one side lists the combinations it would
accept ("profiles" (?))

What did you have in mind here? I ask because it impacts the relationship
between the features and the required level of engineering
work.

-Ekr

On Mon, Jan 14, 2013 at 8:28 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> I'm going to assert that it will be much more difficult to get an state of
> the art RF video codec than to get an good RF audio codec. Some of the
> people working in the CODEC WG had strategies to increate the likely hood
> of an RF codec but the WG never had any strategies to achieve this. I think
> the video codec WG should have a strategy to optimize the odds of RF.
>
> Here's my proposal for a strategy and I think this, or whatever it is we
> decide is our strategy, should be in the charter:
>
> 1) every separable part of the codec becomes a separate feature and both
> sides negotiate the features they support. I'm imaging 100 or more features
> many of which depend on others or you can't use them. The minimal feature
> might just be uncompressed video. The odds of managing for all parts of an
> advanced video codec to be RF are low and this allows us to mitigate the
> risk by if some part if found to not be RF, deployments can disable that
> feature and the features that depend on them. This also makes for a much
> smother watt to incrementally advance the codec over time. Doing this means
> we are not doing a single codec but really a family of codecs .
>
> 2) every feature that goes into the codec is specified in a separate draft
> to get separate IRP claims
>
> 3) every feature includes information about why we think it is RF. This
> might be because it is an implementation of an old algorithm, it might be
> because the IPR has been granted RF, or it might be because we are so
> brilliant no one could have ever thought of this idea before.
>
>
> Cullen
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>