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 <[email protected]> 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-passh%C3%B6he-silent.webm > > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> wrote: > >>> > >>> Awesome sauce. Thanks Moritz! > >>> > >>> -- brion > >>> > >>> On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff > >>> <[email protected]> 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 > >>>> > >>>> _______________________________________________ > >>>> Wikitech-l mailing list > >>>> [email protected] > >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > _______________________________________________ > > Multimedia mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/multimedia > > > > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
