Just an update -- background transcoding has been restarted now that we're
switched back to the Virginia data center where the majority of encoders
are.
Converting the lat 1/3 of videos to VP9 should be finished by the end of
November, approximately. At that point we'll probably start removing
These conversions have been running in the background, at a moderate load
to ensure we don't slow down newer uploads much, and are up to the "P"s
alphabetically so we're on schedule. :)
I've temporarily stopped the batch process pending the upcoming datacenter
switchover test, and will continue
Quick update... no major problems noticed so far. One configuration change
I made was to re-enable VP8 transcodes for new files, since disabling them
completely lead to the existing ones not being used. Later in the
transition, or afterwards, we'll clean up the now-unused VP8 transcodes.
If I'm
Batch process is continuing... over 2200 source videos have been compressed
to VP9 so far, of the 120k+ total in the system.
Seeing big improvements in overall compression, though it's hard to tell
how representative the subset of conversions done so far is. I'll post
occasional updates to the
I meant end of August. Sorry for the extra email noise.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
On Tue, Jul 31, 2018 at 2:15 AM, Pine W wrote:
> Thanks, Brion. At my current rate of progress, I'll be making use of this
> feature by the end of the month.
>
> Pine
> (
Thanks, Brion. At my current rate of progress, I'll be making use of this
feature by the end of the month.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
On Tue, Jul 31, 2018 at 12:51 AM, Brion Vibber
wrote:
> Configuration has been updated and VP9 mode swapped in. Newly uploaded
> videos
Configuration has been updated and VP9 mode swapped in. Newly uploaded
videos should start encoding as VP9 starting now.
I'll start the backfill batch process tonight or tomorrow, and will likely
stop and restart it a few times over the coming weeks if anything needs
adjustment. Please file tasks
The quality/bandwidth for the output in this command will be determined by
the qmin/qmax settings you provided; the value of 19 is a bit conservative
and will likely produce a relatively large, but good quality file. Try
various different settings to dial in on desired quality; larger settings
for
i tried VP9 uploading a video with a spinning wheel made with a
samsung galaxy s5, mp4, original size 99.5MB. i removed the sound
beforehand though:
https://commons.wikimedia.org/wiki/File:180522-alpaca-spinnen-gotthard-passh%C3%B6he-silent.webm
using:
https://tools.wmflabs.org/video2commons/
Oh and one more thing!
For the VP9 configuration I'll be enabling 1440p and 2160p ("4K")
resolutions, which people can manually bump up to when watching videos with
a suitable 4K source on a high-res screen. They use higher data rates, but
only a small fraction of input files are 4K so should not
Ok, after some delay for re-tweaking the encoding settings for higher
quality when needed, and pulling in some other improvements to the config
system, all related updates to TimedMediaHandler have been merged. :D
If all goes well with the general deployments in the next few days, expect
the
Awesome sauce. Thanks Moritz!
-- brion
On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff <
mmuhlenh...@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
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
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
Date: 6/28/18 1:54 PM (GMT-08:00) To: Wikimedia Foundation Multimedia Team
Cc: Wikimedia-tech list
Subject: Re:
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
On Sun, Jun 17, 2018 at 12:30 PM Brian Wolff 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
Woo!
Good to see us moving forward to newer codecs.
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?)
--
brian
On Sunday, June 17, 2018, Brion Vibber wrote:
> In the next couple weeks I'm
17 matches
Mail list logo
