A plea to the Foundation re. MPEG-2

I appreciate the fact that the Foundation has other fish to fry, but some members are still thinking about this "in their spare time," so to speak. Thank you for being creative in finding a solution that benefits only my part of the community.

I would use MPEG-2 decoding quite a bit, primarily for 1080i decoding on OTA terrestrial TV broadcast streams here in the States.

Secondarily, I would use MPEG-2 to H.264 transcoding and two Pis for those times when I am in Europe and would like to watch TV remotely.

I think someone indicated that it runs about $0.10 each in when there are 100K+ licenses involved

Can you provice a link for that?

I believe it is $2 per unit sold, with no cap for mpeg2 decode.

I spent some time looking for it, but I can't find it. If I do...I'll let you know. (This week is being more than a tad busy...so I don't know when I'll be able to make a thurough search.)

I think someone indicated that it runs about $0.10 each in when there are 100K+ licenses involved

Can you provice a link for that?

I believe it is $2 per unit sold, with no cap for mpeg2 decode.

Correct. [1]

I spent some time looking for it, but I can't find it. If I do...I'll let you know. (This week is being more than a tad busy...so I don't know when I'll be able to make a thurough search.)

$0.10/unit are the terms for AVC above 5 million units/year. 100K to 5 million is $0.20/unit [2]

[1] http://www.mpegla.com/main/programs/M2/ ... ement.aspx
[2] http://www.mpegla.com/main/programs/AVC ... ement.aspx

I would use MPEG-2 decoding quite a bit, primarily for 1080i decoding on OTA terrestrial TV broadcast streams here in the States.

In the UK "Freeview" (SD OTA terrestrial digital TV) uses MPEG2, but "Freeview HD" (HD OTA terrestrial digital TV) uses H264. Does the US use MPEG2 for both?

I don't want to get into religious debates but can I just add my +1 for this request

$0.10/unit are the terms for AVC above 5 million units/year. 100K to 5 million is $0.20/unit [2]

[1] http://www.mpegla.com/main/programs/M2/ ... ement.aspx
[2] http://www.mpegla.com/main/programs/AVC ... ement.aspx[/quote

Hi!

If that information is correct then maybe the Foundation could set up a donationd fund for the supporters of mpeg2 related codecs - to unlock them global on all devices.
That ammount of money should be possible to collect. I am sure the majority of us would donate for this goal more money than (divided by X) theoretically needed.

Its really pity that the Raspberry Pi can not decode the (at the moment) widest used codec in hardware.

John

[jamesh]

Let's say, 200k systems already released and rising by 4k a day. That $400k to find. Not an easy ask. Even if people stumped up $10 (5 times what the licence itself is worth, notwithstanding any cost issues with DRM and maintenance of databases to record licences etc), that's still 40k people needed to 'crowdfund' it.

I can't see that happening. Whether it's the widest used codec in hardware or not.

I would use MPEG-2 decoding quite a bit, primarily for 1080i decoding on OTA terrestrial TV broadcast streams here in the States.

In the UK "Freeview" (SD OTA terrestrial digital TV) uses MPEG2, but "Freeview HD" (HD OTA terrestrial digital TV) uses H264. Does the US use MPEG2 for both?

Yes, the US uses MPEG-2 for both. Most channels are HD, therefore no MPEG-2 hardware decoding means that the Pi has very limited utility with regard to OTA TV.

The ATSC standard that applies in the US does have a section for use of H.264, but since all the broadcasters started with MPEG-2, they have stayed with MPEG-2.

I would use MPEG-2 decoding quite a bit, primarily for 1080i decoding on OTA terrestrial TV broadcast streams here in the States.

In the UK "Freeview" (SD OTA terrestrial digital TV) uses MPEG2, but "Freeview HD" (HD OTA terrestrial digital TV) uses H264. Does the US use MPEG2 for both?

