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
ready.
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