(Auto)update libjingle 72847605-> 72850595
Modify | /trunk/talk/app/webrtc/mediaconstraintsinterface.cc | diff | ||||||||||||||||||||||||||||||||||||||
|
Was there a public discussion to follow along on? Or is this now it?
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Was there a public discussion to follow along on?
Or is this now it?
Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.
On Aug 8, 2014 9:27 AM, "Adam Barth" <aba...@chromium.org> wrote:
>
> On Fri Aug 08 2014 at 9:18:16 AM Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>> Was there a public discussion to follow along on?
>
> We discussed the issue in a VC. There have been various email threads on various lists, but none of them converged on a workable solution.
>>
>> Or is this now it?
>
> I'm happy to re-open this topic if you'd like to discuss it further.
>
> Adam
After I sent this, I was afraid that last sentence would be seen as more combative than desired.
No, I merely was hoping to follow the decision making a bit more than your summary, to understand the process, as well as understand the impact (however small) to the Blink process.
On Friday, August 8, 2014 12:14:15 PM UTC-4, Adam Barth wrote:Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.Does this mean we believe that running behind a flag will not gather enough data?
What about shipping only to dev/canary channels?
Mainly, I am curious why this feature is special compared to other experimental features on the web platform.
Or, will we be using the 50%-prefixed technique for other nonstandard features as well?
> I think it's an appropriate technique to use in the context of an experiment that aims to gather data from a large population of users. For most features, using a runtime flag is likely a better approach because they can be evaluated individually by developer
Thanks Adam; this makes sense. It might be helpful to update the documentation at http://www.chromium.org/blink/developer-faq#TOC-Will-we-see-a--chrome--vendor-prefix-now- and thereabouts to reflect this update to our thinking and capture the subtleties you've explained in this thread.
Note that webrtc shipped prefixed features before, and we were looking for a way to avoid having websites rely on them after they already shipped.
Yes, in this case, a new property was added, but mainly for consistency reasons.
I think using a random trial is a suitable tool for trying out not yet standardized features, but it doesn't fundamentally change our stance on prefixed features.
Best
Jochen
As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.
As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.A better example is screen sharing. Screen sharing is a 'plugin free' Hangouts feature that uses the "chromeMediaSource": "screen" constraint in webkitGetUserMedia.Other websites cannot use this (chrome prefixed, oh...) constraint, not even in HTTPS. Only Hangouts can.I do not recall more examples at the moment, but I think there were more, even for short periods of time.
If Google wants to experiment with stuff, you can limit the constraints (or any other feature) to Google properties. While I am not in favor of this kind of favoritism, I prefer it over this - prefixed properties are harmful to the web as a whole, while favoritism is simply 'cheating'.
By the way, 50% is a pretty high percentage. WebGL used to be available to less than 50% of the users for a long time (not due to experiments), due to driver issues, or insufficient implementations on certain operating systems, but websites still experimented with WebGL and used WebGL, even if not all of the users could experience them.
At least it was know. But this can be even worse - a developer uses the prefixed constraint because it works for them and for some of their users that tested their website (luck, I guess) and have no idea the feature is not available for all (no one publicized this decision until now). It is true that these constraints were never publicized as well, but as you know - if something exists in a browser, there will be developers that use it.
Oh, then I misremembered - sorry!What about QUIC, though? Is it currently limited to Google properties?
When was this up-to-50% policy applied?
Or will it be applied going forward?
And for what features - all of the goog prefixed ones (constraints and statistics)?
Your past experience with Google websites makes me sad. :(
What about an up-to-50%-for-Google-properties policy? Looks like the best of both of the worlds.
On Fri Aug 08 2014 at 1:58:19 PM PhistucK <phis...@gmail.com> wrote:As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.A better example is screen sharing. Screen sharing is a 'plugin free' Hangouts feature that uses the "chromeMediaSource": "screen" constraint in webkitGetUserMedia.Other websites cannot use this (chrome prefixed, oh...) constraint, not even in HTTPS. Only Hangouts can.I do not recall more examples at the moment, but I think there were more, even for short periods of time.
If Google wants to experiment with stuff, you can limit the constraints (or any other feature) to Google properties. While I am not in favor of this kind of favoritism, I prefer it over this - prefixed properties are harmful to the web as a whole, while favoritism is simply 'cheating'.
We discussed that as a possibility, but in the past we've had difficulty removing features that are exposed only to Google web sites for much the same reason that we have difficulty removing vendor-prefixed features more generally in the web.
The idea behind exposing these non-standard features less than 50% of the time is that it lets retain the option of removing the feature entirely, even if the web site that uses the feature is uncooperative.
Another way we could mitigate that risk is to log a message to the developer console whenever you use one of these experimental APIs.
Maybe instead of activating the feature on a percentage of users or activating it only for Google properties (which doesn't feel right), we could declare a time-limited experimentation with non-standard features for data gathering purposes?For example, such features would be turned on by default in a certain Chromium milestone version, but turned off immediately after that?That way, I doubt we'd see significant adoption of these experimental features by authors, since it won't be worth the trouble for just 6 weeks.
Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.
It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)
Maybe instead of activating the feature on a percentage of users or activating it only for Google properties (which doesn't feel right), we could declare a time-limited experimentation with non-standard features for data gathering purposes?For example, such features would be turned on by default in a certain Chromium milestone version, but turned off immediately after that?
That way, I doubt we'd see significant adoption of these experimental features by authors, since it won't be worth the trouble for just 6 weeks.
If we're expecting to see more features of that nature, maybe they can be announced using "Intent to Experiment" threads here on blink-dev?
Le vendredi 8 août 2014 18:14:15 UTC+2, Adam Barth a écrit :Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.
It was exactly the same thinking for when one browser had an experimental feature and the other didn't "People won't write non-standard code since it's not interoperable. We'll be able to remove the feature later". What happened is that the websites were encouraging users to download a different browsers (not pointing fingers, it happened with pretty much all combinaisons of source and target browsers).
This time, the website just has to display a message like "your version of Chrome has a bug preventing it from running this awesome demo. Please re-install Chrome."
And "my friend can run the demo while I cannot and we're both on Chrome, that should work the same, right?" would be a powerful motivator for people to re-install Chrome.
Exposing something experimental on the web is playing with fire.
I'm sympathetic with the intention of real-world testing on a large population, that's why I'm fine with exposing the experimental things on Google properties. It's a noble goal to want other web devs to test out the feature, however, as soon as you release something on the web, you cannot control what will happen.
One possible middle-ground between "google only properties" and "the entire web" would be to have web devs declare interest and the Chrome team to whitelist their domains (akin to what happens with the HSTS prelaod list [1][2]). Among other things, that would "guarantee" that the Chrome team has a point of contact with the websites running experiments, which would give you a clear way to inform people that an experimentation is coming to an end (which you don't have if you ship something on the web).
Other middlegrounds are possible. I would love to see them explored.
On Sat Aug 09 2014 at 2:34:27 AM <brua...@gmail.com> wrote:It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)Personally, I find it frustrating to develop for a platform that grants special privileges to some developers. For example, Chrome on Windows originally used WinInet as its network stack, but we couldn't implement HTTPS certificate handling properly because Internet Explorer used a private API to WinInet in order to implement its HTTPS certificate handling.I don't think the web platform should grant special privileges to some developers. As I've written earlier in this thread, that's a matter of opinion and not everyone agrees with me. It sounds like you're in the camp of folks who disagree.
On Sat Aug 09 2014 at 7:59:43 AM <brua...@gmail.com> wrote:
Le vendredi 8 août 2014 18:14:15 UTC+2, Adam Barth a écrit :Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.It was exactly the same thinking for when one browser had an experimental feature and the other didn't "People won't write non-standard code since it's not interoperable. We'll be able to remove the feature later". What happened is that the websites were encouraging users to download a different browsers (not pointing fingers, it happened with pretty much all combinaisons of source and target browsers).
This time, the website just has to display a message like "your version of Chrome has a bug preventing it from running this awesome demo. Please re-install Chrome."To be clear, the dice get re-rolled whenever you launch Chrome.
And "my friend can run the demo while I cannot and we're both on Chrome, that should work the same, right?" would be a powerful motivator for people to re-install Chrome.
You can re-launch Chrome to get a new roll of the dice. That seems like a numerical problem. Perhaps 1% would be a better size? Then a user would have to re-launch Chrome a hundred times to game the system.
Exposing something experimental on the web is playing with fire.
Definitely. That's why I take this topic seriously and why we're trying a few different approaches to see what works in practice. The alternative is to try to design network protocols without real-world data, which will result in protocols that don't work in the real world.
One possible middle-ground between "google only properties" and "the entire web" would be to have web devs declare interest and the Chrome team to whitelist their domains (akin to what happens with the HSTS prelaod list [1][2]). Among other things, that would "guarantee" that the Chrome team has a point of contact with the websites running experiments, which would give you a clear way to inform people that an experimentation is coming to an end (which you don't have if you ship something on the web).
Other middlegrounds are possible. I would love to see them explored.A similar idea that we've talked about is having API keys for experimental features. For example, if you wanted to use the experimental parts of the web animation API, you could somehow get an API key that would be scoped to a particular set of URLs and a particular time period.That idea is probably worth trying, but my concern is the same as with the other time-limited approaches. When it comes time to expire the API key for a popular web site, we're back to the same game of chicken.
Le samedi 9 août 2014 17:11:46 UTC+2, Adam Barth a écrit :On Sat Aug 09 2014 at 2:34:27 AM <brua...@gmail.com> wrote:It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)Personally, I find it frustrating to develop for a platform that grants special privileges to some developers. For example, Chrome on Windows originally used WinInet as its network stack, but we couldn't implement HTTPS certificate handling properly because Internet Explorer used a private API to WinInet in order to implement its HTTPS certificate handling.I don't think the web platform should grant special privileges to some developers. As I've written earlier in this thread, that's a matter of opinion and not everyone agrees with me. It sounds like you're in the camp of folks who disagree.I don't want the web platform to grant special privileges to some developers, but for an experimental feature that is meant to be removed eventually, it seems like a reasonable trade-off.
What is the harm if you're sure you'll remove it eventually? I'd obviously be outraged if you any browser was considering adding a permanent feature only to some developers.
I imagine the feature will be unconditionally available in Canary builds, so the reason you want to expose the feature to the web is to gather real-world data on websites with lots of users who will use the feature (not just devs who want to play around with the feature, because they'd just use Canary).
In the end, that's a very small population you're targetting, it feels inadequate to expose the feature to a wide audience when you know the intended audience is very small (and when you know there is potential harm).
Just to throw my two cents in, it seems like fundamentally, what we're trying to achieve is a whitelist for Google properties. While I'm not really in favor of doing this, if we are going to, it seems more honest with ourselves and everyone if we use a whitelist in Chrome that define what origins can use the special implementation/features that define what sites can use the unprefixed version of the feature.
In any case, if we do go ahead with prefixes in cases like this, we ought to have a chromium.org doc to clearly define the conditions under which we allow them so they don't bleed into other use cases.
--JoelJuberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.
Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.
Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.
AdamOn Fri Aug 08 2014 at 3:50:42 AM PhistucK <phis...@gmail.com> wrote:A recent commit (August 7th, 2014) in WebRTC added a goog prefixed constraint to webkitGetUserMedia -Log message
(Auto)update libjingle 72847605-> 72850595
Modify /trunk/talk/app/webrtc/mediaconstraintsinterface.cc diff
... 95 95 "googSuspendBelowMinBitrate"; 96 96 const char MediaConstraintsInterface::kImprovedWifiBwe[] = 97 97 "googImprovedWifiBwe"; 98 + const char MediaConstraintsInterface::kNumUnsignalledRecvStreams[] = 99 + "googNumUnsignalledRecvStreams"; 98 100 const char MediaConstraintsInterface::kScreencastMinBitrate[] = 99 101 "googScreencastMinBitrate"; 100 102 // TODO(ronghuawu): Remove once cpu overuse detection is stable. ... Prefixing features is harmful to the web platform, making websites incompatible with other browsers, breaking assumptions, causing monopolization and hurting competition. People rely on prefixed features instead of treating them as non production, experimental features that (not only could) will change, break and disappear soon. I listed some details in the last section of this post.
Blink (of Chrome) and Gecko (of Firefox) have announced long ago they will not be adding prefixed features anymore.Instead, experimental features are disabled by default and can usually be turned on by using a command line flag (about:flags in Chrome) or by setting a certain preference (about:config in Firefox).In this example, you can use the Experimental Web Platform Features flag in Chrome in order to expose any experimental functionality (a prefix is not needed then, because it is meaningless if it is not exposed to the web by default anyway).This lets any Chrome user that is looking to experiment with the functionality that you want to introduce, experiment with it by simply flipping a flag, which is really not a big deal.If you need help with plumbing the flag into WebRTC, I can try diving into the code and come up with a clean way of exposing such concepts ("kEnableExperimentations" or so).I (and the entire web) would appreciate it, if you could move all of the prefixed features and constraints in WebRTC (meaning, prefixed getStats statistics and prefixed media and peer connection constraints, or any other prefixed feature that is currently exposed by default to the web) behind the Experimental Web Platform Features flag, that can be easily turned on from about:flags.Note - I am mostly referring to goog prefixed features here. Unless I am mistaken, webkit prefixed WebRTC features (like webkitGetUserMedia, webkitRTCPeerConnection and webkitMediaStream and others with which I might not be familiar) are features that should be deprecated and unprefixed, as soon as possible, rather than be moved behind a flag.Here are a few reasons, explanations and arguments, some of them are recent and some are not -- http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/ (I am not sure Firefox actually implemented -webkit- prefixed feature eventually, though).- Microsoft just recently announced that Internet Explorer 11 on Window Phone 8.1 Update 1 added support for -webkit- prefixed CSS because websites were incompatible with Internet Explorer, because they only relied on vendor prefixes, because they simply worked with the default browsers.- Opera did the same with Presto (their rendering engine, prior to switching to WebKit and then Blink), in order to be compatible with the vendor prefix encumbered web.Thank you very much (everyone here) for all of your work. You are doing amazing things to the web.☆PhistucK
Perhaps, but doesn't it also benefit those who are first to gather data using the prefix - and penalize late comers?
That is, using WebRTC as an example, it seems the prefix is to allow WebRTC-using sites to change/adapt their infrastructure. If we believed it was for the benefit of Chrome users directly, we could just expose the data gathering as part of Chrome UMA, without ever exposing to the web.
So sites that know about the prefix - which, presumably, includes Google sites (and, had PhistucK not mentioned it, may have been JUST Google sites), that can quickly adopt the prefix and gather data, have a greater chance to shape and influence the decisions.
How do we decide when we can remove the prefix? When we've decided we have collected enough data? Considering its the site operators collecting the data, this is the same as saying "When Google services decide they no longer need the data" - since if we kept it around (even at 50%) for other services, then we really are doing exactly what is wrong with prefixes - making them a defacto part of the platform.
So the prefixes deployed only benefit those that fastidiously follow Chrome development, can influence and convince Chrome devs to add a prefix, and convince Chrome devs to avoid removing a prefix until "sufficient" data is collected. That seems to be, effectively, Google only, so why not be transparent and spell that out in code?
Either way, if this is the route we go, a huge +1 to a clear and transparent policy.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Perhaps, but doesn't it also benefit those who are first to gather data using the prefix - and penalize late comers?
That is, using WebRTC as an example, it seems the prefix is to allow WebRTC-using sites to change/adapt their infrastructure. If we believed it was for the benefit of Chrome users directly, we could just expose the data gathering as part of Chrome UMA, without ever exposing to the web.
So sites that know about the prefix - which, presumably, includes Google sites (and, had PhistucK not mentioned it, may have been JUST Google sites), that can quickly adopt the prefix and gather data, have a greater chance to shape and influence the decisions.
How do we decide when we can remove the prefix? When we've decided we have collected enough data? Considering its the site operators collecting the data, this is the same as saying "When Google services decide they no longer need the data" - since if we kept it around (even at 50%) for other services, then we really are doing exactly what is wrong with prefixes - making them a defacto part of the platform.
So the prefixes deployed only benefit those that fastidiously follow Chrome development, can influence and convince Chrome devs to add a prefix, and convince Chrome devs to avoid removing a prefix until "sufficient" data is collected. That seems to be, effectively, Google only, so why not be transparent and spell that out in code?
On Aug 9, 2014 11:35 AM, "Aaron Boodman" <a...@chromium.org> wrote:
>
> On Sat, Aug 9, 2014 at 10:49 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>> Perhaps, but doesn't it also benefit those who are first to gather data using the prefix - and penalize late comers?
>
> It benefits developers who are aware of the experiment and take advantage of it. It might also benefit them if they provide feedback to vendors which results in changes to the API before it is finalized. It also (hopefully) benefits the users who are in the experiment group, because they get some new/better feature.
>>
>> That is, using WebRTC as an example, it seems the prefix is to allow WebRTC-using sites to change/adapt their infrastructure. If we believed it was for the benefit of Chrome users directly, we could just expose the data gathering as part of Chrome UMA, without ever exposing to the web.
>
> I don't know enough about this particular API to say whether there is some other way to do it besides adding DOM APIs to the platform.
>>
>> So sites that know about the prefix - which, presumably, includes Google sites (and, had PhistucK not mentioned it, may have been JUST Google sites), that can quickly adopt the prefix and gather data, have a greater chance to shape and influence the decisions.
>
> I would be in favor of us telling people widely when we were doing this so that lots of developers could take advantage of it and we'd get lots of feedback.
+1, and why I think we should codify policy.
>>
>> How do we decide when we can remove the prefix? When we've decided we have collected enough data? Considering its the site operators collecting the data, this is the same as saying "When Google services decide they no longer need the data" - since if we kept it around (even at 50%) for other services, then we really are doing exactly what is wrong with prefixes - making them a defacto part of the platform.
>
> This is where I disagree. Vendor-prefixed properties become a defacto part of the platform when they are present in a large enough percent of users' browsers that it starts becoming economically worthwhile for developers to optimize for that case and to ignore the case where the property doesn't exist.
>
> As long as the chance of the property existing is relatively small, then developers must continue to invest in the case where the property is missing, and the property can be removed at any time without breaking sites.
Except when it let's you optimize your server infrastructure ahead of those that aren't gathering the data, and indepdent of how it influences the client side.
Much of the data being gathered here can certainly help influence the standards process for WebRTC, of which Google is involved with in every aspect. But I think there is a real danger of using Chrome to act as a client-side metrics gathering for server side properties, which was true for webGL prefixes, and is true here, both to degrees.
While it helps standards - running code and real world experience - we do need to be careful here. And it doesn't seem like we've been doing well, especially around transparency (AFAICT)
>>
>> So the prefixes deployed only benefit those that fastidiously follow Chrome development, can influence and convince Chrome devs to add a prefix, and convince Chrome devs to avoid removing a prefix until "sufficient" data is collected. That seems to be, effectively, Google only, so why not be transparent and spell that out in code?
>
> I hadn't been thinking about the idea as a way to add Google-privileged APIs -- I was thinking of it as a better way for the Blink team to get early feedback on features which are genuinely on a standards track.
>>
>> Either way, if this is the route we go, a huge +1 to a clear and transparent policy.
>>
>> On Aug 9, 2014 10:37 AM, "Aaron Boodman" <a...@chromium.org> wrote:
>>>
>>> FWIW, I think the percent-limited experiment approach is great. I proposed it awhile back (https://plus.google.com/u/0/b/109132032588648589691/109132032588648589691/posts/84byPDaVLYa), but others on blink-dev weren't that happy about it back then. I'm glad to see it come back 'round :).
>>>
>>> I think it works best for cases where the experimental feature provides some genuine value to either the developer or user, but it's still possible to implement the application reasonably well using the fallback.
>>>
>>> - a
>>>
>>>
>>> On Fri, Aug 8, 2014 at 9:14 AM, Adam Barth <aba...@chromium.org> wrote:
>>>>
>>>> Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.
>>>>
>>>> Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist. Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.
>>>>
>>>> Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Fri Aug 08 2014 at 3:50:42 AM PhistucK <phis...@gmail.com> wrote:
>>>>>
>>>>> A recent commit (August 7th, 2014) in WebRTC added a goog prefixed constraint to webkitGetUserMedia -
>>>>>
>>>>> Log message
>>>>>
>>>>> (Auto)update libjingle 72847605-> 72850595
>>>>>
>>>>> Affected files
>>>>> expand all collapse all