Page MenuHomePhabricator

"fast" and "high-compression" tiers for video transcodes
Open, Needs TriagePublic

Description

Currently we transcode videos to their primary VP9 targets at all resolutions roughly at once, then never touch them again unless someone manually re-runs them with the then-current global settings. This wastes encoding time on files which are rarely used if we use high compression, or wastes bandwidth and quality on files which are often viewed if we use faster low compression.

We should consider a two-tier system:

  • first tier is fast
    • See bug T413030 for current proposal to drop two-pass encoding on default VP9 transcodes.
    • this gets files viewable as fast as possible, starting with low resolutions and proceeding to high ones
  • second tier is slower, produces more efficient output
    • for VP9 would use two-pass and higher-quality settings
    • this reduces the bandwidth usage of frequently-viewed files

See also bug T209437 for adding AV1; AV1 can likewise be encoded fast-and-sloppy or slow-and-compressy.

The second tier could be automatically triggered after hitting a view count threshold, or could be forced by users. Adding the second tier should *not* stop the first tier from continuing to play back while it's running, but might want to remove the files afterwards to save disk space.

Event Timeline

I‌ love the idea. One thing we could also try to do is to instead of looking at views which is not directly available in our mediawiki env, we can look at whether it's been used in main namespace of any other wiki so if a video is used in an article in German Wikipedia, it would get the "high-compression" treatment. Easier to check as well.