On Fri, Mar 14, 2014 at 11:39 AM, Michael Dale <mdale(a)wikimedia.org> wrote:
On Mar 14, 2014, at 12:02 PM, Brion Vibber
<brion(a)pobox.com> wrote:
I plan to do some research on client-side conversion combined with upload
once I've gotten a little farther on the JavaScript Ogg player (which is
now working pretty well on Safari 6.1/7 and IE 10/11, and I'm experimenting
with Flash-based support for older browsers).
Going client-side means we can use the existing MP4 decoding built into
the operating system or browser, combined with shipping a software Ogg or
WebM encoder. In my preliminary research there's going to be some ugly
tradeoffs, though...
[snip]
I don’t like the idea of an extra encoding pass of all content that
becomes part of the wikimedia archive, I would strongly recommend we work
with a partner to upload the original asset into an archive, and have the
service re-encode an ingest, with a metadata mapping.
*nod* If we end up with a good transcoding partner, that'll obviate the
need for this line of research for basic video uploads. (I might still
experiment with pure Ogg/WebM encoding for generating animations
in-browser, though. I've got all kinds of crazy ideas!)
For the meantime though, client-side transcoding *is* our existing
situation, just with less convenient tools -- anything that gets uploaded
into our system is likely to have gotten re-encoded from MP4 or something
else to Ogg or WebM, and we make all our playback derivatives from that.
Maybe its less exciting then cross-compling an encoder
into javascript ;)
That's for sure! ;)
but we should think long term and work to preserve the
original quality
encodes, and in theory patents will expire, and or we will want to re-encod
into whatever is free and popular at that point in time.
*strongly agree*
For the same reason I'm excited about doing on-wiki editing like the stuff
you prototyped a while ago; that can save a level of transcoding and makes
things more reusable...
ffmpeg has been compiled to JS with a nice little
library<http://bgrins.github.io/videoconverter.js/> package, but
I don’t think its a good idea archive wise. Not to mention this is has much
more patent exposure for the users. Instead of legally hosting two or three
decoders on WMF, or using decoders that are already on users systems, we
would be pushing out patented separate software runtimes for decoders to
thousands of users ? Firefogg was already hosted on a seperate domain for
this reason.
Yes, tools like ffmpeg and VLC are tough for us to use directly for patent
reasons; if we end up shipping anything ourselves for client-side
transcoding it'll have to make use of the system or browser or Flash's
existing video decoding facilities or it's a total no-go. For JS that means
piggybacking on the <video> element and Web Audio API.
-- brion