Re: Recap from WebRTC World

On 24/07/2013 12:55 AM, Cullen Jennings (fluffy) wrote:
> On Jun 27, 2013, at 8:19 AM, Gili <cowwoc@bbs.darktech.org> wrote:
>
>> Hi,
>>      (If you'd like to respond to individual points, please start a separate topic)
>>      I'd like to start a discussion of issues that came up during the WebRTC World conference (in sessions and while speaking with Dan Burnett and Cullen Jennings):
>> 	• Ending the VP8/H264 war: A proposal was made to mandate a patent-unencumbered codec (whose patents have expired or are not enforced) as mandatory and optionally upgrade to other codecs such as VP8 or H264 depending on peer capabilities and personal preferences. VP8 guys can use VP8. H264 guys can use H264. And if the two camps need to chat with each other they can fall back on H263. This gives you the flexibility of arbitrary codecs without the need to do transcoding.
>> 	• The WebRTC API needs to focus on normal web developers, not not telecom experts: The conversation on this mailing list is unduly skewed in favor of telecom experts which make up a tiny minority of WebRTC end-users. We need to find a way to collect feedback from the Javascript community at large in order to ensure that the API facilitates their use-cases. The proliferation of WebRTC SDKs for end-users (the conference was full of them) is a strong indication that there is a gap to be filled.
>> 	• Implementers vs End-users: The specification document has two target audiences, implementers and end-users. We need to provide implementers with a lot of low-level detail but make as little guarantees as possible to end-users to leave the door open to future change (without breaking backwards compatibility). We discussed explicitly marking-up sections of the specification "for implementers" or "for end-users" or separating the specification into separate documents. We need to make it clear, for example, that the specification does not make any guarantees regarding the contents of the SDP token. Implementers need a detailed breakdown in order to implement WebRTC 1.0 but end-users may not rely on these details because the token might not even be SDP in future versions.
>> 	• SDP: Users should interact with the Constraints API instead of SDP. It is true that there are some use-cases that are not yet covered by this API (forcing you to manipulate the SDP directly) but the plan is to address all these use-cases by 1.0 so users never have to interact with SDP directly. "If your use-case is not covered by the Constraints API, please tell us right away!"
>> 	• Offer/Accept: There are plans to enable peers to query each other's capabilities and change constraints (and as a result the offer/answer) in mid-call.
>> 	• Troubleshooting WebRTC: We need to do a better job diagnosing WebRTC problems. We need a user-friendly application (run by non-developers!) for quickly debugging network and microphone problems (Skype does this), and allow users to drill down into more detail if necessary. We also need programmatic access to this API so WebRTC applications can detect problems at runtime and decide (for example) to refund users who paid for a call that was subsequently aborted due to network problems.
>> 	• Use-cases, use-cases, use-cases: "Tell us what is wrong, not how to fix it". You are a lot more likely to get traction for your problems if you help us understand your use-cases then trying to argue for change for its own sake. On the flip side for specification editors, I encourage you to actively engage posters (ask for these use-cases) instead of ignoring discussion threads ;)
>>      I encourage other people who attended the conference to contribute their own discussion points.
>>      (If you'd like to respond to individual points, please start a separate topic)
>> Thank you,
>> Gili
> So I take it you expected some sort or response to this from me. I don't really know you wanted me to say. A bunch of this I agree with, the parts I don't are already well covered in previous discussions of the WG.

     I believe the following proposals were not addressed to date:

  * Mandating an unencumbered video codec as a baseline, and allowing
    arbitrary video codecs (H264, VP8, etc) to be negotiated as an
    upgrade path. To clarify, this proposal isn't meant to favor VP8 or
    H264. It is meant to eliminate the possibility of future IPR issues
    without while leaving the door open to better codecs depending the
    device capability at runtime (think hardware codecs, and codec
    licenses).
  * How do we address the fact that the WG does not represent web
    developers? (I believe we are in the middle of having this discussion)
  * Implementers vs End-Users: Shouldn't we have separate documents for
    the two target audiences?
  * Troubleshooting WebRTC: There is a gaping hope when it comes to
    user-facing diagnostic tools.

Thanks,
Gili