[rtcweb] Steve's choices (Re: Straw Poll on Video Codec Alternatives)

[Harald Alvestrand <[e-mail]>]

On 12/16/2013 10:20 PM, Steve McFarlin wrote:
> 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.

I actually liked the weights. They give ranking information, which is 
important. I think I'll add some to my reply to the poll (in preparation).

What I don't like is having followups to poll answers without changing 
the subject - this makes the actual poll answers harder to find.

Sorry to be a PITA about this.

>
> steve
>
> On Dec 16, 2013, at 12:16 PM, cowwoc <[e-mail] 
> <mailto:[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.
>>>
>>>> 1.
>>>>     All entities MUST support H.264
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No.
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 2.
>>>>     All entities MUST support VP8
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Yes.
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 3.
>>>>     All entities MUST support both H.264 and VP8
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.3)
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 4.
>>>>     Browsers MUST support both H.264 and VP8, other entities MUST
>>>>     support at least one of H.264 and VP8
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.8)
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 5.
>>>>     All entities MUST support at least one of H.264 and VP8
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 6.
>>>>     All entities MUST support H.261
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 7.
>>>>     There is no MTI video codec
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.1)
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 8.
>>>>     All entities MUST support H.261 and all entities MUST support
>>>>     at least one of H.264 and VP8
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.3)
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>> 9.
>>>>     All entities MUST support Theora
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.2)
>>>
>>>>     1.
>>>>
>>>>
>>>>     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.
>>>
>>>>10.
>>>>     All entities MUST implement at least two of {VP8, H.264, H.261}
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.4)
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>>11.
>>>>     All entities MUST implement at least two of {VP8, H.264, H.263}
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No.
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>>12.
>>>>     All entities MUST support decoding using both H.264 and VP8,
>>>>     and MUST support encoding using at least one of H.264 or VP8
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No.
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>>13.
>>>>     All entities MUST support H.263
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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).
>>>
>>>>14.
>>>>     All entities MUST implement at least two of {VP8, H.264, Theora}
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> Acceptable (0.6)
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>>15.
>>>>     All entities MUST support decoding using Theora.
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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.
>>>
>>>>16.
>>>>     All entities MUST support Motion JPEG
>>>>     1.
>>>>         Are you in favor of this option [Yes/No/Acceptable]:
>>>>
>>>
>>> No No No.
>>>
>>>>     1.
>>>>
>>>>
>>>>     2.
>>>>         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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb