Do you have a specific solution in mind? The only thing I can think of would be to reduce the size of the data every now and then. Maybe divide by 2 when it reaches a certain arbitrary number of decoded frames and decode all the frames similarly so any data after that would be heavier. However, I think it will only help with #1 and I don't think #2 would really benefit from it unless we assume that some websites will run without using the API.

In general, I wonder if there is a solution for #2 apart from:
- clearing all data when not smooth every now and then;
- run local tests in Chrome and reset data if we see different results (à la Firefox).

I haven't given it much thought yet, but off the cuff:

1. Create a ping/pong schema in the DB where, for every profile/resolution/fps combo, we have 2 buckets of stats (ping and pong) where one is full and being used to respond to the API queries, and the other is filling up with new stats. Switch between ping and pong every time you hit some predefined threshold. Clear the old data every time you switch.

2. add a timestamp to the stats buckets that is "last written time". if last written is too old, wipe the data.

The timestamp would be a good solution to the case of everyone using the API and locking the user out of a configuration they could now use. My concern though is that if the API wasn't providing a false negative, we would actually reduce the general user experience by exposing support to something that isn't supported. Maybe this can be mitigated by picking a very long delay before wiping so it's less likely it will be hit and if it's hit, it will be less painful to the user as it would not happen often.

Yeah, long delay SGTM. Another thing we could do is hasten the wiping if we notice a large swing in other capabilities where data is regularly flowing in (e.g. user got a new CPU). 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc23b5920b370498f2e0466c1965a62787efec22

commit fc23b5920b370498f2e0466c1965a62787efec22
Author: chcunningham <chcunningham@chromium.org>
Date: Wed Sep 26 19:28:56 2018

Expire old stats from the VideoDecodeStatsDB

Metrics show that the DB makes its best predictions for a given key
after accumulating ~2500 frames. With this change rows in the DB will
begin to down-weight the existing frames after reaching the 2500 frame
max. New appends of more than 2500 frames will completely flush out old
stats. This roughly approximates a sliding window of the last 2500
frames without adding complexity to the DB of a real sliding window.

This change also expires old statistics that have not received an
update in the last 30 days. This ensures that clients who have a bad
outlier decode performance aren't punished forever - otherwise sites
may never give them another chance at that resolution / frame-rate.

Change-Id: I82f6920fbe3f594dad36d35b12c55d32e65de5a6
Bug:  818889 
Test: New unit tests
Reviewed-on: https://chromium-review.googlesource.com/1113503
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594427}
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/chrome/browser/browsing_data/browsing_data_remover_browsertest.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/blink/video_decode_stats_reporter.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/blink/video_decode_stats_reporter_unittest.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/capabilities/video_decode_stats.proto
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/capabilities/video_decode_stats_db.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/capabilities/video_decode_stats_db.h
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/capabilities/video_decode_stats_db_impl.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/capabilities/video_decode_stats_db_impl.h
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/capabilities/video_decode_stats_db_unittest.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/mojo/interfaces/media_types.mojom
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/mojo/services/video_decode_perf_history.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/mojo/services/video_decode_perf_history_unittest.cc
[modify] https://crrev.com/fc23b5920b370498f2e0466c1965a62787efec22/media/mojo/services/video_decode_stats_recorder.cc