Drop back to back frames in VideoFrameResolutionAdapter::MaybeDropFrame.

Drop back to back frames in VideoFrameResolutionAdapter::MaybeDropFrame.
We have observed on some Mac that video frames are delivered back to back from the build in video capture device. This can potentially happen on all platforms. If that happen, the simple filter used for frame rate calculation get scewed. This cl fix that by dropping all frames received within 5ms of the previous frame.

BUG=394315
Committed: https://crrev.com/2924f310947b5a091390a6c06b37f7796bee47e7
Cr-Commit-Position: refs/heads/master@{#292361}

[perkj_chrome, 2014-08-28 06:48:03]

Patchset #1 (id:1) has been deleted

[perkj_chrome, 2014-08-28 06:51:32]

perkj@chromium.org changed reviewers:
+ mcasas@chromium.org

[perkj_chrome, 2014-08-28 06:51:33]

Can you help verify this fix and review it?

[perkj_chrome, 2014-08-28 07:40:33]

perkj@chromium.org changed reviewers:
+ tommi@chromium.org

[perkj_chrome, 2014-08-28 07:40:33]

Tommi, can you please review as well?

[mcasas, 2014-08-28 08:26:40]

LGTM with nit.

Will verify during the day, anyway this is basically what we did 
yesterday on the spot.

https://codereview.chromium.org/516783002/diff/40001/content/renderer/media/v...
File content/renderer/media/video_track_adapter.cc (right):

https://codereview.chromium.org/516783002/diff/40001/content/renderer/media/v...
content/renderer/media/video_track_adapter.cc:238: << delta.InMilliseconds();
nit: add 
<< "ms";
after delta.InMilliseconds()

[tommi (sloooow) - chröme, 2014-08-28 09:01:39]

lgtm % please update comment.

https://codereview.chromium.org/516783002/diff/40001/content/renderer/media/v...
File content/renderer/media/video_track_adapter.cc (right):

https://codereview.chromium.org/516783002/diff/40001/content/renderer/media/v...
content/renderer/media/video_track_adapter.cc:236: // anyway so therefore
instead dropped.
To be fair, when this happens, the frames were very likely not actually captured
at the interval that the timestamps suggest (unless we're trying to render
something in realtime from an ultra-speed video camera).
I'd rather like a todo here for handling/correcting the situation where the
timestamps are bad.  Given that the timestamps have been proven to be unreliable
in some cases, it would be good to not actually have to rely on them :)

I also don't think we should be making assumptions about the relevance of what's
visible to the naked eye since this code should be generic and not aware of
whether or not the track is going to ultimately be rendered at the same speed
it's being captured.  (think e.g. of the above cameras, recording, later
playback at a fraction of the capture fps).

[tommi (sloooow) - chröme, 2014-08-28 09:06:00]

On 2014/08/28 09:01:39, tommi wrote:
> lgtm % please update comment.
> 
>
https://codereview.chromium.org/516783002/diff/40001/content/renderer/media/v...
> File content/renderer/media/video_track_adapter.cc (right):
> 
>
https://codereview.chromium.org/516783002/diff/40001/content/renderer/media/v...
> content/renderer/media/video_track_adapter.cc:236: // anyway so therefore
> instead dropped.
> To be fair, when this happens, the frames were very likely not actually
captured
> at the interval that the timestamps suggest (unless we're trying to render
> something in realtime from an ultra-speed video camera).
> I'd rather like a todo here for handling/correcting the situation where the
> timestamps are bad.  Given that the timestamps have been proven to be
unreliable
> in some cases, it would be good to not actually have to rely on them :)
> 
> I also don't think we should be making assumptions about the relevance of
what's
> visible to the naked eye since this code should be generic and not aware of
> whether or not the track is going to ultimately be rendered at the same speed
> it's being captured.  (think e.g. of the above cameras, recording, later
> playback at a fraction of the capture fps).

which begs the question... don't we need one of these? :)
http://www.ximea.com/usb3-vision-camera

[perkj_chrome, 2014-08-28 10:05:00]

The CQ bit was checked by perkj@chromium.org

[commit-bot: I haz the power, 2014-08-28 10:05:35]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/perkj@chromium.org/516783002/60001

[commit-bot: I haz the power, 2014-08-28 11:01:25]

Committed patchset #3 (id:60001) as b51b9257169dbda090cc43c29a77dbb88c56c643

[commit-bot: I haz the power, 2014-09-10 02:58:53]

Patchset 3 (id:??) landed as
https://crrev.com/2924f310947b5a091390a6c06b37f7796bee47e7
Cr-Commit-Position: refs/heads/master@{#292361}