I've been testing Ogg and WebM video playback on my various iOS devices <https://github.com/brion/OGVKit> in prep for adding playback support to the Wikipedia iOS app. Here's a few notes on our infrastructure: *Bandwidth* Bandwidth usage for 360p transcodes may be a bit tight for flaky 3G networks, but the only lighter transcode we have is a tiny tiny 160p. - Recommend adding a 240p transcode step with intermediate bandwidth. *Frame rate* 60fps/50fps source files get transcoded at the same framerate; this means limited bandwidth is spent on extra frames instead of picture quality, and 60fps playback can be heavy on CPU usage for slower computers and mobiles. - Recommend decimating >=48fps to half the frame rate on transcodes. Sometimes you want the 48/50/60fps, but usually it seems unnecessary and things are just being transcoded from high-quality source material. Examples of gratuitous 60fps: - https://commons.wikimedia.org/wiki/File:Wiki_Makes_Video_Intro_4_26.webm - https://commons.wikimedia.org/wiki/File:Hamilton_Mixtape_%2812_May_2009_liv… - https://commons.wikimedia.org/wiki/File:Big_Buck_Bunny_4K.webm *Seeking performance with Ogg audio* The Ogg format is kind of weird in that it's really designed more for live streaming than for encoding a fixed-length sequence. Part of that legacy is that by default, seeking to a particular time within a file requires doing a bisection search -- you jump around to byte positions in the file, sync up the decoder, and check if you have to go up or down. This is really hard on latency over the internet, especially on mobile networks or on far-flung continents. - Recommend transcoding/remuxing all Ogg audio and adding skeleton index. Ogg files can contain an optional index in a 'skeleton' track, which we include by default on all our Ogg Theora *video* transcodes -- this makes seeking much faster, as the player knows the byte positions of various times in the file to start with. Currently, TimedMediaHandler only produces Ogg transcodes if the original file was not Ogg Vorbis to begin with (eg, if it was a WAV file or Ogg using FLAC encoding or something). It should be easy to tweak that logic to always produce a transcode, and make sure we include skeleton tracks on audio output too. *API* The videoinfo query in the API can be used to get a list of transcodes, but it feels very icky to use, and of course is totally bound to MediaWiki. - Recommend exposing sources list as an MPEG-DASH manifest file that can be passed directly into a DASH-supporting WebM-supporting player. Need to research this one further; documentation seems wonky on the format. -- brion