Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Silvia Pfeiffer <[e-mail]>]

Percentage of agreement is what is call it. Higher is better.
Silvia.
 On 17 Dec 2013 07:17, "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.
>
>
>
>    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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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).
>
>
>    1. 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.
>
>
>    1. 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.
>
>
>    1. 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 [e-mail]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>