Subject: [rtcweb] An Observation of issues uncovered by the Straw Poll

From: John Leslie <[email-masked]>
Date: Mon, 13 Jan 2014 12:19:58 -0500

As I said before, I commend the chairs for running this straw poll.
I will trust the chairs to total and report the responses by question:
I make no attempt to count the responses raising the issues I mention.

- video quality:

   Quite a number of folks have based their rejection of particular
choices on their perception of video quality; but I do not believe it
worth our while to chase down "objective" measures of this. We have to
accept that _some_ folks will end up "in the rough" here.

- licensing:

   Many folks appear surprised that their views of licensing issues
aren't shared by the rest of us. I'm not surprised, myself. This, IMHO,
is "damage" to be routed around. Folks will, however, need to accept
that we won't reach a single understanding of the licensing issues.

   One particular issue is Nokia's "refuse-to-license" stand on VP8.
I remind folks that IETF takes no position on what a disclosure
_means_ -- and there's no possibility to change that here. Individual
companies make their own decisions on how to proceed; and it appears
at first blush there are enough willing to proceed despite Nokia
that VP8 will see significant deployment.

- legacy interoperation:

   I only recently came to understand how important it is for some of
us that legacy equipment may claim "WebRTC compatibility". We should,
IMHO, take this very seriously. We can, perhaps, find "fudge-factor"
room to allow this despite these not meeting a MTI requirement; but
it really would be cleaner if they met our "MTI" specification.

   H.264 has the largest count of hardware that only does H.264; but
there really is VP8-only deployment; so IMHO it's not unreasonable to
ask that both H.264-only and VP8-only equipment fit within our "MTI".

- future-proofing:

   This has seen alarmingly little consideration in the straw poll.
Perhaps this is inevitable in any straw poll... But it would be very
surprising if we never see H.265-only and VP9-only equipment deployed.
I suggest that both of these deserve some consideration as to how we
can allow these as "WebRTC compatible".

- what happens if both ends don't support the same codec?

   Regardless of what we spec as MTI, there will be attempts to
connect by devices which don't support our MTI codec(s). We can't
stop this. But we seem to have minuscule common ground on what this
"means". Many folks have assumed we'll just proceed with no video.
Others, including pretty much anyone who cares about hearing-impaired
folks, want _some_ video, no matter how imperfect.

   I suggest we take this second group more seriously. Implementations
can always decide the video offered is worse than nothing, and refuse
to display it; but hearing-impaired folks are often _very_ good at
using vision to supplement their hearing. (I suggest that even folks
who don't consider themselves hearing-impaired use such clues...)

   I have already started a thread about transcoding; and I'm happy
to have a transcoding discussion there.

   Some of us have seriously proposed H.261 as a way to deal with
failure to negotiate a common modern codec. IMHO, we've failed to
approach consensus there, and, for myself only, I'm ready to abandon
that effort.

- are we ready for the question?

   This is a stock question to move discussion along. I won't answer
it here; but I suggest there are signs we are not ready.

   The usual interpretation by those who hear the question is, "Are
you likely to change your mind if discussion continues?" But that
is not the correct interpretation in a consensus process.

   There are a significant number of responses indicating things
which could change how some of us look at this question (including
possible "standardization" of VP8, availability of packages to
extend the capabilities of browsers, etcetera).

   There is also a very real possibility that we're the wrong group
to be making the MTI decision. I don't see consensus there yet;
but I certainly wouldn't rule it out.

   Instead of continuing to beat our heads against this particular
wall, might we consider how to negotiate a connection in the absence
of a shared codec among those offered?

--
John Leslie <[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 13:07:51 -0500

Hi John,

On 13/01/2014 12:19 PM, John Leslie wrote:
> [snip]

I agree. We should post a "deprecation strategy" which would outline the 
process for removing MTI features in the future.

> "means". Many folks have assumed we'll just proceed with no video.

As far as I'm concerned, if the remote end does not follow the 
specification then behavior is undefined. In practice this means that I 
should be free to dump the non-compliant peers.

> who don't consider themselves hearing-impaired use such clues...)

Agreed.

> of a shared codec among those offered?

I believe the specification already does this. MTI is meant as a 
fallback, but nothing prevents implementations from negotiating to a 
higher-end codec.

Gili