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 qmin/qmax will be lower quality / smaller bandwidth.
The settings we'll be using for derivatives are based on the constrained
quality mode, using the -crf option plus a relatively high maximum bitrate
as a constraint for high-motion files, and also a conservative -qmin to
ensure that bits aren't wasted on details that are actually source
compression artifacts.
In general, you should optimize the files you upload for quality, not for
size -- higher source quality ensures better quality for the viewable
derivatives, and for future re-use possibilities. Note that you can keep
using VP8 for uploaded files; there's no immediate need to change
configurations for uploads unless the files themselves are too big to
upload and need higher compression.
-- brion
On Thu, Jul 26, 2018 at 9:38 PM rupert THURNER <rupert.thurner(a)gmail.com>
wrote:
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-pass…
using:
https://tools.wmflabs.org/video2commons/
which used the following (i removed the paths ...)
ffmpeg -y -i dl.unknown_video -threads 0 -skip_threshold 0 -bufsize
6000k -rc_init_occupancy 4000 -qmin 19 -qmax 19 -vcodec libvpx-vp9
-tile-columns 4 -f webm -ss 0 -an -pass 1 -passlogfile
dl.unknown_video.an.vp9.webm.log /dev/null
ffmpeg -y -i dl.unknown_video -threads 0 -skip_threshold 0 -bufsize
6000k -rc_init_occupancy 4000 -qmin 19 -qmax 19 -vcodec libvpx-vp9
-tile-columns 4 -f webm -ss 0 -an -pass 2 -passlogfile
dl.unknown_video.an.vp9.webm.log dl.unknown_video.an.vp9.webm
the size increased by 30 mb, the quality on a smaller screen is the
same, i did not verify on a high resolution screen if a difference can
be noticed.
rupert
On Fri, Jul 27, 2018 at 2:47 AM, Brion Vibber <bvibber(a)wikimedia.org>
wrote:
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 significantly
increase disk space projections for now.
These can take a long time to compress, so if we find it's problematic
we'll
turn them back off until the jobs can be split
into tiny chunks (future
work
planned!), but it works in my testing and
shouldn't clog the servers now
that we have more available.
(Note that the ogv.js player shim for Safari will not handle
greater-than-HD
resolutions fast enough for playback, even on a
fast Mac or iPad; for
best
results for 4K playback use Firefox, Chrome, or a
Chromium-based
browser.)
-- brion
On Thu, Jul 26, 2018 at 5:39 PM Brion Vibber <bvibber(a)wikimedia.org>
wrote:
>
> 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 beginning of VP9 rollout starting next
week.
>
> Changes since the earlier announcement:
> * the new row-multithreading will be available, which allows higher
> threading usage at all resolutions; encoding times will be more like
1.5-2x
> slower instead of 3-4x slower.
> * switch to constrained quality with a larger max bitrate: many files
will
> become significantly smaller in their VP9
versions, but some will
actually
> increase in exchange for a huge increase in
quality -- this is mostly
60fps
> high-rate files, and those with lots of
motion and detail that didn't
> compress well at the default low data rates.
>
> -- brion
>
> On Fri, Jun 29, 2018 at 9:46 AM Brion Vibber <bvibber(a)wikimedia.org>
> wrote:
>>
>> Awesome sauce. Thanks Moritz!
>>
>> -- brion
>>
>> On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff
>> <mmuhlenhoff(a)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_201…
>>> (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
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Multimedia mailing list
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________________________
Multimedia mailing list
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia