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

["Cullen Jennings (fluffy)" <[e-mail]>]

On Jan 15, 2013, at 8:03 AM, Eric Rescorla <[e-mail]> wrote:

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

I had not really put too much thought into which style would work best but I was imaging "extensions" for interactive and "suites" for stored video. 

For interactive, the SDP would have the list of features supported by the receiver. The side encoding the video would look at that, and encode appropriately. The actual information of what the encoding was would be in the bitstream so any device could decode just from looking at the bitstream. 

For non interactive media - something more like vimeo, I would imagine that we would define a small number of suites defined in IETF specs and the video is encoded to one or more of the suites and the receiver either can deal with the suite or it can't. More or less how interactive video works today. It does allow new suites to be defined with existing features which would allow for fairly rapid roll out of new suites if a problem was found with existing suite set. 

> 
> -Ekr
> 
> 
> On Mon, Jan 14, 2013 at 8:28 PM, Cullen Jennings (fluffy) <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/video-codec
> 
> _______________________________________________
> video-codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/video-codec