Taylor, feel free to grab it if you want to start!
As usual, there are a few steps involved, since we can't break users' code:
- Add UMA counters for how much they're used
- File an intent-to-deprecate-and-remove, citing the numbers found
- Change the counters to deprecation warnings (which also count)
- Wait for a revision or two, or until usage is reasonably low
- Remove
Happy to see someone starting this!
@hta, that's very interesting idea not to break users' code. But it's hard to follow the steps because I'm newbie in chromium community even though I've handled chromium browser on the embedded products for several years. Could you tell me in more detail?
[Questions]
1. What is UMA counters?? And how can I change the counters to deprecation warnings??
2. Is it file name "intent-to-deprecate-and-remove"? And where should I put it in chromium directory?
3. I got it that removing |remote| and |readonly| members after waiting until usage is reasonably low. Then who decides "reasonably low"?? And how do we measure degree of use??
Sorry for too many questions at a time.
@hta, I don't know why the following message is made by bugdroid1@chromium.org.
"The following revision refers to this bug"
What am I supposed to do for it?
#23 - it documents that some code changes that are relevant to this issue were made in Chromium by someone.
Since you starred the issue, you get it as an e-mail notification, like any other comment.
You do not need to do anything.
+dalecurtis, who authored the smoothness algorithm according to git.
peary2@'s CL was reverted because it caused a performance regression.
The original code applies a smoothness algorithm to remote video tracks. After removing the remote attribute, the algorithm was applied to local tracks as well, which caused the performance regression.
I think a solution is to keep the attributes in the content layer and just not expose them to Blink. Dale, what do you think?
No idea :) +qiangchen who worked on the MediaStream version. The metric increased from 15 to 59, which I guess is bad, but can't seem to find details on the calculation to confirm that. Why do we not want smooth remote tracks? Did this make the remote ones not-smooth?
Yes, I noticed the issue when doing the smoothness project, the problem on smoothing local preview is that
1. Smoothing algorithm requires queuing several (for most cases, just 2) frames for selection.
2. We have only 3 capture buffers.
So if the smoothing algorithm applies to local preview, it would hold 2 buffers, then allow only 1 buffer in commuting, then from time to time the camera is waiting for buffer, and un-smoothness occurs.
Based on #29, I think the best way to proceed with this bug is to remove the |remote| and |readonly| attributes from the Blink layer, but leave them in content so as to not affect the smoothness algorithm.
peary2: Do you want to amend your CL to reflect this?
Comment 1 by mcasas@chromium.org
, Mar 29 2016