Replace uses of legacy SkImageGenerator API

media/renderers/skcanvas_video_renderer.cc

Index: media/renderers/skcanvas_video_renderer.cc
diff --git a/media/renderers/skcanvas_video_renderer.cc b/media/renderers/skcanvas_video_renderer.cc
index 395f6d613e466a45a885d11334fd815788e4ac53..a9b55e0ef5f7994519daa86b7000c55ad7c07112 100644
--- a/media/renderers/skcanvas_video_renderer.cc
+++ b/media/renderers/skcanvas_video_renderer.cc
@@ -244,8 +244,7 @@ class VideoImageGenerator : public SkImageGenerator {
   bool onGetPixels(const SkImageInfo& info,
                    void* pixels,
                    size_t row_bytes,
-                   SkPMColor ctable[],
-                   int* ctable_count) override {
+                   const Options&) override {

[chcunningham, 2017/05/16 18:50:54]

Should these options have implications for conversion to RGB below? Sorry,
pretty unfamiliar.

[msarett1, 2017/05/16 18:59:15]

No problem.  The "options" should not, given that YUV is opaque and the only
current option deals with alpha blending behavior.

In theory, an SkImageGenerator should respect the width, height, color type,
color space on the SkImageInfo - but if that's something we need to do here, it
probably belongs in a separate change.  I suspect it is not necessary right now
anyway.

     // If skia couldn't do the YUV conversion on GPU, we will on CPU.
     SkCanvasVideoRenderer::ConvertVideoFrameToRGBPixels(frame_.get(), pixels,
                                                         row_bytes);