Page MenuHomePhabricator

Enable H.264/MP4 support for Commons uploads and TMH/etc. playback
Open, Stalled, Needs TriagePublicFeature

Description

Many H.264 patents expire in 2023-2025.

Event Timeline

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

Bugreporter changed the task status from Open to Stalled.Feb 9 2023, 8:31 AM

And H.264 in Matroska or H.264 in mp4 or H.264 in mpeg-ts, and are all these patent free and with which audio profiles, and are those audio profiles also patent free ?

rm uploadwizard tag, as it doesn't care about file support, it just uploads whatever core and TMH allow you to upload.

I would prefer mp4 if possible.

@Yuhong: Could you answer the questions, please?:

And H.264 in Matroska or H.264 in mp4 or H.264 in mpeg-ts, and are all these patent free and with which audio profiles, and are those audio profiles also patent free ?

Which patents at which point?

Answered the first one in recent comments. There is already an issue for enabling AAC.

Yuhong renamed this task from Enable H.264 support for Commons uploads and TMH/etc. playback to Enable H.264/MP4 support for Commons uploads and TMH/etc. playback .Feb 9 2023, 12:13 PM

I wonder if there are any plans at this point.

If there were updates, they would be in this ticket.

I am in no rush to do that one for a couple of reasons, but....

Note that WMF already has webm/VP9 support for all videos (and soon mp4/VP9 hls), so we don't depend on theora (and haven't for a while already). Having said that, native support is useful for direct playback of the original uploads, which I guess will then require people to download VLC media player to do so. It is sad and a bit disappointing, that even something like Chrome is not able to maintain multiple codecs. Just thinking about how much 'original' material in Internet archive and Wikimedia Commons is stored in this format, and the amount of training and demo site that likely still use it.

I know. They even transcode Theora videos to WebM.

I wonder however if this is a good time to make up plans for enabling this though.

It would be pretty trivial to enable H.264 and AAC output, we have all the necessary machinery ready to go for traditonal flat .mp4 files and can very easily add definitions for HLS. AAC may be good to go as far as patent expiration but there's not a big rush to enable it unless H.264 comes along for the ride, and that's still got some time yet.

With VP9 and Opus support in iOS 17 there's much less immediate pressure to enable .mp4 output, though it would be convenient for reuse purposes (some tooling doesn't like WebM or the other original source formats).

There's no change to our support matrix triggered by Chrome dropping Theora support; we don't produce it in transcode output since some years ago, and original input files using it all produce WebM (and, as the HLS support rolls out, HLS-flavored fragmented MP4 tracks).

Though don't forget input as well as output, which is part of why I mentioned AAC.

*nod*; AAC could come in as a standalone .m4a or with MPEG-4 Visual video in .3gp files for instance; we'd need to get legal clearance on both but it should be straightforward to start working towards that (eg, making sure we can selectively check for codecs in an ISO BMFF/MP4/QuickTime-family media file and start allow-listing the ones we don't have a worry about)

In particular smartphone cameras often record in mp4, and support would mean that they would not have to be converted.