Moving to MediaWiki product, as this is not related to the Commons configuration but to the files handling source code.

(In reply to comment #1)

Moving to MediaWiki product, as this is not related to the Commons
configuration but to the files handling source code.

See my comment on bug 43154 : the most general solution may involve a bit of touching the default file-handling code in MediaWiki, but the simplest solution could just involve changing the Commons-specific file-upload interface.

This is a TMH issue. I believe its in the plans for the future. There's probably already a bug for this.

Just a note to say that user Wywin as submitted a GSoC proposal related to this report:

https://www.mediawiki.org/wiki/User:Wywin/mediaConvert

mdale wrote:

Note this is supported in TMH:
https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/Platform_testing

This is mostly an issue of community feature consensuses. The development effort is mostly complete, involves changing the transcodes configuration option and more testing.

Can this be closed out now, or does it need to be repurposed to an 'enable on Wikimedia sites' bug?

I think the original request was to convert the file and throw away the original asset, not to transcode the unfree format. (Not sure if that's a good idea, but I don't think that is what tmh does)

Throwing away original files is never good... I'd give that a solid wontfix.

mdale wrote:

Correct. The TMH implementation for auto conversion does encode webm from MPEG-4, it does not throw away or hide originals.

The request is "Allow MPEG and WMV uploads to Commons: transparently
convert to the preferred free media format and return that as the final file
(and filename extension) on Commons."

The important bit is to allow users to upload videos in non-free formats as opposed to forcing them to do the conversion before uploading.

Implementing this would certainly be a useful new feature for end users.

Unfortunately, if we do this, we will have to deal with a range of new problems:

• We work to encourage creation and sharing of free content. This works well with "free/open formats". If we start to support "priopriatery formats", we will somehow fail to encourage the free/open one.

• We wouldn't store the original file anymore. This would be a switch in the Media handling approach and my feeling: this stinks.

• If we support "propriatery format/codec", we will have to store a re-encoded version of this file (as original file) and for this reason we will systematicaly loose in quality.

• Maintenance work will grow. Assuming, we simply use the ffmpeg, this should be relatively easy to maintain. But, if for some reason, ffmpeg has some "legal problems" with "propriatery formats", then we will be impacted too.

All in one, I'm not convinced at all that this would be a good move. IMO, instead of supporting propriatery technologies, we should continue to improve our documentation, help if we can to improve free tools like for example Firefogg.

Not sure how much it is relevant, but this came under my radar today:

https://devcomo.2013.nodeknockout.com/about

FFmpeg compiled into JavaScript (using Emscripten). Could theoretically transcode whatever file is thrown by the uploader into WebM.

mdale wrote:

impressive, is there anything javascript ~can't~ do ;) p.s I could not get the demos to work but I am sure it could work ;)

We have firefogg.org which somewhat similar to this, and integrated into upload wizard, though it runs as a firefox extention with native ffmpeg rather then cross compiled into javascript ;) Which I am sure a wee bit faster.

It not a good user experience to have to encode in browser before the asset is ingested, we lose archival quality, it take a lot longer time for HD content uploads, and we really don't get around the patent issues per say if you're directly hosting this js file for example.

For those following this bug: https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video

Update: during Wikimania there was discussion among a couple MW devs (thanks, Brion) and Alexis @ the Internet Archive to enable automatic conversion to free formats in something like the following way:

At the upload stage, when detecting a non-free video format

• Ask for basic title/source information
• Inform the uploader that [Commons] does not accept that format because it is non-free, and that the Internet Archive will automatically convert it to a free format.
• Pass the file handle to IA, upload there with the same title & metadata
• Wait for IA's transcoding to finish, grab the URL of the .webm version
• Insert that into the TMH upload and continue.

This would address Kelson's concerns, and the concerns raised in the MP4 rfc. IA stores the original, maintains ffmpeg and related code, and handles the conversion. We include a link back to IA in our file description, to attribute its part in the process and point to the original.

@Sj Interesting new approach. Would be interesting to get a feedback from dev/op people about this approach.

There is now a volunteer developed and maintained service hosted on wmf labs that does all this, with the exception of the transparent part.

https://tools.wmflabs.org/videoconvert/

FYI, we are now doing this via the Schnittserver and Internet Archive. Not ideal, but at least there is a solution.

Super nett. Can you use Schnittserver for mp3 files as well? cf. https://phabricator.wikimedia.org/T45149

There is no need of any special Internet Archive support for this, their conversion facility is open for all. See also https://commons.wikimedia.org/wiki/Commons:Upload_tools#Internet_Archive

Is there a more recent umbrella for this + other conversion issues?

In T45150#4774245, @Sj wrote:

Is there a more recent umbrella for this + other conversion issues?

No. Everything has been derailed by the Commons community's vote. Until the community changes its mind, I'd consider it unlikely that anything more will be discussed, let alone happen.

Revisiting: Still needed. Hooks into the Internet Archive transcoding toolchain don't require a community vote, and is primarily interface sugar in the Uploader, offering a positive option rather than rejecting the uplooad. The IArchive team has repeated their interest in supporting such a flow.