Do these bad frames indicate a deterministic bug that you can fix, or can they be caused by things outside of your control (e.g. higher system load or IO hiccups caused by other processes running on the DUT)?

If it's the latter, I'd recommend against making them trigger test errors (unless you set an extremely high threshold that you never expect to see hit), since they're probably going to be a constant source of test flakiness otherwise.

This seems like it may be better to report as perf data (if it isn't already) that can be manually inspected.

These error looks random and uncontrolable for me.
So, I created crrev.com/c/1303783 not to report errors even when many frames are broken on real device tests.
I think VM tests using vivid won't cause such flakiness.

These tests are reporting frame statistics as perf data already. (though it seems that tast.informational-chrome's data haven't appear anywhere yet.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/2a7670ee97f79d1c7179336b1da02f6fe2a4a3e7

commit 2a7670ee97f79d1c7179336b1da02f6fe2a4a3e7
Author: Keiichi Watanabe <keiichiw@chromium.org>
Date: Mon Oct 29 18:21:39 2018

video.WebRTC*: Don't raise error by broken frames on real devices.

To avoid uncontrolable test flakiness, stop raising test errors
even if some video frames are broken when WebRTC tests are running
on real devices.

This change doesn't mean that we will ignore broken frames, because
these tests report frame statistics as perf data.

BUG= chromium:898745 , chromium:899586,  chromium:882433 
TEST=Run tast.video.WebRTC* on kevin/amd64-generic VM

Change-Id: I3d8d28f595bcd3f35ac42975ec5791220ec0ec7c
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1303783
Reviewed-by: Shuhei Takahashi <nya@chromium.org>

[modify] https://crrev.com/2a7670ee97f79d1c7179336b1da02f6fe2a4a3e7/src/chromiumos/tast/local/bundles/cros/video/webrtc/webrtc.go

The change was landed in 11206.0.0 and errors disappeared:
https://stainless.corp.google.com/search?view=matrix&row=model&col=build&first_date=2018-10-30&last_date=2018-10-30&test=tast.video.WebRTC&build=R72&exclude_cts=false&exclude_not_run=false&exclude_non_release=true&exclude_au=true&exclude_acts=true&exclude_retried=true&exclude_non_production=false

So, I'll mark this issue as fixed.