Yes, the US uses MPEG-2 for both. Most channels are HD, therefore no MPEG-2 hardware decoding means that the Pi has very limited utility with regard to OTA TV.

The ATSC standard that applies in the US does have a section for use of H.264, but since all the broadcasters started with MPEG-2, they have stayed with MPEG-2.

In addition to the OTA (almost universally MPEG2) there are many cable/satellite carriers. Some rebroadcast the streams they receive from the content providers (MPEG2 for the OTA providers), some transcode these streams to MPEG4 (H.264).

Most (all I have seen) of the OTA stuff or CableCard stuff just gives you a stream of whatever they receive. SiliconDust HD HomeRun Prime is the example of what I was planning to use to make the tuners available in my house to all the infrastructure.

+1 for MPEG-2 decoding ...

I will add my vote to get MPEG-2 decoding added to the Pi.
Its low-cost, low-power requirements, low-heat and 1080p playback capabilities (enabled and not) make it the ideal openELEC platform. And if MPEG-2 hardware-based decoding was enabled, it would be the perfect "HDhomerun client".

Discovering today that the Broadcom SoC can indeed decode MPEG-2 and that this capability *could* be activated via a firmware upgrade, I'll wholeheartedly say that I'd be willing to pay to get this firmware upgrade. This possibility actually made me purchase a 2nd Pi on the spot -- even before receiving the 1st one I ordered.

Since the MPEG LA is getting its knickers in a twist over hypothetical piracy of a very specialized piece of software, I'd suggest to simply put the firmware upgrade onto some form of daughterboard. Such an arrangement could make it possible for future buyers to buy a "Pi rev. C" that has added capabilities unlocked by the use of this additional module.

And existing clients could upgrade the Raspberry Pi units they already own. Win-win for everybody!

I will add my vote to get MPEG-2 decoding added to the Pi.
Its low-cost, low-power requirements, low-heat and 1080p playback capabilities (enabled and not) make it the ideal openELEC platform. And if MPEG-2 hardware-based decoding was enabled, it would be the perfect "HDhomerun client".

Discovering today that the Broadcom SoC can indeed decode MPEG-2 and that this capability *could* be activated via a firmware upgrade, I'll wholeheartedly say that I'd be willing to pay to get this firmware upgrade. This possibility actually made me purchase a 2nd Pi on the spot -- even before receiving the 1st one I ordered.

Since the MPEG LA is getting its knickers in a twist over hypothetical piracy of a very specialized piece of software, I'd suggest to simply put the firmware upgrade onto some form of daughterboard. Such an arrangement could make it possible for future buyers to buy a "Pi rev. C" that has added capabilities unlocked by the use of this additional module.

And existing clients could upgrade the Raspberry Pi units they already own. Win-win for everybody!

I believe it's been mentioned on here that the camera module *may* be used as an activation dongle at some point.

I believe it's been mentioned on here that the camera module *may* be used as an activation dongle at some point.

I've seen this too, though I must point out that there are some, like me, who have no use for a camera with the Pi in the context of a media player... It would be a shame to waste a perfectly good camera module. This is why I'd suggest a second, simpler and possibly cheaper type of expansion module: the "firmware upgrade board".

Being simpler, such a module could be brought to market even quicker.

I've been watching this thread with interest viewtopic.php?f=29&t=5641 about software decoding of MPEG2 at SD resolution.

Is this a solution that is likely to reach fruition before a Hardware Decode solution being licensed?

I am pondering if SD MPEG-2 decoding in software will meet the majority of folks' requirement. I know that my HD is also in MPEG-2 here in the US, is this the case for others though?.

The progress certainly looks good. Well done to those with more skills in this area than me.
As for MPEG-2 for HD (TV) ...
Here in UK we have MPEG2 for DVB-T (Digital SD) and MPEG4 for DVB-T2 (can do HD).

My off-air recordings are MPEG2 and attempts at conversion to MPEG4 have proved to be very very slow and I seemed to loose quality (as expected I suppose when re-encoding from lossy to lossy).
I am one of the early requesters - from before the device shipped.
If it means buying the camera add-on I'd almost certainly do it.

