Change Details

**Feature summary** (what you would like to be able to do and where): **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): **Benefits** (why should this be implemented?):

**Feature summary** (what you would like to be able to do and where): Current streaming video tracks for TimedMediaHandler videos are VP9 (good quality/bitrate, compatible with desktop browsers, Android, and newer iOS devices) and Motion-JPEG (terrible quality/bitrate, a single low resolution, but works on older iOS devices back to iOS 10) If we can confirm legal review for MPEG-4 Visual codec (not the newer Advanced Video Codec or h.264 that is in most newer .mp4 files) we can produce iOS 10-compatibile tracks at up to 480p (full NTSC SD quality) at reasonable enough bitrates. The code is ready to go, needing only a configuration added and enabled, but we need to confirm that the patents are expired and no license is required to meet our file format policy. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Many older devices on iOS 10-15 don't include a hardware VP9 codec or don't support it in their older OS, and currently receive the low-resolution Motion-JPEG fallback at a low 144p resolution for videos on Wikipedia on the mobile web or in the app. This is better than nothing and works cleanly, but it noticeably blurry/pixelated. **Benefits** (why should this be implemented?): We can run resolutions at 180p and 240p at lower bitrates than MJPEG and 360p and 480p at higher bitrates, all with much higher visual quality than now. Once set up and backfill run, no additional engineering or maintenance effort will be required.

**Feature summary** (what you would like to be able to do and where): Current streaming video tracks for TimedMediaHandler videos are VP9 (good quality/bitrate, compatible with desktop browsers, Android, and newer iOS devices) and Motion-JPEG (terrible quality/bitrate, a single low resolution, but works on older iOS devices back to iOS 10) If we can confirm legal review for MPEG-4 Visual codec (not the newer Advanced Video Codec or h.264 that is in most newer .mp4 files) we can produce iOS 10-compatibile tracks at up to 480p (full NTSC SD quality) at reasonable enough bitrates. The code is ready to go, needing only a configuration added and enabled, but we need to confirm that the patents are expired and no license is required to meet our file format policy. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Many older devices on iOS 10-15 don't include a hardware VP9 codec or don't support it in their older OS, and currently receive the low-resolution Motion-JPEG fallback at a low 144p resolution for videos on Wikipedia on the mobile web or in the app. This is better than nothing and works cleanly, but it noticeably blurry/pixelated. **Benefits** (why should this be implemented?): We can run resolutions at 180p and 240p at lower bitrates than MJPEG and 360p and 480p at higher bitrates, all with much higher visual quality than now. Once set up and backfill run, no additional engineering or maintenance effort will be required.