Plan of VP9 software decoder in Chromium

[Jay]

Hi All,

   Does anyone know the plan of VP9 SW(software) decoder in Chromium? Could ffmpeg be used as VP9 software decoder in Chrome?

   I found that Chromium integrates both libvpx and ffmpeg as VP9 SW decoders and it uses libvpx as VP9 SW decoder by default currently. 

   Here is piece of source code in function "DefaultRendererFactory::CreateRenderer":

   if (gpu_factories_.get())

    video_decoders.push_back(new GpuVideoDecoder(gpu_factories_));

 

   #if !defined(MEDIA_DISABLE_LIBVPX)

  video_decoders.push_back(new VpxVideoDecoder(media_task_runner_));

   #endif  // !defined(MEDIA_DISABLE_LIBVPX)

   video_decoders.push_back(new FFmpegVideoDecoder(media_task_runner_));

  Chromium put all video decoders in a vector called “video_decoders” in a sort order. When the first decoder does not work, it will use the next one. We could observe that Chromium will first check GpuVideoDecoder, then VpxVideoDecoder and FFmpegVideoDecoder. 

  Here libvpx is wrapped by a macro called “MEDIA_DISABLE_LIBVPX”, which is controlled by a build flag called “media_use_libvpx”. I disabled libvpx by modifying the build configuration and found that FFmpegVideoDecoder will be used as VP9 software decoder. However, it will fail in function "bool FFmpegVideoDecoder::ConfigureDecoder(bool low_delay) ". It seems ffmpeg is not well integrated as Chromium VP9 software decoder. Then why does chromium put ffmpeg in the VP9 video decoder list? Any comments? 

   

   Thanks very much!

[PhistucK]

The code looks too generic to be concerned only with VP9 (I could not find a single mention of "VP9" in that file and the rest of the path also does not mention it), so I guess FFMPEG is used for other codecs and not for VP9 (I bet the codec is explicitly disabled in FFMPEG for Chrome, because it does not need two implementations of the same codec, I presume), which probably means the code path you want to exercise is simply not implemented.

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Dale Curtis]

We currently do not use the vp9 decoder provided by ffmpeg, but you can reconfigure and build ffmpeg to include support. I have a test patch for this here that I used for performance evaluations:

https://codereview.chromium.org/736873002/

libvpx had vp9 support far before ffmpeg, since vp9 was developed internally (and is still active). The ffvp9 decoder is still missing a few features. Last I heard from Ronald, they are:

- scalable doesn't work (actually, I think the bitstream parses fine, but content is predicted without scaling so output looks like crap)

- anything profile 1 and up doesn't work (422, 444, rgb, 10bit, 12bit, etc.)

- x86 32bit isn't as well-optimized as 64bit (it may still be somewhat competitive with libvpx, I don't know)

- not arm optimized (neon)

- dale

[Feng, Jay]

Hi Dale,

 

   It seems ffvp9 will not be used as VP9 software decoder in short term, since it is still under performance evaluation and is missing some features, right? Do you have any information about roadmap or plan to share about this?

    Thanks very much!

[Paweł Hajdan, Jr.]

Just curious, what are possible advantages of using ffvp9 instead of libvpx? I'm trying to understand context for this thread.

Paweł

--

[Dale Curtis]

At this time libvpx does not have frame-level multithreading, while ffvp9 does so in some cases the performance is better. You can read more about that on Ronald's blog:

http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

We have no plans to switch to ffvp9 at this time, so there's no further information I can share.

- dale