On Sat, Jan 27, 2024 at 12:57 PM Erik Moeller <eloque...@gmail.com> wrote:
> On Tue, Jan 23, 2024 at 11:44 AM Brion Vibber <bvib...@wikimedia.org> > wrote: > > 1) Overturn the requirement to avoid handling h.264 files on Wikimedia > servers or > > accept them from users or serve them to users. Allow importing h.264 > uploads > > and creating h.264 transcodes for playback compatibility. > > The last RFC [1] will reach its 10 year anniversary in February, so I > think it would be reasonable to re-engage with the (Wikimedia-wide) > community if anything about the current policy should change. > Personally, I continue to be in favor of Wikimedia transcoding > uploads, as long as WMF doesn't end up paying licensing fees to the > video patent monopolists. *nod* What's changed over the last 10 years? Looking at Commons:Video, it > currently says: > > > The preferred video format is VP9 video in the WebM container, but Theora > > video in the ogv container and VP8 or AV1 video in the WebM container are > > also allowed. > > So at least it looks like there are now new royalty-free formats that > are widely supported in browsers, right? > We have playback covered reasonably well and it's getting better because our old "frenemies" at Microsoft and Apple are now pulling their weight for universal compatibility. They are both members of the industry consortium pushing the royalty-free AV1 codec and have both adopted VP9 as its predecessor bridge codec. :) Allowing us to create MP4 h.264/AAC output in limited resolutions would increase compatibility with older iOS devices and other "funky" browsers, but we don't "need" it for the latest devices. Reuse is more problematic. If you download our VP9 WebM or MP4/HLS playback derivatives, or a WebM, Ogg, or MPEG-1/2 source file, many other sites and tools won't take them because they expect MP4s with h.264 or HEVC. Can you save the video to your camera roll? Repost it? Edit it in your video editor of choice? Maybe, maybe not. Manual conversion will take time and requires extra effort. Note that h.264/AVC and HEVC are both international standards but not open standards, and they both have active patent pools and require licensing to produce and distribute an encoder or decoder. I'll leave it to a future consultation to figure out what that means to us, users of Debian's ffmpeg package. ;) Allowing us to create MP4 h.264/AVC output could increase ease of use / compatibility for reusers. Contributing is also more problematic, because most modern cameras and editing tools produce H.264 or HEVC video in some flavor of MP4 container by default. We accept some old formats (MPEG-1 and MPEG-2 and Ogg Theora) and some weird formats (WebM with VP8 or VP9) but not the actually commonly used ones. This means almost every video upload is recoded by the uploader, either manually or through a tool. This reduces the quality of the stored file and the subsequent playback derivatives, and gives another opportunity to massively mis-estimate bitrate and produce a very bad quality stored file by accident that cannot be fixed by anyone else (this happens a lot). > Is there anything that can be done to expand the server-side format > support further without changing Wikimedia's stance on patents? For > example, should Wikimedia Commons support additional container formats > or codecs that are royalty-free or whose patents have expired? > The only functional change we need is to enable uploading .mp4 and .mov files with the h.264 video and AAC-LC audio codecs. (And optionally HEVC if it's not problematic). Without reinterpreting or changing the policy, I think we're not meant to be *using* the h.264 or HEVC codecs in ffmpeg, even though it's in our Debian installations. This means our only hopes for ingesting common video files are reevaluating the policy or doing a Rube Goldberg machine where we transcode client-side using hardware codecs via Web Codecs. ;) While that would be a fun project, it shouldn't be necessary IMO. Container formats are not a problem; everybody ships MP4/ISO BMFF muxer/demuxer code without a second thought about patents. We're even producing MP4 files for HLS playback tracks for iOS (with free codecs inside). Allowing *ingestion* of MP4 h.264/AAC would allow uploading camera originals from most consumer gear -- a major democratizing feature.Ingestion of MP4 HEVC/AAC would give more compatibility. In both cases we have all the software we need, we already use the Debian ffmpeg package which includes code supporting both formats; we just don't allow uploading the files, reading them to convert for playback, or downloading the originals from our web site. Do we need a MPEG-LA patent license for that? Nobody seemed to think so in 2014 but nobody could tell me for sure either, then or now. We'd also have to make the choice of whether distributing the files as originals is somehow violating a patent or if nobody cares about distribution of files encoded by someone else. Nobody knew for sure what that meant in 2014 under different license agreements but we were pretty sure we wouldn't have to pay anything, even though we put the idea of getting the license to a vote. Again though, if we do this we need to think seriously about providing better management tools for reviewing large/long uploads (long video, audio etc) as I keep hearing people say "please don't make it easy to upload video, then we'll have to review more uploads and we don't have the human time available to dedicate to it". -- b
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/5TY4CMP4XLM6NNIG3STSBRKHG4A5S62U/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
