Thanks to all people involved,

I just read about this new video format in the making/released [0].

Of course, I am not asking to support this, as this seems like the future, and not the present, but being a complete noob on video formats and codecs, I would like to know if someone more knolegeble has some insight about this and if it is something to keep in mind/someone has tested it and has experiences to share/client and vendor support?

--
Jaime

[0] <url:https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/>

On Fri, Jun 29, 2018 at 6:46 PM, Brion Vibber <bvibber@wikimedia.org> wrote:
Awesome sauce. Thanks Moritz!

-- brion

On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff <
mmuhlenhoff@wikimedia.org> wrote:

> Hi all,
>
> On Thu, Jun 28, 2018 at 01:54:18PM -0700, Brion Vibber wrote:
> > Current state on this:
> >
> > * 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)
>
> I've completed this today. We now have a separate repository component
> for stretch-wikimedia (named component/vp9) which includes ffmpeg 3.2.10
> (thus allowing us to follow the ffmpeg security updates released in Debian
> with a local rebuild) with backported row-mt support and linked against
> libvpx 1.7.0.
>
> I tested re-encoding
>
> https://commons.wikimedia.org/wiki/File:Wall_of_Death_-_Pitts_Todeswand_2017_-_Jagath_Perera.webm
> (which is a nice fast-paced test file) from VP8 to VP9, which results in
> a size reduction from 48M to 31M.
>
> When using eight CPU cores on one of our video scaler servers, enabling
> row-mt
> gives a significant performance boost; encoding time went down from 5:31
> mins
> to 3:36 mins.
>
> All the details can be found at
> https://phabricator.wikimedia.org/T190333#4324995
>
> Cheers,
>         Moritz