RTCVideoDecoder will soon shim webrtc::VideoDecoder calls to media::VideoDecoder:
https://codereview.chromium.org/2418613002

Currently, the assumption used widely in webrtc is that if a codec is not supported, then a nullptr will be returned from RTCVideoDecoder::Create(). This requires querying the underlying decoder capabilities inside Create(), which was easily done with a VideoDecodeAccelerator, but is not supported by media::VideoDecoder.

The workaround for this is to call Initialize() on the media::VideoDecoder after constructing it in Create(), and wait for the result to come back before returning. If the decoder initializes successfully, we return the decoder, else we return nullptr, so the caller knows to fallback to software right away. Then, in InitDecode(), if the webrtc::codecSettings differ from the codec settings used to initialize the decoder (namely: the size of the video), then we issue *another* blocking Initialize() call before returning.

As part of the VDAv2 effort, we will add synchronous capability query methods to VideoDecoder. When the interface has been updated, replace the Initialize() call in Create() with a capability query.