Bug 91569 – [chromium] We need layout tests for testing the H/W VDA code

• Component: WebCore Misc.
• Status: RESOLVED WONTFIX

[Ananta Iyengar]

The H/W video decode codepath in Chromium does not have layout tests to help catch
issues like the one here https://bugs.webkit.org/show_bug.cgi?id=91562

A possible approach mentioned by Adrienne Walker

You could either explicitly enable the hardware video path via a new function in Chromium's LayoutTestController.cpp (look for how we handle loseCompositorContext as an example).  Alternatively, you could create a (hypothetical) LayoutTests/platform/chromium/compositing/hardwarevideo/ directory and then modify TestShell::runFileTest to set these flags on anything in that directory.

Then I think you could just take a basic video layout test and run it through the hardware path.

[Ami Fischman]

Assigning to myself; anyone else who wants this ping me.

[Ami Fischman]

Note given the current state of HW decode enabling, it's not enough to enable the HW path, because there is SW fallback.  Maybe we should allow somehow expose
chrome://histograms/Media.GpuVideoDecoderInitializeStatus
to LayoutTestController (assuming it even has chrome://histograms; hmm).

[Ami Fischman]

Extra-tricky: HW video decode is currently only supported for h.264.  We're about to get VP8 support too, but only on one platform (and one that is not part of the public waterfalls).  But chromium's DRT is built without h264 support (because it is not built with $GYP_DEFINES including proprietary_codecs=1 and ffmpeg_branding=Chrome).

This means that end-to-end testing of HW decode cannot be done using layouttests on the usual bots with the usual DRT.  

Some possibilities:
1) Use unusual DRT: build a Chrome-branded DRT (w/ proprietary codecs) to run on the usual bots (win7, mac, cros that has HW decode capabilities)
2) Use unusual bots: build a normal chromium DRT but run it on a (so far nonexistent) bot on HW that supports VP8 HW decode, once https://chromiumcodereview.appspot.com/10808058/ lands)
3) Give up on end-to-end testing and content ourselves with testing just the webkit compositor path, by stubbing out actual video decode and replacing it with dummy textures.
4) ???

Ideas welcome.

[Adrienne Walker]

(In reply to comment #3)

> Ideas welcome.

Is it possible to do a HW video decoder adapter that does software video decode and then uploads video frames and pretends to be a HW video decoder?

[Ami Fischman]

(In reply to comment #4)
> Is it possible to do a HW video decoder adapter that does software video decode and then uploads video frames and pretends to be a HW video decoder?

Possibly, but not (at all) easily.

FWIW, note this a very platform-dependent feature, so any approach that virtualizes the HW out of the picture is unlikely to catch all the regressions we worry about (e.g. bug 91562 which gave birth to this bug).

[Ami Fischman]

CrOS now has tests for HW decode initializing and beginning decode correctly.
Post-blink, this [chromium] bug is uninteresting to webkit, so WONTFIXing.