Cryptograss:Video player decisions
Two decisions about the video player, written for Justin, September 2026. Sky asked for them in one place rather than scattered across pickipedia#111.
Nothing here is urgent and nothing is half-finished: the selector is built and tested, and the structural change is optional. Both are waiting on a call, not on work.
Decision 1: ship the quality selector?
Every video now publishes as four streams — 1080p, 720p, 360p and audio-only — but nobody can choose between them. The player picks by bandwidth. That means the audio-only stream, the one added for campground connections, cannot be reached deliberately.
The selector is a row of buttons under the player: Auto | 1080p | 720p | 360p | Audio only. The choice is remembered per viewer, so picking "Audio only" on a tether holds for the evening rather than for one video. Renditions are named by the short side of the picture, so an upright phone video reads 1080p, not 1920p.
Tested in a headless browser against a real published release:
buttons : Auto | 1080p | 720p | 360p | Audio only default : Auto after 360p : 360p playing at t=7.5 (switch mid-playback, no reload) after audio : Audio only stored=Audio only after reload : Audio only (remembered) page errors : none
The catch
To make the buttons work in Chrome, the player has to change which engine it uses.
The code asks the browser "can you play HLS?" and uses the browser's own player if it says yes. That was written on the assumption that only Safari says yes. Chrome answers "maybe" as well — confirmed in a headless Chromium, which both claims support and plays these streams. So Chrome has been using its built-in player all along, and that path hides the list of renditions from the page: no selector is possible, and playback errors can only be guessed at.
The fix is to prefer hls.js (the library already loaded) wherever it works, and fall back to the browser's own player otherwise, which still covers iOS Safari. Through hls.js the page can see the ladder, offer the choice, and tell a decoder failure apart from a missing file.
This changes how every viewer plays video, not only the new buttons. That is the part worth a deliberate yes.
- If yes
- One paste, and the buttons appear. Playback moves to hls.js for Chrome and Firefox; Safari on iOS is unaffected.
- If no
- The selector can be limited to browsers already using hls.js — but that is mostly Firefox, so most viewers would never see it, and the audio-only stream stays unreachable for them.
The file is ready at User:Magent/Common.js proposal — 742 lines, md5 6b8f497226ac633c9efee1886b1fd58a, passing a syntax check, and byte-identical to the copy that was tested.
Decision 2: move the player out of MediaWiki:Common.js?
This one is about how the code gets deployed, not what it does.
The video player lives in MediaWiki:Common.js — a wiki page, not a file in the repository. Every change means a person copying several hundred lines into a text box. That has three consequences:
- No review, no tests, no CI. A change is live for every visitor the moment it is saved.
- It has already broken. On 15 September the site's JavaScript was down for 23 minutes — every video player, the block-height widgets, the forms — because the copy was taken from a view that escaped some characters. The fault was in the handoff, not the code.
- No history alongside the code it belongs to. Page history exists, but it sits apart from the repo, the PRs and the deploys.
The alternative is to move the player into the PickiPediaReleases extension, where it becomes an ordinary file in the pickipedia repo, loaded as a ResourceLoader module. Then it ships the way everything else does: a PR, CI, Jenkins. The quality selector would simply be a PR on top.
- Cost
- Roughly half a day. Move the player code, register the module, delete the copy from Common.js.
- Risk
- It changes how every page loads its player, so it wants a real browser check on a Release page, a jam page and a draft page before it counts as done. Unlike a paste, all of that is testable in advance.
- If not done
- Everything keeps working. It just means every future player change is another hand-paste, with the same failure mode available each time.
Recommendation
Yes to both, in the order 2 then 1. Do the move first and the selector arrives as a reviewable PR, making the September 15 paste the last one. If only one is wanted, take the selector — the ladder is half-delivered without it.
If the answer is "not now", nothing is lost. The selector sits on its wiki page, and the player keeps working exactly as it does today.
See also
- pickipedia#111 — the issue this came from, with the test output
- Cryptograss:Video encoding pipeline — what the four streams are and why AV1
- User:Magent/Common.js proposal — the file itself
