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
Hi, Multimedians.
I've been talking with our new multimedia team, we're just getting to the point
where we have a really good idea of where we want to go after a little while
of doing work mostly on existing issues and refactoring efforts, and I have
a small announcement to make.
In the next few months, we intend to work on pulling upload API logic into core,
and writing a new interface for uploading files from VisualEditor. Our initial
plan involved refactoring UploadWizard to a point where including it in VisualEditor
would not be difficult, but our new plans include usability improvements that,
in my opinion, would unnecessarily enmire our work. Our team will be submitting
patches to OOJS-UI, MediaWiki Core, and VisualEditor itself in an effort to get
this project off the ground, as well as tweaking configuration settings in mw-config
and generally running around looking for code review.
Rest assured, we intend to maintain our commitment to fixing bugs in UploadWizard
as they come up, as well as bugs in the myriad other Multimedia projects. Please
continue to bother the Multimedia team if and when things go wrong, we are always
happy to help you, or at least point you in the right direction.
Here is a rough roadmap of where we need to go in the next few months:
# mw.Api.plugin.upload API to automatically detect what methods are available for the browser, take a File object or file input, and perform the upload
## Base upload API with simple API call, quick and dirty, with gadget proof-of-concept https://phabricator.wikimedia.org/T103397?workflow=create
## Expand to use File API where available https://phabricator.wikimedia.org/T103398
## Expand to support stashing with appropriate continue-upload API https://phabricator.wikimedia.org/T103399
## {{stretch}} Expand to use chunked uploading where available https://phabricator.wikimedia.org/T103398
# Tie together all of those things into an Upload object or similar in core, so we can handle it with relative ease in our mostly-UI extension
## Create Upload model API in core https://phabricator.wikimedia.org/T103413
### Base functionality - use the new upload API to upload a file, configurable to use stash
### Base functionality - finish stash upload
### Base functionality - set file description page text for upload (to be used in finish-stash call, or in initial upload if no stash option passed in)
# Upload OOUI widget can then just use all of those things, and it can live in VE instead of having to be across a couple of extensions.
## Create upload widget in VE https://phabricator.wikimedia.org/T91717 {{epic}}
### Upload inspector
### File input widget in OOUI {{done}}
### Take file from widget, use upload API in core to stash
### Description/licensing/category form
### Emit finished upload from widget
## Use upload widget for inserting files into VE https://phabricator.wikimedia.org/T91717 (new task?)
### Add upload widget as above
### Use emitted file to construct thumbnail (file API?), caption (based on description)
## Drag-and-drop https://phabricator.wikimedia.org/T40031
## Copy-paste https://phabricator.wikimedia.org/T39932
--
Mark Holmquist
Lead Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
One of the reasons we've always worried about using the open Ogg and WebM
formats on iPhones and iPads is that we don't get to make use of the
hardware MP4/H.264 codec... using the main CPU cores is presumed to drain
the battery faster.
I've done a first-pass test measuring energy usage of native-code WebM/Ogg
playback using the new energy reporting in the Xcode 7 / iOS 9 beta:
https://brionv.com/log/2015/06/19/webm-and-ogg-energy-usage-on-ios-9-beta-w…
The good news is that playback of buffered data at my target resolutions
(360p for 32-bit, 720p for 64-bit) is barely under the "Low" mark on the
energy drain meter! :D
The bad news is that H.264 playback with the native widget reports
post-buffer-download energy drain even lower, at the "Zero" mark... if you
can believe that!
(In both cases, reported drain is significantly higher during network
download, at least on my fast wifi.)
But "Low" sounds pretty good... If folks would like to see more concrete
measures, I can rig up my test to run continuously until the battery runs
out and time it.
-- brion
I've been passing the last few days feverishly working on audio/video
stuff, cause it's been driving me nuts that it's not quite in working shape.
TL;DR: Major fixes in the works for Android, Safari (iOS and Mac), and
IE/Edge (Windows). Need testers and patch reviewers.
*== ogv.js for Safari/IE/Edge ==*
In recent versions of Safari, Internet Explorer, and Microsoft's upcoming
Edge browser, there's still no default Ogg or WebM support *but* JavaScript
has gotten fast enough to run an Ogg Theora/Vorbis decoder with CPU to
spare for drawing and outputting sound in real time.
The ogv.js decoder/player has been one of my fun projects for some time,
and I think I'm finally happy with my TimedMediaHandler/MwEmbedPlayer
integration patch <https://gerrit.wikimedia.org/r/#/c/165478/> for the
desktop MediaWiki interface.
I'll want to update it to work with Video.js later, but I'd love to get
this version reviewed and deployed in the meantime.
Please head over to https://ogvjs-testing.wmflabs.org/ in Safari 6.1+ or IE
10+ (or 'Project Spartan' on Windows 10 preview) and try it out!
Particularly interested in cases where it doesn't work or messes up.
*== Non-JavaScript fallback for iOS ==*
I've found that Safari on iOS supports QuickTime movies with Motion-JPEG
video and mu-law PCM audio <https://gerrit.wikimedia.org/r/#/c/217295/>.
JPEG and PCM are, as it happens, old and not so much patented. \o/
As such this should work as a fallback for basic audio and video on older
iPhones and iPads that can't run ogv.js well, or in web views in apps that
use Apple's older web embedding APIs where JavaScript is slow (for example,
Chrome for iOS).
However these get really bad compression ratios, so to keep bandwidth down
similar to the 360p Ogg and WebM versions I had to reduce quality and
resolution significantly. Hold an iPhone at arm's length and it's maybe ok,
but zoom full-screen on your iPad and you'll hate the giant blurry pixels!
This should also provide a working basic audio/video experience in our
Wikipedia iOS app, until such time as we integrate Ogg or WebM decoding
natively into the app.
Note that it seems tricky to bulk-run new transcodes on old files with
TimedMediaHandler. I assume there's a convenient way to do it that I just
haven't found in the extension maint scripts...
*== In progress: mobile video fixes ==*
Audio has worked on Android for a while -- the .ogg files show up in native
<audio> elements and Just Work.
But video has been often broken, with TimedMediaHandler's "popup
transforms" reducing most video embeds into a thumbnail and a link to the
original file -- which might play if WebM (not if Ogg Theora) but it might
also be a 1080p original which you don't want to pull down on 3G! And
neither audio nor video has worked on iOS.
This patch <https://gerrit.wikimedia.org/r/#/c/217485/> adds a simple
mobile target for TMH, which fixes the popup transforms to look better and
actually work by loading up an embedded-size player with the appropriately
playable transcodes (WebM, Ogg, and the MJPEG last-ditch fallback).
ogv.js is used if available and necessary, for instance in iOS Safari when
the CPU is fast enough. (Known to work only on 64-bit models.)
*== Future: codec.js and WebM and OGVKit ==*
For the future, I'm also working on extending ogv.js to support WebM
<https://brionv.com/log/2015/06/07/im-in-ur-javascript-decoding-ur-webm/>
for better quality (especially in high-motion scenes) -- once that
stabilizes I'll rename the combined package codec.js. Performance of WebM
is not yet good enough to deploy, and some features like seeking are still
missing, but breaking out the codec modules means I can develop the codecs
in parallel and keep the high-level player logic in common.
Browser infrastructure improvements like SIMD, threading, and more GPU
access should continue to make WebM decoding faster in the future as well.
I'd also like to finish up my OGVKit package
<https://github.com/brion/OGVKit> for iOS, so we can embed a basic
audio/video player at full quality into the Wikipedia iOS app. This needs
some more cleanup work still.
Phew! Ok that's about it.
-- brion
I have revived the WebP upload patch:
https://gerrit.wikimedia.org/r/#/c/95872/ <https://gerrit.wikimedia.org/r/#/c/95872/>
It’s been stale for like 2 years, but I think we can easily get this deployed.
We would need a review by Chris perhaps
It’s a bit incomplete in the metadata support, but we don’t really need that initially as far as I’m concerned.
DJ
Hi multimedia people!
I was wondering if there was any post-hackathon follow up with the
flickrupload work that happened? Anything interesting/fun coming down
the pipe there?
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |