On Fri, Mar 14, 2014 at 11:39 AM, Michael Dale <mdale@wikimedia.org> wrote:
On Mar 14, 2014, at 12:02 PM, Brion Vibber <brion@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 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