On Mar 14, 2014, at 12:02 PM, Brion Vibber <[email protected]> wrote: > On Fri, Mar 14, 2014 at 12:29 AM, Samuel Klein <[email protected]> wrote: > Thank you, Fabrice. Is any followup to the earlier RfC planned, > regarding converting mp4-to-ogg on upload? > > As Gilles mentioned, based on the RfC results we don't currently have a > server-side solution on the table. > > 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... > > Possibilities are basically: > > 1) in-browser JavaScript and/or Flash: no installation required, but likely > slow. Probably would only work on desktop (assuming my prelim research is > correct and it's doable at all!) > > 2) OS & browser-specifc extension or plugin (similar to Firefogg): requires > one-time installation. Not possible for mobile, and historically it's not > been easy to get people to install Firefogg. I don't really want to go down > this road as there's a potential combinatorial explosion of things to support. > > 3) OS-specific native helper app: requires one-time installation. Desktop is > doable; should be workable but slow on mobile. Requiring installation may be > a stopping point for many users.
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. Maybe its less exciting then cross-compling an encoder into javascript ;) 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. 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. Thinking ahead, Imagine ORBX.js gains acceptance or Apple buys into Daala, as it delivers on the improvements they are targeting. We would then have 3 passes on all content, getting pretty distant from the H.264 captured by the device. We are not dealing with mezzanine files, devices already have relatively aggressive low bitrates on consumer captured video assets. The user should upload the source asset, the server should do the encoding. Internet archive would be a good partner. —michael
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
