Thanks for the update. As you can imagine, I am very interested in this!


Pine
( https://meta.wikimedia.org/wiki/User:Pine )


-------- Original message --------
From: Brion Vibber <bvibber@wikimedia.org>
Date: 6/28/18 1:54 PM (GMT-08:00)
To: Wikimedia Foundation Multimedia Team <multimedia@lists.wikimedia.org>
Cc: Wikimedia-tech list <wikitech-l@lists.wikimedia.org>
Subject: Re: [Multimedia] Video output changing to WebM VP9/Opus soon

Current state on this:

* delaying to mid-July so I don't start a batch process and leave it unattended for a week :)
* still hoping to deploy the libvpx+ffmpeg backport first so we start with best performance; Moritz made a start on libvpx but we still have to resolve ffmpeg (possibly by patching 3.2 instead of updating all the way to 3.4)
* after further testing of 30fps and 60fps files, I'm also planning to increase the data rate a bit.

I want to do a little more testing on the ideal data rate, but it'll end up looking more like a 30% reduction than a 38% reduction in file size. Our current VP8 and provisional-VP9 configurations were tuned mostly on 24fps files, while 30fps files are very common and require a moderately higher data rate to reduce compression artifacts. (50fps and 60fps files are also around, and will also benefit from an increase in data rate.)

(Possibly the data rate will end up scaled according to frame rate, but frame rate is surprisingly hard to calculate reliably for WebM input.)

-- brion


On Sun, Jun 17, 2018 at 1:32 PM Brion Vibber <bvibber@wikimedia.org> wrote:
On Sun, Jun 17, 2018 at 12:30 PM Brian Wolff <bawolff@gmail.com> wrote:
Woo!

Good to see us moving forward to newer codecs.

:D
 
What is the expected impact on transcode time/memory usage? (As in, will large videos still transcode fine or would they potentially hit limits sooner?)

Using the same CPU thread count, typical files take about 3-4 times longer with the configuration we've got ready. This doesn't seem to be a major problem at low resolutions, but higher resolutions may need to have the limits raised for very long videos like conference talks. Memory usage may be higher but I've not specifically noticed a major difference between VP8 and VP9 there.

This could be improved significantly by updating to libvpx 1.7 and a matching version of ffmpeg that supports macroblock row multithreading: this means that we'll be able to use more than 4 threads for HD videos, which should allow using all cores on a 20-core/40-thread machine if it's not loaded up with other files.

The necessary libraries are released; we just need to backport the newer packages to Debian 9 I believe. Don't yet know whether this will be an easy or hard task.

Now that you mention it I am concerned about the time limit on very long videos, so I'll take another look at the packaging backport and see if we can knock that out quickly. :)

-- brion