Background

An iOS 18 device playing back one of our WebM videos at a nice sharp HD 1080p resolution:

Playback of our WebM video output files is unavailable on older iPhones, until about iOS 17.4. All iPhones running iOS 18 can play back WebM; all on 17.3 or earlier cannot. Older devices currently get our fallback compatibility track, which is a blurry 144p Motion-JPEG .mov:

While we have a shim ogv.js that can play back WebM on those iOS versions, we've been migrating off it to the native fallback track because the shim is slow and janky on older phones. Using a format that's natively supported by the phone is cleaner, faster, and supports use cases like fullscreen, picture-in-picture, and casting to a TV.

The initial fallback transcode we added last year is using Motion-JPEG, which is supported by all iPhone versions and unpatented, but very inefficient in terms of compression; this means that the 1-megabit stream is a very low resolution 144p, and appears quite blurry on a phone much less being casted to a big TV.

Per Wikimedia's traditional codec patents policy we continue to avoid h.264/AVC, the most common generic video codec today, but its older cousin MPEG-4 Visual has fallen out of patent in recent years and is well-supported by every old model of iPhone. This compresses much better than Motion-JPEG and should support 240p, 360p, and 480p standard-definition transcodes within the data rate constraints we spent on MJPEG.

These will look fairly clean on a phone, up to as good as our current WebM 480p but with a higher data rate:

We can either pair it with its matching AAC-LC audio codec, also expired of patents, or we can continue to use MP3 for the audio track if we are conservative.

Work proposed

• Add QuickTime MPEG-4 Visual + AAC-LC transcode tiers to WebVideoTranscodes.php:
  • (video bitrates are provisional -- test these on some files and compare them visually against the WebMs)
  • 240p.mpeg4.mov - 500 kbits
  • 360p.mpeg4.mov - 1000 kbits
  • 480p.mpeg4.mov - 2000 kbits
  • all with 128 kbits for audio
  • Use codec string video/quicktime
• Add any necessary strings/setup to describe the tracks
• enable them in config once in production
  • this is enough to start them generating on new uploads
• (optional) Start a batch encode of all missing .mpeg4.mov files with maintenance/requeueTranscode.php
  • this may be a larger task to monitor it as the tools are not very good and should themselves be improved, cf T362123. Consider breaking this out and adding dependencies.
  • Disable and remove the old MJPEG tracks when done, they won't be needed and it'll free disk space.

Benefits

Anybody who's rocking an older-model iPhone with our mobile web site or app will appreciate the much clearer videos. :)

iOS 16 and below are a fraction of total iOS hits according to stats, and will continue to shrink, but that's still several percent of our total hits potentially seeing a very blurry video right now:

Once it's set up and the backfill is run, no ongoing engineering or maintenance effort will be required.

Risks

Legal: As far as I know we have not gotten formal legal sign-off on acceptability of MPEG-4 Visual video or AAC-LC audio codecs, but both are believed to be out of patent and their use is consistent with our traditional policy (adopting GIF, MP3, and MPEG-1 and MPEG-2 video/audio when they came out of patent protection).

Tools: A batch run may take time and require some babysitting. The maintenance script requeueTranscodes.php has not been extensively tested under the new kubernetes production maintenance system, and it's known to sometimes get lost when using its --throttle mode which is meant to be self-moderating on enqueuing speed.

Additionally the frontend tool for seeing the state of transcodes on Special:Transcodes is very broken on Commons due to the inefficiently laid out transcodes table, making it hard to review ongoing state.

It may be necessary to perform some cleanup on the maintenance tools before doing a batch run, and that's a whole separate task or two (cf T362123, )