Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Steve McFarlin <[e-mail]>]

I am sorry. I was not sure if I should weight my Acceptable answers or not. Basically Yes = 1.0 and No = 0. Higher weight is 'better'. I should probably just have included my objections and not added any extra info as this seems to have added noise to the process. My apologies. Chairs please disregard my weights.

steve

On Dec 16, 2013, at 12:16 PM, cowwoc <[e-mail]> wrote:

> I know we're not supposed to reply directly to authors but I don't understand how to interpret Steve's answers...
> 
> Steve, can you please clarify what "Acceptable (X)" means? What is the significance of X? Is the higher the number, the better? Does it imply that one Acceptable answer is more acceptable than another?
> 
> Thanks,
> Gili
> 
> On 16/12/2013 3:10 PM, Steve McFarlin wrote:
>> Weighted opinions are purely mine, and not that of my employer. I am not taking Cisco's gift into consideration. While it is generous and useful for some, the license 'hack' forces the installation of the library on the end user machine/device. This is not feasible on some platforms. 
>>  
>>> 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:
>> 
>> Not all platforms expose access to a hardware or software encoder. If every feasible platform exposed H.264 API's then my reply would be "Acceptable 0.4". I also feel the IPR burden is too much on smaller players implementing MCU's.
>> 
>>> 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:
>> 
>> While I don't like putting my faith with other companies when it comes to IPR, I truly believe that Google will in good faith deal with any IPR issues that arise in the future. I think the gamble is an acceptable risk.
>> 
>>> All entities MUST support both H.264 and VP8
>>> Are you in favor of this option [Yes/No/Acceptable]:
>> 
>> Acceptable (0.3)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> While I still think the IPR on 264 is a burden, I think this is acceptable with respect to the browser space. My only concern is this option might just fragment/split the webrtc space with conforming and non conforming implementations. If selected I full expect FOSS implementations to be mostly VP8. With this said as long as the major players (browsers) implement both, then any custom non conforming RTC stack will still work in most cases.
>> 
>> There is still 264 IPR issues on conforming MCU's that do any coding tasks with the 264 data. There are also IPR issues related to broadcasting and the sale of H.264 content, but those are obviously outside the scope of this discussion.
>> 
>>> 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 (0.8)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> There is still 264 IPR issues on MCU's that do any coding tasks with the 264 data. There are also IPR issues related to broadcasting and the sale of H.264 content, but those are obviously outside the scope of this discussion.
>> 
>>> 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:
>> 
>> This only makes sense if we want to 'see who wins'. Given the division amongst many people I suspect we would see more 244 xor VP8 implementations then ones with both.
>> 
>>> 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:
>> 
>> While the video is usable, it just can't compete in the modern video communications space.
>> 
>>> There is no MTI video codec
>>> Are you in favor of this option [Yes/No/Acceptable]:
>> 
>> Acceptable (0.1)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> If no consensus is made on any other option then I see no other choice. This group needs to move forward at some point.
>> 
>>> 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]:
>> 
>> Acceptable (0.3)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> I really don't like the fallback to 261. It is just not a good codec.
>> 
>>> All entities MUST support Theora
>>> Are you in favor of this option [Yes/No/Acceptable]:
>> 
>> Acceptable (0.2)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> While better than 261, I feel having at least one modern codec as a MUST is better than this.
>> 
>>> All entities MUST implement at least two of {VP8, H.264, H.261}
>>> Are you in favor of this option [Yes/No/Acceptable]:
>> 
>> Acceptable (0.4)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> I really don't like 261. It is not a good codec for modern video communications.
>> 
>>> 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:
>> 
>> As far as I am aware 263 still has IPR issues. This just forces compliant stacks into a possible IPR violation issue.
>> 
>>> 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:
>> 
>> While I think the risk of an IPR suite for disturbing a H.264 decoder is small, I would not put it past some NPE popping up and forcing you to visit that lovely court in Texas. The visit alone would put any small player instantly out of business assuming they did not 'pay the fee'. This option in a IETF spec just makes it that much easier for a NPE or IPR holder to select targets.
>> 
>>> 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:
>> 
>> Possible IPR issues. Not a modern codec. (I understand VP8 and 264 are not modern codecs per say, but at least they are 'more' modern than 263).
>> 
>>> All entities MUST implement at least two of {VP8, H.264, Theora}
>>> Are you in favor of this option [Yes/No/Acceptable]:
>> 
>> Acceptable (0.6)
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> Theora is a better quality codec than 261, and does not have any possible IPR issues that 263 has. I am not sure of the IPR status of Theora, and I don't ever recall seeing someone sued for it. Then again maybe there has never been a big enough target for anyone who thinks they have IPR on Theora from coming forward. I would personally be willing to take a risk on the much more than 263 or distributing a 264 decoder.
>> 
>>> 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:
>> 
>> Maybe I have not had enough or had too much coffee today, but I don't see the logic in this option at the moment.
>> 
>>> All entities MUST support Motion JPEG
>>> Are you in favor of this option [Yes/No/Acceptable]:
>> 
>> No No No.
>> 
>>> 
>>> Do you have any objections to this option, if so please summarize them:
>> 
>> I understand the need to enumerate all options, but this just has so much FAIL attached to it. Do we really need interop with old Canon network cams (lol)? On the positive side I think Firefox still supports motion JEPG streaming as a relic from the Netscape implementation back in 96 (or earlier). Kidding aside, this will be way too bandwidth intensive to achieve good quality video.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb