Video transcode config cleanup


Video transcode config cleanup

  • basic error details dialog for failed transcodes in the status table on the File: page.
  • various cleanup in ffmpeg usage and encoding config for VP8, VP9, and H.264 output
  • disable 120p and 180p VP9 transcodes by default doesn't really seem necessary; use 240p as lowest default transcode size. See T312153 for cleanup directions after deployment.
  • simplify VP8/VP9 config for more predictable bitrates: use a lower target rate, remove quality constraint
  • scale bitrate with frame rate; gives better quality on 50fps and 60fps material and saves space at 24fps
  • base TimedMediaHandler class now implements the getFramerate() method, returning 0 when irrelevant. this simplifies use of it vs checking for the specific subclasses supporting it
  • when not using a fixed-rate format, allow deinterlacing to emit one frame per field, which preserves motion in interlaced SD and HD footage in MPEG-2 format (and, eventually, MPEG-4 or H.264 input once allowed). this doubles the output framerate, increasing bitrate.
  • when using native MediaWiki thumbnailing, interlaced MPEG-2 files now extract deinterlaced thumbnails
  • change VP9 to increase speed 2-3x in exchange for about 25% higher bitrates: disabled auto alt ref and using more aggressive speed param at high res
  • tweaked H.264 alternate config to be more consistent with the quality of the VP9 config
  • tweaked all audio configs to be more consistent; most video sites report that users care more about audio quality than video quality, so using full quality at all resolutions
  • use bitrate to estimate output file size, and error out early if it exceeds $wgTranscodeBackgroundSizeLimit
  • add soft limit as $wgTranscodeSoftSizeLimit, defaulting to 2 GiB. this is overrideable by manual transcode resets on the web or requeueTranscodes.php --manual-override, unlike the hard limit.

Regarding the VP9 size/speed tradeoff; the intention is to
later add the ability to use higher quality configs on
specific files to re-run them at higher compression if it's
frequently played, but this will probably wait until HLS is

There is no need to re-run existing files made with the
previous config at this time.

Note that VP9 files with multichannel Opus will fail in
Safari; they should fail over automatically to VP8/Vorbis
transcodes in playback.

Note that the frame rate check uses existing code in getid3,
and has reported a wildly incorrect value on at least one
input file in my test set. Capping to a min of 24 and max
of 60 for bitrate calculations keeps things reasonable.
It would be possible to get a more accurate frame rate by
calling out to ffprobe, but this is not guaranteed to be
available on app servers in production I think.

The bitrate is scaled linearly from 24 to 30 fps, than at
0.5x from 30 to 60. Lower or higher reported frame rates
are capped to 24-60 for bitrate, and a -fpsmax is set
to 60 if the format doesn't enforce a stricter limit.

Bug: T312152
Change-Id: I1a17441e71e556e67669ab665e804298c546f9db


brionAuthored on Aug 22 2022, 5:20 PM
rETMHd7216b655b2b: Localisation updates from https://translatewiki.net.