News for hackers. Stuff that matters.
Re:An Invisible Tax on the Web: Video Codecs (2018) by gnicholas on Saturday January 09, 2021 @07:32PM (#25706804)
Some interesting details on how the H.264 patents are priced, from an article [1] about how much Google pays. Google had threatened to pull H.264 support circa 2011, but ultimately they decided in 2013 to pay a few million bucks/yr to keep it.

IIRC, H.264 is one of a few non-Google technologies that is included in Chrome, but is not included in Chromium.

> So, how much does those rights cost? Under the terms in place for 2011-2015, the royalty rates are the same regardless of whether a product is part of an OS. There's no royalty for the first 100,000 units of a licensed product; sublicensees pay 20 cents per unit up to 5 million and 10 cents per unit above 5 million. The current agreement includes an annual limit: “The maximum annual royalty (‘cap’) for an Enterprise [is] $6.5 million per year in 2011-2015.”

What happens in 2016? Under the MPEG LA license, the terms are "renewable for successive five-year periods … on reasonable terms and conditions.” The per-copy royalty rates "will not increase by more than 10% at each renewal.” If rates go up by the maximum 10% for that five-year period, the cost of 10 million licenses will increase by $150,000 from a current rate of $1.48 million to $1.63 million.

There's a small gotcha in the new MPEG LA license agreement. Footnote 17, which appears in tiny print at the very end of the summary of license terms, notes that “Annual royalty caps are not subject to the 10% limitation.” Although that sounds like a loophole, it really only affects the largest players in the market.

1: https://www.zdnet.com/article/a-closer-look-at-the-costs-and....

Re:An Invisible Tax on the Web: Video Codecs (2018) by laurencerowe on Saturday January 09, 2021 @08:55PM (#25707777)
> There's a small gotcha in the new MPEG LA license agreement. Footnote 17, which appears in tiny print at the very end of the summary of license terms, notes that “Annual royalty caps are not subject to the 10% limitation.” Although that sounds like a loophole, it really only affects the largest players in the market.

Cisco’s free to use h264 encoder/decoder binaries of its open source OpenH264 are a result of this license cap so potentially it could affect others if those rates rise to the point they withdraw availability.

https://en.m.wikipedia.org/wiki/OpenH264

Re:An Invisible Tax on the Web: Video Codecs (2018) by aste-risk on Sunday January 10, 2021 @02:05AM (#25711738)
the wikipedia page mentions that cisco pays to MPEG LA royalties on behalf of any software project that uses their precompiled binaries. How do they keep track of who downloaded their binaries and how much money they owe to MPEG LA?
Re:An Invisible Tax on the Web: Video Codecs (2018) by detaro on Sunday January 10, 2021 @06:28AM (#25713613)
AFAIK they pay the max amount, so it doesn't matter how many people use their binaries.
Re:An Invisible Tax on the Web: Video Codecs (2018) by Moosdijk on Sunday January 10, 2021 @04:02AM (#25712575)
I think it's internally. The article also states that the users of the code would still have to pay the royalties.
Re:An Invisible Tax on the Web: Video Codecs (2018) by Delk on Sunday January 10, 2021 @04:56PM (#25720434)
No, it's not only internal use, as long as it's Cisco's binary that's being distributed. That's how for example Firefox ships H.264 decoding support.

The license does not cover any other binaries built from the same Cisco source code, though.

The Wikipedia article is also fairly clear about this and says: "any software projects that use Cisco's source code instead of its binaries would be legally responsible for paying all royalties to MPEG LA themselves, however."

(emphasis mine)

Re:An Invisible Tax on the Web: Video Codecs (2018) by lucb1e on Saturday January 09, 2021 @09:22PM (#25708070)
> IIRC, H.264 is one of a few non-Google technologies that is included in Chrome, but is not included in Chromium.

That's interesting, I never missed it and use both Chromium and Firefox. Apparently we can do without this tax. Or might a nonfree codec package in Debian have something to do with it? I did hear someone complain once about my sending a nonfree video format (in a jovial manner), not sure about the details anymore but it played out of the box for me (in Chromium).

Re:An Invisible Tax on the Web: Video Codecs (2018) by zerocrates on Sunday January 10, 2021 @12:46AM (#25710929)
I believe Firefox will support H.264 for videos only using the operating system's own support (so on Linux, if you have it supported in gstreamer and/or ffmpeg then it's supported in Firefox).
Re:An Invisible Tax on the Web: Video Codecs (2018) by labawi on Sunday January 10, 2021 @08:21AM (#25714416)
Linux firefox Plugins tab, though I'm not sure if it's used beyond webrtc:

> OpenH264 Video Codec provided by Cisco Systems, Inc.

> This plugin is automatically installed by Mozilla to comply with the WebRTC specification and to enable WebRTC calls with devices that require the H.264 video codec. Visit https://www.openh264.org/ to view the codec source code and learn more about the implementation.

Re:An Invisible Tax on the Web: Video Codecs (2018) by zinekeller on Sunday January 10, 2021 @11:04AM (#25715986)
Nope, it isn't used beyond WebRTC, and in Windows it even autodetects if the computer has a capable enough hardware encoder and use that instead (and decoding through native Windows libraries if there isn't a suitable hardware decoder).
Re:An Invisible Tax on the Web: Video Codecs (2018) by colejohnson66 on Saturday January 09, 2021 @11:41PM (#25710172)
If you’re using YouTube, it supports other formats than just H.264. So, in that instance, lack of H.264 isn’t noticeable.
Re:An Invisible Tax on the Web: Video Codecs (2018) by Narishma on Sunday January 10, 2021 @04:18AM (#25712710)
Unless you don't have hardware accelerated decoding for VP8/9. Then it is very noticeable, especially on a laptop.
Re:An Invisible Tax on the Web: Video Codecs (2018) by KozmoNau7 on Sunday January 10, 2021 @05:42AM (#25713281)
This completely killed my Tegra K1-based chromebook. What good is a Google laptop with a full HD display, if it can't play Youtube videos in any resolution higher than 480p?
Re:An Invisible Tax on the Web: Video Codecs (2018) by basilgohar on Sunday January 10, 2021 @09:11AM (#25714751)
That would be very odd because YouTube definitely supports H.264 videos in higher than 480p resolutions. VP9 is only exclusively used for some formats/resolutions (e.g., HDR is VP9-only, I think).
Re:An Invisible Tax on the Web: Video Codecs (2018) by KozmoNau7 on Sunday January 10, 2021 @06:59PM (#25721941)
It's been a while since I sold it, but it would just choke on anything 720p or higher.
Re:An Invisible Tax on the Web: Video Codecs (2018) by samoa42 on Sunday January 10, 2021 @04:43AM (#25712901)
this!

h264 is the most widely supported codec to decode in hardware, so the inclusion of a software decoder in the browser is kinda moot.

Re:An Invisible Tax on the Web: Video Codecs (2018) by MaxBarraclough on Saturday January 09, 2021 @08:38PM (#25707552)
Doesn't Windows bundle an H.264 decoder? If Chrome made use of that, would they have to pay for their own licence?
Re:An Invisible Tax on the Web: Video Codecs (2018) by devbug on Sunday January 10, 2021 @04:44AM (#25712905)
Windows bundles software decoders (for H.264 and H.265) that are available through MFT and DXVA.[1][2] Chromium leverages both already.[3] It's also a low effort way to support hardware-accelerated decoding as vendors (Intel, AMD, NVIDIA) register MFTs that wrap their propriety SDKs (Quick Sync, AMF, NVDEC).

These provided MFTs have to meet certain minimum requirements for certification by Microsoft, which amounts to "good enough." Results vary in practice and can be incredibly frustrating (especially encode). It's often better to use the underlying SDKs but that comes with a lot of hassle.

(I've been working on a video capture and sharing app inspired by Shadowplay.)

Windows 10 is also rolling out support for AV1, though not bundled.[4]

[1]: https://docs.microsoft.com/en-us/windows/win32/medfound/h-26...

[2]: https://docs.microsoft.com/en-us/windows/win32/medfound/abou...

[3]: https://chromium.googlesource.com/chromium/src/+/master/medi...

[4]: https://www.microsoft.com/en-us/p/av1-video-extension/9mvzqv...

Re:An Invisible Tax on the Web: Video Codecs (2018) by MaxBarraclough on Sunday January 10, 2021 @06:25AM (#25713582)
> Chromium leverages both already

Why do they need to pay for their own licence then?

Re:An Invisible Tax on the Web: Video Codecs (2018) by ksec on Sunday January 10, 2021 @07:54AM (#25714238)
They dont, and neither do Mozilla if they decide to use the OS media playing framework.

But most Browsers tends to implement their own for all sort of reasons.

Re:An Invisible Tax on the Web: Video Codecs (2018) by kfarr on Saturday January 09, 2021 @10:42PM (#25709429)
IIRC this is what Firefox tries to do -- use the OS decoder. For many reasons it is not a great user experience.