MPEG-2 Patents Have Expired (mpegla.com)
New submitter jabuzz writes: Unless you live in the Philippines or Malaysia, then MPEG-2 has now joined the likes of MP3 and AC3 and gone patent free with the expiration of US patent 7,334,248.
← Back to Stories (view on slashdot.org)
HDTV in the United States uses ATSC, which is a transport stream for MPEG-2. Most cable companies still use MPEG-2, though I believe the satellite companies have switched.
While this only means a $2 reduction in the cost to make a TV, it also means a $2 reduction in the cost of streaming devices capable of playing TV signals. That's significant when you're talking about a Roku stick, which is why they skipped the license fee and don't support it. That means you can't use a Roku as a frontend for MythTV without transcoding your recordings, and you can't use a Roku as a frontend for a HDPrime networked cable card tuner.
All that can change now. I don't know if existing hardware that Roku uses can support MPEG-2, but if it does, then they could add support with just a software update. The same with all the other similar devices that may not have supported MPEG-2 in the past.
To put it in perspective, two days ago was the 28th anniversary of Super Mario Bros. 3 in the US.
-=This sig has nothing to do with my comment. Move along now=-
>Is the patent relevant to modern computing?
As network capacities increase, the efficiency of the coding should matter less. So presumably MPEG-2 is becoming more relevant over time.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
A lot of live HD distribution is still done in MPEG2. Why? The coding delay for MPEG2 is a lot lower than for h264/HVEC/whatever the latest fancy is. Not a big deal when dealing with canned material, but a huge factor in dealing with live material. It's the difference between an 18Mbps stream (for MPEG2 HD) vs 6Mbps (h.264), but also the difference between 0.5 seconds of encoding delay vs 2 or 3 seconds.
Also, the broadcast industry is incredibly stingy when it comes to spending money, especially capital expenditures. MPEG2 encoders are pretty cheap at this point, whereas MPEG4 are 10x the cost.
...si hoc legere nimium eruditionis habes...
A lot of live HD distribution is still done in MPEG2. Why? The coding delay for MPEG2 is a lot lower than for h264/HVEC/whatever the latest fancy is. Not a big deal when dealing with canned material, but a huge factor in dealing with live material. It's the difference between an 18Mbps stream (for MPEG2 HD) vs 6Mbps (h.264), but also the difference between 0.5 seconds of encoding delay vs 2 or 3 seconds.
That's not an inherent problem of the spec, and hasn't been true for over half a decade:
http://web.archive.org/web/20150306225444/http://x264dev.multimedia.cx/archives/249
(it's even better today)
I've set up live streams with x264 as an encoder with a guaranteed
encoding latency of under 150ms. On commodity hardware.
Also, the broadcast industry is incredibly stingy when it comes to spending money, especially capital expenditures. MPEG2 encoders are pretty cheap at this point, whereas MPEG4 are 10x the cost.
Yeah, commercial ones. I've been surprised several times by how free-software-averse
the whole broadcasting industry is: They'd rather buy a commercial encoder for $bignum
purchase + recurring $bignum2 support fee instead of using a superior setup that's based
on x264, would cost them about $bignum/10 for the initial setup, and then nothing to run for as
long as they'd like. I'd even deliver the whole documentation on how to run everything, so they
wouldn't need me again.
It's frustratingly hard to make "No need, I'll document and show you how to fix everything yourself"
an accepted answer to "But who do we call if something goes wrong?", even in cases where
they already have very capable and qualified people in-house.
Unfortunately, there's a pretty good inverse correlation between price and quality for H.264
encoders: The more expensive they are, the more they suck.
And that's were the latency problem tends to come in (and the encoding efficiency problem, and
the picture quality problem, and...).
FWIW, the "interesting" video codec patents expired many years ago. You can peruse them here...
https://en.wikipedia.org/wiki/...
The last patent is entitled "Conditional access filter as for a packet video signal inverse transport system" applied to cable systems and satellite broadcast, but basically doesn't apply to program streams (which is what is used in DVD and created by most MPEG2 A/V multiplexers).
There were some streaming and DVR-like systems that recorded transport streams directly and used them, but not really any "free" stuff (which might use packet formats like MKVs) . Of course now it is totally moot...
The mpeg2 key was just used to 'unlock' a software implementation in the VC4 firmware. It was trash anyways.
Basically all you need now is the open source VC4 drivers, or the open source vc4 gcc port and you can compile up mpeg2 for it at the same power usage as the real thing, completely bypassing the firmware requirement.
Not sure if they finished display output yet, but there is an open source VC4 bootstrap firmware now, as well as broadcom documentation on the VC4 opcodes so you could write/optimize your own implementation. The core has 20GFLOPS of peak processing if I remember correctly. Most of the Mali 400 cores are 2x that, but far less generally programmable.