The current VPXDecoder (and WebMReader) are using libvpx with the default decoding option which is to use a single thread for all operations. We should use multi-thread operations if possible. FFmpeg configure libvpx with min(16, num_processors) ; which chrome sets it to two. We should also ensure that libvpx is built with multi-threading support.

This is using the same logic as chromium.

Comment on attachment 8671711 [details] [diff] [review] [vpx] P1. Configure libvpx to use two threads. This is part of the 1193614 uplift. Approval Request Comment [Feature/regressing bug #]: 1193614 [User impact if declined]: Video playback will be slower, causing frames to be skipped. [Describe test coverage new/current, TreeHerder]: current media tests [Risks and why]: This low-risk patch helps to improve decoding speed by using more than one thread to decode. This is the same approach has done by popular media players and chrome. [String/UUID change made/needed]: None

Comment on attachment 8671711 [details] [diff] [review] [vpx] P1. Configure libvpx to use two threads. We are very late in the cycle: we are going to build beta 9 tomorrow. I think this can wait 43 and we will have more time to test the feature.

Comment on attachment 8671711 [details] [diff] [review] [vpx] P1. Configure libvpx to use two threads. May improve video decoding performance and has some test coverage; let's try it in aurora.

jya, do we have a baseline to measure performance to see if this improves things?

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #7) > jya, do we have a baseline to measure performance to see if this improves > things? Dan found that for a typical VP9 video it has effectively halved the decoding time (from 30+ms to 16ms) We do not have otherwise a tool readily available to measure decoding speed. We have tools that can provide log, but that need a debug build.

I'm ok just believing y'all's judgement, but was curious if you were going to come back and measure it after the uplift. Carry on!