1080i/720p MPEG-2

[yakovlev]

Asked this on another page, but I think that was the wrong place. This seems to be the right one.

In the US, our digital TV standard is either 1080i or 720p MPEG-2 at 19.4 Mbit/s. Will raspberry pi be able to decode this, either with the arm chip (doesn't seem likely) or with hardware acceleration?

This would be a big help for working with digital TV signals.

One of the earlier posts implied that SD MPEG-2 (i.e. DVD quality of 720x576 at 9.8Mbit/s) shouldn't be a problem for the ARM chip alone, which would be a great thing if it's accurate. I was expecting even that to be a stretch for the ARM.

Thanks!

[Gert van Loo]

Yes, the board can do that. You will need the GPU to do it for you. What I don't know is if licensing is required.

[yakovlev]

The standard linux video acceleration APIs seem to be VDPAU, XvBA, and VA-API, although the first two seem to be proprietary. Does the board use one of these extensions to interface with the proprietary graphics driver, or does it use something more custom?

As far as licensing goes, would that be licensing the correct binary blob from Broadcom, or getting something from MPEG-LA?

Thanks!

[liz]

We haven't decided yet about codec licensing (which would be from MPEG-LA), although the board does support it in hardware. I'll be writing a post on the blog when we've finished negotiation about codecs later on; I think you'd be pretty shocked to find just how much of the cost of the final board is taken up in licence fees, so we're having to think very hard about exactly which ones to include. (Example: AAC costs us 4% of the price of each board!) For most people, the decoding done by h.264 should be sufficient, although there are good arguments for including the codecs you mention - we'll let everyone here know when we've made a decision.

[ShiftPlusOne]

So if we use something like mplayer, we won't have GPU acceleration for most formats unless you buy the license and code support for it into the GPU?

[yakovlev]

Just to add some information to my own question, from what I've been able to determine.

Raspberry Pi uses an embedded acceleration API known as OpenMAX. This API basically requires a separate codec be supplied in the "binary blob" for each media type.

OpenMAX seems to have limited linux support, mainly with gstreamer and possibly also with VLC. Unfortunately, it sounds like most of the linux media applications use ffmpeg, which lacks OpenMAX backend support. Neither VA-API nor VDPAU are supported.

To make a long story short (too late) the ARM core will hopefully be sufficient for SD video, as that is all that most media applications will have access to. Selected media applications will be able to use the accelerated codecs, but only if each individual codec is licensed by the foundation (included in the binary blob) which will be a significant licensing cost per codec. There is no "generic" back end that can be used to accelerate all video codecs using OpenGL 2.0 (or something similar) primitives.

Thanks!

[liz]

Quote from yakovlev on September 21, 2011, 23:19
Just to add some information to my own question, from what I've been able to determine.

Raspberry Pi uses an embedded acceleration API known as OpenMAX. This API basically requires a separate codec be supplied in the "binary blob" for each media type.

OpenMAX seems to have limited linux support, mainly with gstreamer and possibly also with VLC. Unfortunately, it sounds like most of the linux media applications use ffmpeg, which lacks OpenMAX backend support. Neither VA-API nor VDPAU are supported.

To make a long story short (too late) the ARM core will hopefully be sufficient for SD video, as that is all that most media applications will have access to. Selected media applications will be able to use the accelerated codecs, but only if each individual codec is licensed by the foundation (included in the binary blob) which will be a significant licensing cost per codec. There is no "generic" back end that can be used to accelerate all video codecs using OpenGL 2.0 (or something similar) primitives.

Thanks!

That's exactly right. We're going to try to get as many codecs licensed as possible, though - so don't panic yet!

[yakovlev]

I'm wondering what the feasibility is of a "codec license pack" or "multimedia upgrade" selling for, say $10-$20?

This would allow a full array of codecs for those who want/need them, but would be able to keep the base cost down, as it's starting to sound like codec licensing will be a significant part of the cost. (At a rate of roughly $1/codec, based on one of your earlier postings and a little math.)

Then again, the licensing bodies may not be real fond of that idea, for "codec piracy" reasons.

[Michael]

Quote from yakovlev on September 22, 2011, 16:26
I'm wondering what the feasibility is of a "codec license pack" or "multimedia upgrade"


Yea, I was thinking along similar lines, go for the best bang for buck (as Liz outlined) on the model A, and provide (almost?) everything on the model b.

[liz]

We've been thinking about a codec license pack - I know I can't hold you guys off from speculating, but we know that media centre applications are going to be something people want to use it for (and I want to see as many of these in living rooms as possible, because it means exposure to kids); so we're very aware of this while we're working out what to do.

[yakovlev]

liz, that's fantastic to hear. Sounds like you've got all the right ideas, and just have to work through what the best ones are.

[Unnamed]

VP8?
Only Firefox arm supported http://en.wikipedia.org/wiki/H.....ideo#Table

[jamesh]

I think the GPU has a VP8 codec, but at the moment we are still working on attaching the GPU to web streaming, so web based video is not yet working.