Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Tim Panton <[e-mail]>]

My straw on the camel's back....

All entities MUST support H.264
Are you in favor of this option [Yes/No/Acceptable]: No
Do you have any objections to this option, if so please summarize them:
The license(s) of H.264 imposes too many unquantified financial/legal restrictions on its use to support 
the level and kinds of innovative use that webRTC may see if it is successful. As such it risks damaging 
innovative players and entrenching the world view of the existing players.
The cisco plugin marginally mitigates this, but does not address mobile apps,
or future business models that don't fit in the current license grant.

All entities MUST support VP8
Are you in favor of this option [Yes/No/Acceptable]: Yes
Do you have any objections to this option, if so please summarize them:

All entities MUST support both H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
Same objection as 1) - It exposes all webRTC use to the full range of legal risk for both 
codecs.

Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]: Acceptable
Do you have any objections to this option, if so please summarize them:
The existing webRTC browser makers already have VP8 and H264 solutions, 
other entities (door bells, baby monitors) can pick the codec their hardware/usecase best
supports, with the certainty that there will not be an interop failure with any webRTC browser.
This proposal does make the launch of a wholly new browser more difficult.

All entities MUST support at least one of H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]: Acceptable
Do you have any objections to this option, if so please summarize them:
In theory this risks a significant level of interop failure, but in practice it will probably
end up as a 'the market will decide' option, with the huge majority of users ending up 
using a single codec.

All entities MUST support H.261
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
The codec will be unacceptable for a large number of (mobile) use cases requiring dynamic bandwidth adjustment.

There is no MTI video codec
Are you in favor of this option [Yes/No/Acceptable]:Acceptable
Do you have any objections to this option, if so please summarize them:
In theory this risks a significant level of interop failure, but in practice it will probably
end up as a 'the market will decide' option, with the huge majority of users ending up 
using a single codec.

All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]: No
Do you have any objections to this option, if so please summarize them:
The H261 codec will be unacceptable for a large number of (mobile) use cases.
This option is worse than 5) since it reduces the pressure on the browser makers 
to avert interop failure.

All entities MUST support Theora
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:

All entities MUST implement at least two of {VP8, H.264, H.261}
Are you in favor of this option [Yes/No/Acceptable]:No 
Do you have any objections to this option, if so please summarize them:
Along with the objections to 5) and 6) This also brings added complexity in implementation,
api, user interface and signalling - for a minimal (or zero) benefit.

All entities MUST implement at least two of {VP8, H.264, H.263}
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
Along with the objections to 10) this adds a new unquantified legal risk over h263.

All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
SDP is really bad at specifying asymmetrical connections - with the current API's this would
ensure that _every_ javascript programer would need to become an SDP expert.

All entities MUST support H.263
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
H263 is unlikely to be acceptable for a large number of (mobile) use cases requiring dynamic bandwidth adjustment.

All entities MUST implement at least two of {VP8, H.264, Theora}
Are you in favor of this option [Yes/No/Acceptable]:No 
Do you have any objections to this option, if so please summarize them:
See 10)

All entities MUST support decoding using Theora.
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
unlikely to be acceptable for a large number of (mobile) use cases.

All entities MUST support Motion JPEG
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
unlikely to be acceptable for a large number of (mobile) use cases requiring dynamic bandwidth adjustment.