GitLab

VideoDecoderPipeline holds together a (Vaapi|V4L2)VideoDecoder, a frame
pool and a converter. It gets a series of VideoDecoder create functions
from ChromeosVideoDecoderFactory, and needs to go through each decoder,
trying to create and then Initialize() each -- the first one that works
is good to go.

VideoDecoderPipeline retrieves such create functions and holds on to the
last |used_create_vd_func_| along such Create+Initialize cycles (to
avoid repeating a potentially broken one) and relies on the factory's
GetCreateDecoderFunctions() to return all such functions /except/ the
one passed as argument. This logic, aside from convoluted, is broken if
there were more than 2 such create functions. This CL simplifies all
that by keeping a list of |remaining_create_decoder_functions_| that are
tried and, if failed, discarded.

During the moves along the different initialization methods (see [1]),
a given Status is constructed and filled to indicate a potential
failure. Status [2] works in a non-intuitive way because it must be
constructed with a given StatusCode, which becomes its code(), but can
AddCause() to it -more StatusCodes- that are sadly, opaque. ToT uses a
kChromeOSVideoDecoderNoDecoders as start StatusCode, so any subsequent
errors e.g. kDecoderFailedCreation or kDecoderFailedInitialization are
thrown into the opaque causes. This CL changes this to start with a kOk,
and then collect the first meaningful error StatusCode.

Unittests added to hopefully clarify and identify the use cases.

[1] https://i.imgur.com/qH17CTJ.jpg (or https://imgur.com/a/anCJ2Ig)
[2] https://source.chromium.org/chromium/chromium/src/+/master:media/base/status.h;l=41

Bug: 1040291
Change-Id: I35889605850eb51e0dfe9308688c092d2b755edd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2259472
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Jao-ke Chin-Lee <jchinlee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#781964}