On Fri, Mar 14, 2014 at 11:39 AM, Michael Dale <[email protected]> wrote:
> On Mar 14, 2014, at 12:02 PM, Brion Vibber <[email protected]> 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
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
