Test List

https://wpt.fyi/results/webrtc-encoded-transform/RTCRtpScriptTransform-encoded-transform.https.html
https://wpt.fyi/results/webrtc-encoded-transform/script-transform.https.html

Rationale

I'm proposing that we add <meta name="timeout" content="long"> to these tests ( see documentation on this meta tag ).

(1) For RTCRtpScriptTransform-encoded-transform.https.html, all browsers are consistently reasonably close (less than an order of magnitude away) from the default 10-second harness-timeout-threshold, and at least Chrome and Firefox occasionally overshoot 10 seconds and get judged as failing the test (with a timeout) as a result.

Just looking at test results from yesterday...

• Here's a case where Firefox overshot the 10-second timeout:
  https://wpt.fyi/results/webrtc-encoded-transform/RTCRtpScriptTransform-encoded-transform.https.html?sha=6f599e27d8

• Here's a case where Chrome overshot the 10-second timeout:
  https://wpt.fyi/results/webrtc-encoded-transform/RTCRtpScriptTransform-encoded-transform.https.html?sha=8d423fc1ba

(I didn't find a case where Safari overshot 10 seconds in the past day of test runs, but Safari's consistently in the 2-3 second range which still feels somewhat dangerously close to 10 seconds, if there were some sort of system load/hiccup or async delay that slowed down the test by a factor of 3x for whatever reason.)

(2) for script-transform.https.html, runtimes are a bit lower, but sometimes much longer (in Firefox but not just Firefox).

• e.g. here's a test run from yesterday where Edge took just over 6 seconds:
  https://wpt.fyi/results/webrtc-encoded-transform/script-transform.https.html?sha=3af8623a0e

That 6s test-duration feels enough to 10 seconds to indicate that a 10-second timeout (assuming the test will never complete after that point) is too severe.