good points.... I don't think it would be a _bad_ idea to support server side transcoding it ofcourse gives more flexibility to have the original file and then let us target different output formats in the future. Would let us support camera video uploads etc.
But there are logistical issues. It adds a bit of complexity / cost to the server side setup. Additionally we are interested in working with archive.org who already offers free transcode to ogg from arbitrary uploaded formats for free licensed content. They have 2100+ transcode/storage cpu units and petabytes of storage. Commons has on the order of 40 TB storage and all of (already busy) wikimedias servers together are around 400 units ... It makes sense to encourage long form video contribution to be supported via partnership with archive.org. Especially once we have them integrated as an archive provider. Firefogg ideally is not "complex" for end users. Its a one click extension install, the user does not have to know anything about encoding video. We supply the transcode settings via the javascript api so the settings are identical to what we would request server side. Using an extension also lets us control the upload system so we can have it upload in 1 meg chunks for example. That way we can improve usability around multi hundred meg POST uploads by giving progress indicators, support resumed uploads etc. > Would it be worth providing a simple http-upload to a server-side transcoder > for these relatively small files that are low-quality to begin with? > yes I would support that effort. Just focused on the firefogg stuff right now. If you have time to push forward on this we can try and get something set up. > wouldn't it be more efficient to let > an infrastructure like the one I created encode _all_ versions used for > streaming, whether for desktops or mobile devices, from a single > archival-quality upload? yes, it may be more ideal to just upload the HQ version and have the server do the transcode. Your transcode infrastructure could be very useful for that. But we will have to see how the logistical issues mentioned above play out. peace, --michael _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
