Many H.264 patents expire in 2023-2025.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Stalled | Feature | None | T329258 Enable H.264/MP4 support for Commons uploads and TMH/etc. playback | ||
Open | None | T155320 Implement strict mime type detection and media type inferring of audio/video files | |||
Resolved | • brion | T151352 Ogg Opus-File should be classified as audio not multimedia-Files. | |||
Declined | None | T155523 re-index multimedia files after deployment of ogg filetype detection updates | |||
Resolved | MarkTraceur | T156135 Audio WebM file marked as MEDIATYPE_VIDEO | |||
Resolved | matthiasmullie | T174391 30 Audio WebM files on Commons marked as MEDIATYPE_VIDEO | |||
Open | None | T301807 Two MPG files are audio files, but are classified as video |
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!
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.
@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.
Interestingly there is https://commons.wikimedia.org/wiki/Category:Videos_taken_with_iPhone_X
Note that Chrome is removing support for Theora: https://groups.google.com/a/chromium.org/g/blink-dev/c/qqDdLkeyk7Y/m/ajHePzglAwAJ
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.
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).
*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.