maybe I am completely wrong but this looks promising to me: https://github.com/raspberrypi/firmware/commit/3bf71e429299611f5e671a04026cd4d19afbb95b

Got enough testers for the mo - will come back for beta round

Simon

[jamesh]

The progress certainly looks good. Well done to those with more skills in this area than me.
As for MPEG-2 for HD (TV) ...
Here in UK we have MPEG2 for DVB-T (Digital SD) and MPEG4 for DVB-T2 (can do HD).

My off-air recordings are MPEG2 and attempts at conversion to MPEG4 have proved to be very very slow and I seemed to loose quality (as expected I suppose when re-encoding from lossy to lossy).
I am one of the early requesters - from before the device shipped.
If it means buying the camera add-on I'd almost certainly do it.

Are you doing the conversion on the Raspi itself - which would be pretty slow? A PC decent PC should be faster than realtime. Quality degradation shouldn't be too noticeable although there will be a bit. But then any rip shows some degradation.

The camera add on as a dongle was just an idea Gert and I threw around, since you really need H264 encode for the camera, and the MP2 licence could go in as well as that (although its another $2).

Certainly adding the codec to the camera module seems to be the simplest means for the foundation to manage the license and would be the quickest method for users to obtain it. I fully support that concept and would purchase one for mpeg2 support to play ATSC files.

Maybe later on, if the foundation is inclined, there could be a codec module that is smaller and cheaper than the camera module.

Are you doing the conversion on the Raspi itself - which would be pretty slow? A PC decent PC should be faster than realtime.

On PC - but not live. I couldn't get live re-encoding working well with the handful of UPnP servers that I tried.
So I did post-recording conversion using Handbrake and a couple of others but didn't get good quality. Maybe I should have tried with other settings.

Quality degradation shouldn't be too noticeable although there will be a bit. But then any rip shows some degradation.

I record from Freeview - so initial recording quality is as broadcast - lower than DVD.

Please add the mpeg-2 license, Gladly would pay the surcharge, for the units we have purchased

XBMC, works perfect with h264, but not all channels of streaming use this codec

licensepacket@mpegla.com

+1 for MPEG-2 decoding ...

It's the one thing lacking from being my PI "perfect".

Edit: this reply was to a quite old post in this thread to someone claiming the end user would have to pay license fees for using software codecs.

The answer is - you don't need to, actually the reason is quite simple:
Patent fees have to be paid if you use the patented technology commercially.
If you are a private user or use it purely for research (Non profit research...) you're free to use any patented technology.
So If you make money with it you have to pay but this doesn't apply to end users. So from a R-Pi user perspective, as long as you don't plan to sell products using the Pi or sell services provided by means of your pi you can pretty much use any patented technology you want.
Now the foundation does not have this possibility since they sell Pis and therefore they'd better have licenses for those patents.
So opensource developers writing codecs are perfectly leagally doing so, but if your company sells support for a linux distribution then either you'd better not include those codecs or buy a license for them. Most distributions don't include codecs since the end user can quite easily add them themselves

Right now, are there any formats we can use for encoding using OpenMax? VP8 maybe? (even if not fully optimized it's still much faster than anything done in the cpu). Or there is still no possibility for encoding?
By the way, I looked into the .elf files updated a few days ago and I saw a new copyright string in there (a Dolby copyright). I guess we're getting ready for the camera and GPU encoding.

If you go a bit back in this thread you'll see that I asked for V8 encoding/decoding .

The response was (implied and explicit) :

1) It is experimental and we can not bear even one n00b / stupid press person
complaining about bugs (i'm guessing this here)
2) There is no V8 content ( they sounded like implying this)
3) It is only SD quality ( they said something about the impossibility to use
the same modes of HW accel. already used by h.264)

And:
http://www.raspberrypi.org/archives/592

ghans