Forgot your password?
typodupeerror
Media Open Source Wikipedia

FLOSS Codecs Emerge Victorious In Wikimedia Vote 235

Posted by Soulskill
from the quest-for-internal-consistency dept.
An anonymous reader writes "Michael Maggs from the Wikimedia Foundation's multimedia team has given a final summary of the discussion and vote about whether to support MP4 video or not. Twice as many people voted against adding MP4 to Wikimedia than voted for full support. Now they can get back to their mission of advocating openness. 'Those opposing MP4 adoption believe that in order for what we create to be truly free, the format that it is in also needs to be free, (else everyone viewing it would need to obtain a patent license in some form to be able to view it). ... From that viewpoint, any software infrastructure in Wikimedia projects must adhere to community norms regarding intellectual property, patent status, licensing or encoding methods. Current community requirements are that free/open standards should be used at all times to encode and store video files on the servers that house our data, so that both our content and software can be redistributed without any restrictions. Proprietary video containers or codecs such as MP4 are not allowed on Wikimedia projects because they are patent-encumbered and their software cannot be re-licensed freely (though MP4 content can be freely re-licensed).'"
This discussion has been archived. No new comments can be posted.

FLOSS Codecs Emerge Victorious In Wikimedia Vote

Comments Filter:
  • Proprietary video containers or codecs such as MP4 are not allowed on Wikimedia projects because they are patent-encumbered and their software cannot be re-licensed freely (though MP4 content can be freely re-licensed).

    Is that true? What does he mean by "re-license" in relation to the content of an MP4? (Or maybe I should ask what he means by "content".)

    How does the MP4 codec have anything to do with the license regarding the content of an MP4 file?

    • by Zocalo (252965) on Saturday February 15, 2014 @07:16PM (#46256777) Homepage
      Just what it sounds like. You can produce an MP4 and license the video itself (the "content") under a free license like Creative Commons, but the software required to play back that CC licensed video content is patent-encumbered and cannot be freely re-licensed.
      • Re: (Score:3, Insightful)

        by Anonymous Coward
        To be fair, you cannot freely re-license any open source codecs either - at least not without contacting all of the folks who contributed to the project and getting their OK on a different license. If the license is currently GPL3 and you want to re-license to Apache - good luck with that.
      • by PopeRatzo (965947)

        OK, thanks.

  • Mobile devices have efficient hardware support for codecs like H.264, and using something else takes a toll on battery life.

    • by amiga3D (567632) on Saturday February 15, 2014 @07:23PM (#46256811)

      Freedom isn't free.

    • by Immerman (2627577) on Saturday February 15, 2014 @07:46PM (#46256949)

      And?

      Wikimedia is concerned (IIRC) with building a library of content that freely accessible and sharable in perpetuity, I'd say that mission trumps catering to current-gen device users. How many hours per day did you say you spent watching wikimedia videos on your phone? The device manufacturers are after all free to implement hardware decoders for open codecs as well, and unlike H.264 they don't even need to pay any royalty fees to do so.

      • The device manufacturers are after all free to implement hardware decoders for open codecs as well, and unlike H.264 they don't even need to pay any royalty fees to do so.

        The thirty H.264 licensors are for the globally dominant players in digital video and so are paying royalties to themselves. We are talking pennies or fractions of a penny per unit here for a cartel the size of Mitsubishi.

        There is an enterprise cap on H.264 royalties.

        There are 1,300 H.264 licensees --- each fabulously wealthy in their own right --- and each with a commitment to H.264 that extends far beyond the web.

        AVC/H.264 Licensees [mpegla.com]

        The numbers game:

        Disney's Frozen "Let It Go" Sequence Performed by Id [youtube.com]

        • If Android requires it as a supported format you can bet the SOCs will start having support for it. In fact several already do. Then there is the fact that as GPUs become programmable the hardware codec support ends up being a piece of firmware which could be done for another codec by a software programmer with access to the hardware specs.

    • by evilviper (135110)

      The hit isn't a very big one:

      "with the hardware offload the battery lasted up to 36% longer"

      http://blog.webmproject.org/20... [webmproject.org]

      And with each faster processor generation, the difference gets smaller and smaller still.

      • 36% is a pretty big difference, especially when streaming video by the hour.

        • by evilviper (135110)

          That was the max, not typical/average, and I seriously doubt the average user will notice. Yes, it makes a difference if you're watching movies non-stop while taking a long flight, but people generally don't take just enough battery power along to squeak by, so the difference won't register too much.

      • by N Monkey (313423)

        The hit isn't a very big one:

        "with the hardware offload the battery lasted up to 36% longer"

        http://blog.webmproject.org/20... [webmproject.org]

        And with each faster processor generation, the difference gets smaller and smaller still.

        Followed the link but couldn't see where it showed actual power consumption of the hardware decoder they used (their own I guess?) but given that an ARM CPU might consume around 500mW [virginia.edu] whereas an H.264 hardware decoder doing HD uses 10mW [imgtec.com], either the screen is using a huge amount of power or their hardware leaves a bit to be desired.

        • by evilviper (135110)

          Followed the link but couldn't see where it showed actual power consumption of the hardware decoder they used (their own I guess?)

          You have to follow one whole link to find out:

          "The logic consumes less than 25 milliwatts of power for 1080p video decoding and less than 5 milliwatts for 480p (TSMC65nm LP)"

          either the screen is using a huge amount of power

          That has ALWAYS been the case, and I don't know why you're surprised. Back to the very first laptops, back-light power draw absolutely dominates power consump

  • by ciaran_o_riordan (662132) on Saturday February 15, 2014 @07:16PM (#46256773) Homepage

    There was an initial surge of pro-mpeg votes by people connected to the WikiMedia Foundation and the technical team which would have been implementing it, then there were many days of mostly anti-mpeg voting when normal Wikipedia contributors heard about this idea.

    As someone who has been campaigning for many years against software patents, it was very encouraging to see that the general Wikipedia populous (i.e. after the initial pro-mpeg surge from employees and pre-briefed technicians) was two-thirds against the use of patented formats.

  • by msobkow (48369) on Saturday February 15, 2014 @07:20PM (#46256797) Homepage Journal

    The whole issue is about idealism, not practicality. In practice, MP4s are available on pretty much any device.

    Unfortunately, that idealism is shooting wikimedia in the foot, because there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos.

    So in their zeal to pursue "openness", they've closed the doors on the people who matter most: the users.

    • by amiga3D (567632) on Saturday February 15, 2014 @07:26PM (#46256827)

      That availability comes at a price. It's almost impossible for a truly open piece of hardware to compete so we get locked down hardware in return for using proprietary codecs. You are right, it does come down to ideology and as I often say most people don't really want to be free as long as they can live in a golden cage.

    • The whole issue is about idealism, not practicality.

      What is practical about freedom?

    • by Vanders (110092) on Saturday February 15, 2014 @08:14PM (#46257077) Homepage
      The users are exactly the people they're thinking about. Because in ten years time, it's the users who'll be happy not to deal with some proprietary closed format that isn't supported on their new device, because sadly it's obsolete and no one cares about Intel Indeo, oh sorry, I mean, MPEG-2, oh wait, I mean, h.264. They care because by using an open format they stand a chance of providing support to the latest iBrain 7, without having to destroy the content with yet another lossy conversion.

      Of course if your outlook is limited to the short term of less than the next 12 months then I guess the decision looks bad, but then you're not thinking about the long game.
      • Re: (Score:3, Insightful)

        by Guspaz (556486)

        What makes you think the terribly performing FLOSS codec of the day will be more likely to be supported in the future than today? You'll probably find the FLOSS codecs are just as poorly supported in the future as they are now.

        There are a few exceptions, where the FLOSS codecs are really quite good; Xiph has done some great things with speech codecs, for example. But Theora and VP8 are terrible, and VP9 doesn't even match h.264, let alone h.265...

        • by Vanders (110092) on Saturday February 15, 2014 @09:24PM (#46257359) Homepage

          the terribly performing FLOSS codec of the day

          I'm not sure which codec you're referring too, so I can't answer you there.

          I guess my optimism is based on WebM being an open format, thus allowing anyone to implement it on any future platform. Unlike various proprietary formats, that won't. I mean, does your 'phone support Intel Indeo or RealPlayer G2?

          VP9 doesn't even match h.264, let alone h.265

          That's really odd, because the benchmarks I've seen show VP8 & h264 to be evenly matched, and no one has produced a finished h.265 or VP9 codec, so I do wonder how you think you've seen those two codecs fairly benchmarked?

          • I guess my optimism is based on WebM being an open format, thus allowing anyone to implement it on any future platform. Unlike various proprietary formats, that won't. I mean, does your 'phone support Intel Indeo or RealPlayer G2?

            H.264 is also an open format in a sense that Indeo etc never were - it has a public specification, and it has complete open source implementations. The only thing that's not open it are the patents, but "in ten years time" they won't be in force anymore.

          • by Guspaz (556486)

            I'm particularly referring to VP8, which Google likes to claim is equivalent to h.264, but in reality it produces dramatically inferior results. The last benchmarks I had looked at showed VP8 requiring about twice the bitrate to achieve comparable quality, although that was a few years ago, so it's possible that the situation has improved. The only real advantage it had was being royalty-free, but that only came about because Google paid for the patent licenses after getting sued for patent infringement.

            As

        • by symbolset (646467) * on Sunday February 16, 2014 @12:16AM (#46257943) Journal
          VP9 is going to be supported for both encode and decode on the next generation of chipsets and devices from ARM, Broadcom, Intel, LG, Marvell, MediaTek, Nvidia, Panasonic, Philips, Qualcomm, RealTek, Samsung, Sigma, Sharp, Sony and Toshiba [techcrunch.com]. That's a long list of heavy hitters. Maybe they know something you don't.
    • by evilviper (135110)

      there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos.

      There are fleetingly few of those... WebM support has gotten pretty pervasive. Chrome & Firefox have had it built-in for quite a while, as does Android, and more. In addition, there are native JAVASCRIPT decoders for Vorbis, Theora, and VP8, which could be used for any platforms that lack support, at merely a performance penalty.

      Nobody is getting shot "in the foot" here.

      • by epyT-R (613989)

        Native javascript? Now there's an oxymoron.. 'Native' means native machine language. Javascript is interpreted bytecode at best. While writing a video decoder in it might be possible, it'll run terribly on anything but the most powerful desktop cpus, and you can forget about anything over 640x480.

        • by evilviper (135110)

          it'll run terribly on anything but the most powerful desktop cpus

          Be sure to spout-off lots of generalizations and pointless guesses, because that helps a lot...

          Let's see... My 6 year old, single-core CPU manages real-time decoding of D1 video. But hey, you said it won't work, so I must have completely imagined it.

    • by wagnerrp (1305589)
      It's a double edged sword. While some users are going to be alienated, some users are going to try to figure out why they cannot play the content, and thus learn the issues surrounding licensing and the decision to use open (unchallenged) formats.
    • The whole issue is about idealism, not practicality. In practice, MP4s are available on pretty much any device.

      Unfortunately, that idealism is shooting wikimedia in the foot, because there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos.

      So in their zeal to pursue "openness", they've closed the doors on the people who matter most: the users.

      When I was first starting to use Linux, I tried many distributions, but settled on Debian and Ubuntu.

      When I was setting up my desktop, I found Debian incredibly inconvenient. I wanted Java, and Flash... there were a great many compromises that I wanted to make, and Debian made those compromises a real pain in the ass. Ubuntu was perfect, it let me make all those compromises by simply clicking a button.

      But I didn't use it on the server when I was doing development. When I was doing development, I realized

    • by Ruedii (2712279)

      WebM codecs such as VP8 and VP9 are also supported on nearly every device. W3.org, Google and the companies supporting ARM have put their full force behind the VPx codecs, and thus the WebM container format. Every Chrome and Firefox user can view it, and if you have device without browser support, you can download either a third party browser such as Firefox or the wikipedia app for most devices, and that will support it.

      Support for WebM codecs is very widespread. As of companies backing VP8 and VP9, th

    • there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos

      Google Chrome supports if by default. Which kind of platform are you using anyway?

    • by sjames (1099)

      They have a much better chance of installing an open codec than someone with a free codec only device has of installing a proprietary codec.

      Nobody has had the door closed on them.

  • My question is unrelated to wikimedia, but this seems like the right place to discuss the alternatives to h264/mp4.

    I often have to encode videos to send to a few people. Most are computer-illiterate, and it needs to "just work". So I use H264 in Quicktime .mov, because most users have Macs, and those who have Windows definitely have Quicktime installed. I guess .m4v might also work as a container, except it doesn't have a timecode track.

    But for the codec, is there a realistic alternative to H264 today? A fo

    • Re: (Score:3, Informative)

      by wiredlogic (135348)

      and those who have Windows definitely have Quicktime installed.

      Quicktime on Windows is a steaming turd along with its redheaded stepchild iTunes. I definitely don't have it installed. If you can't be bothered to use a 21st century cross platform container format I'll gladly skip watching your video.

      • by rduke15 (721841)

        You are obviously not one of the people who needs to work with these videos, but I'm still interested in learning which "21st century cross platform container format" you would recommend, that anyone and their uncle is able to open (without calling me on the phone first).

        I don't like QT much either, but what else can play back ProRes and H264, move frame-by-frame (including backwards), and display timecode and frame numbers?

        • Just use MP4. That is the standard container for H264 AVC. If you want something fancy use MKV. MKV support is required in order for a video decoder to have the DivX logo on it so even standalone players usually support it. Quicktime is awful. Not the container format but the player software. Like the other guy said its a steaming pile of crap. Especially on Windows.
           

    • by evilviper (135110) on Saturday February 15, 2014 @08:03PM (#46257023) Journal

      But for the codec, is there a realistic alternative to H264 today? A format which can fit a feature-length HD movie in high quality in a file under 4GB so that it fits on any USB stick including FAT32, and that anyone can read?

      WebM is certainly better than QuickTime's H.264 encoding quality. That's VP8 with Vorbis audio in an MKV container.

      Oddly enough, your best bet for playback is to use the <video> tag to embed it in a web page. Both Firefox and Chrome natively support WebM, as of quite a while back. Internet Explorer never will, but their market share is dwindling, and all those users need for playback is to install the codec pack first: https://tools.google.com/dlpag... [google.com]

      If you want to keep it on QuickTime, there are QT components to support WebM, though I can't speak to their quality: https://code.google.com/p/webm... [google.com]

    • by tlhIngan (30335)

      I often have to encode videos to send to a few people. Most are computer-illiterate, and it needs to "just work". So I use H264 in Quicktime .mov, because most users have Macs, and those who have Windows definitely have Quicktime installed. I guess .m4v might also work as a container, except it doesn't have a timecode track.

      But for the codec, is there a realistic alternative to H264 today? A format which can fit a feature-length HD movie in high quality in a file under 4GB so that it fits on any USB stick i

    • by rts008 (812749)

      ...and those who have Windows definitely have Quicktime installed.

      No. Not only NO, but HELL NO!

      Real friends don't inflict Quicktime on their friends that use Windows.

      Quicktime on Windows is and always has been a putrid, steaming, stinking pile.
      I have not had Quicktime on any of my computers since I discovered VLC back in 1998.

  • They are only accepting Vorbis/FLAC audio, Theora video, in ogg containers? Or is everything good as long as the container isn't proprietary?

    • Re:This means (Score:5, Informative)

      by evilviper (135110) on Saturday February 15, 2014 @07:55PM (#46257005) Journal

      They are only accepting Vorbis/FLAC audio, Theora video, in ogg containers?

      You seem to be a few years behind the times... WebM is perfectly FLOSS, and much improved.

      For lossy audio, in addition to Vorbis, there is the much better Opus codec. FLAC is the standard for lossless, as there isn't much room for improvement.

      For video, VP8 (and soon, VP9) are vastly superior to Theora.

      And WebM uses the MKV container... not the horrific Ogg.

      Most web browsers support WebM... Chrome/Chromium and Firefox/IceWeasel have support built-in, though the later is lagging a bit behind on VP9/Opus. And IE users can play WebM videos by just installing the codec pack.

      The "Video Without Flash" add-on for Firefox will allow you to watch all videos on the most popular video sites in native/WebM format. Not only does this help those who can't get Flash, but also native WebM playback is vastly less resource intensive and far more responsive.

  • Thin. (Score:5, Informative)

    by westlake (615356) on Saturday February 15, 2014 @07:35PM (#46256881)

    For information only, the raw, unadjusted, uncorrected figures were:

    Prefer full MP4 support: 145
    Prefer partial MP4 support - viewing only: 4
    Prefer partial MP4 support - contributions only: 56
    Neutral: 7
    Prefer no MP4 support: 309

    Total 521

    Is the function of a resource like the Wikipedia to serve its larger audience or its ideological purists?

    If you know anyone who cannot legally play an MP4 video, I would like to meet them. If you can frame an intelligible argument for refusing MP4 video contributions, I would like to hear it.

    • Re:Thin. (Score:4, Interesting)

      by sk999 (846068) on Saturday February 15, 2014 @07:45PM (#46256943)

      "If you know anyone who cannot legally play an MP4 video, I would like to meet them."

      How is someone to know if they are or are not legally allowed to play MP4?

      • You aren't allowed to. Unless someone paid for the patents. Either the hardware or software manufacturer. Did you pay for your playing device? If you didn't there's a good bet you aren't allowed to. The only exception I know of is Adobe Flash. It includes MPEG-4 decoding support and Adobe payed the license. Or whatever. That's why that cancer that is Adobe Flash doesn't seem to vanish from computers. Ever.

    • by epyT-R (613989)

      Wikipedia's main goal is to ensure that its repository of knowledge remains available to all in perpetuity. The best way to ensure this is to house it in free-to-implement technical standards so that the content can be supported by playback vendors, cost-free, as well as ensure that the software needed to access the data is always available..

    • by Vanders (110092)

      If you know anyone who cannot legally play an MP4 video, I would like to meet them.

      I've got a better question for you: why are there still people who are unable to open and play back a WebM video? What's the driver behind not including WebM support in the handful of OSes & devices that have refused so far? It isn't technical. It certainly isn't a cost issue. It surely can't be licensing. So that only leaves, what, ideology?

      Are Apple & Microsoft going to continue to make their users lives more dif

  • File formats aren't copyrightable, and therefore the "FLOSS" label does not apply. Only specific software is copyrightable, and last I checked, there's a plethora of Free Software encoders and decoders, including ffmpeg, x264, etc.

    What the maintainer of the codec wishes to do isn't my problem, and it's not Wikimedia's problem.

    • by drinkypoo (153816)

      File formats aren't copyrightable, and therefore the "FLOSS" label does not apply.

      File formats can be patent-encumbered, and therefore the "FLOSS" label does apply. Most formats of any interest are open (forget the OSI for a moment here) but many fewer are Free.

  • by Kazoo the Clown (644526) on Sunday February 16, 2014 @01:09AM (#46258083)
    Even Archive.org supports MP4, among other formats. YouTube does both Flash and MP4 for the most part, or at least most of the third party downloaders will give it to you in MP4. Clearly the solution is to provide the content in a couple of formats, enough to serve THE USERS. Unless that is, you don't give a shit about users, in which case I don't see why you need a web presence at all...
    • by Raenex (947668)

      Clearly the solution is to provide the content in a couple of formats, enough to serve THE USERS. Unless that is, you don't give a shit about users, in which case I don't see why you need a web presence at all...

      Wikipedia is big enough that it can and should value its core principles over the short-term convenience of a subset of its users. From the summary:

      "Current community requirements are that free/open standards should be used at all times to encode and store video files on the servers that house our data, so that both our content and software can be redistributed without any restrictions." (bold mine)

      Wikipedia is using long-term thinking, and I applaud the decision.

  • MP4 is a media file container (technically MPEG-4 Part 14, or ISO/IEC 14496-14).

    MPEG-4 Part 10 aka ISO/IEC 14496-10 aka AVC aka ITU-T H.264 is a codec that is often found in MP4 containers (except when it is found in MPEG transport streams, such as in Apple HLS).

    There are other video codecs that can be in an MP4 container, such as MPEG-4 Part 2, MPEG-2, or MPEG-1.

    By the way, HEVC (aka ISO/IEC 23008-2 MPEG-H Part 2 aka ITU-T H.265) is amazingly efficient and everyone should switch to it immediately :)

  • "Now they can get back to their mission of advocating openness."

    That was never the mission. This is what they call "mission creep".

    As someone that is responsible for creating more content than most of the "no votes" put together, I shake my head in shame.

  • by astro (20275) on Sunday February 16, 2014 @11:23AM (#46259677) Homepage

    I am surprised there is so much debate here on this. Apparently I have a different understanding of Wikimedia's core mission than some people. In my understanding, their mission is to provide, without restriction, community curated knowledge, period. It is temporarily unfortunate that some (even a significant quantity of) people may be unable to benefit from supporting media to the core knowledge because the platform they are paying for in turn forces them to pay a license for the proprietary technology to read such material. But in the long run it is absolutely appropriate that no proprietary technology should be required to read a single digital bit of the material that Wikipedia provides. To have allowed h.264 would have subtly subverted the core mission.

"Irrationality is the square root of all evil" -- Douglas Hofstadter

Working...