Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Silvia Pfeiffer <[e-mail]>]

I quite liked them. Gave me a feeling for how much you object. I
thought it would have been good for everyone to do it this way
actually. It would be easier to summarize in the end, too. But alas,
that boat has sailed. :-)
Silvia.

On Tue, Dec 17, 2013 at 8:20 AM, Steve McFarlin <[e-mail]> 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.
>
> 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
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>