Will the PS3 be able to decode H264.AVC at 40 Mps?
- Thread starter Brimstone
- Start date
Who would this be, and which profile?
Because 1080p High Profile @ 30-40 megabits/s is no cakewalk. And I'd find it extremely hard to believe he pulled it off on the PS2. At the present time, probably not even on a dual core PC. ;-)
(Don't point to Quicktime, it doesn't even fully support Main Profile and doesn't have CABAC.)
And we're talking about bitrates and algorithmic complexity increases to match.
For this reason, none of the standalone players today use a general purpose CPU or even a GPU to decode the video, it's all cast in silicon for very good reasons.
Last edited by a moderator:
At CES, they specified that PS3's software decoding would leverage Cell+RSX. They didn't elaborate to what extent RSX would be used, though.
Probably the same as the current PC GPU. Most likely RSX will do IT, MC and Deblocking. While Cell do the CABAC and what ever left over. Its a good 50/50 split interm of workload needed.
CABAC is unfriendly to everything - even dedicated HW
- but it does do a nice job of squeezing the data down further. <shrug>Was that a profile that used CAVLC rather than CABAC for the entropy encoding/decoding?
Last edited by a moderator:
Mefisutoferesu
Regular
So, I've been reading through some of the papers on CABAC and my feeble brain is sorta at a loss as to why it's such a bad thing... Aside from being pretty computationally heavy I don't really see anything that's particularly unfriendly to CELL, SO I turn to the infinitely more versed B3D and say, "What? What? WHAAAAT?!!"
From what I gather:
- CABAC is extremely difficult to parallelize. You basically process from the first symbol to the last in sequential order, and the algorithm depends on them being processed in order. So splitting it across multiple SPEs is out.
- CABAC uses a lot of data dependent branching. SPEs aren't that good at branching.
- CABAC uses a lot of memory accesses. SPEs aren't good at lots of memory accesses, if what they're accessing doesn't fit into LS.
To be 100% clear, I'm not saying that it can't be done, just saying that it's not a cakewalk, even for CELL.
Last edited by a moderator:
Ah I see.
Just so we're clear on the matter. Sony announced in its E3 2006 press release that the PS3 can achieve the maximum bitrate Blu-ray offers so the burden of proof here is to find evidence why it can't achieve that.
http://www.us.playstation.com/News/PressReleases/341
And on the subject of PR, ATI's announcement of AVIVO inclusion for the 360 did not have a single mention of the CPU, which is still a fundamental part of their decode process. It's just about what you want to talk up, not necessarily a verbatim description of the processes involved.
http://www.us.playstation.com/News/PressReleases/341
And on the subject of PR, ATI's announcement of AVIVO inclusion for the 360 did not have a single mention of the CPU, which is still a fundamental part of their decode process. It's just about what you want to talk up, not necessarily a verbatim description of the processes involved.
Do you need to split it over multiple SPEs ? From what I gather of Cell, a single SPE and PPE should be able to do the job. The other can go do some other stuff, or go to sleep.
They could be talking about MPEG-2.
Basing anything off a Company's PR release is very shaky ground at best! I mean no company would every strech the turth in a PR release at a big trade show would they
The burden of proof lies with both camps well until its released that is, then we will know for sure.Basing anything off a Company's PR release is very shaky ground at best! I mean no company would every strech the turth in a PR release at a big trade show would they
I'm sorry but I find this line of reasoning utter nonsense. You don't get to pick and choose what is PR disingenuity and not. Until proven otherwise, we have to accept that the information released by a company is fact. If we're allowed to call this out, then why stop there? What makes this more unlikely than the console actually existing at all? It again comes down to "Why do we not believe this?" which invokes the burden of proof.
I think you're just being overly cynical.
I don't have the details, just some more questions. Is CABAC the only stage in H.264 AVC decoding ? Can you organize the SPEs in stream fashion so that 1 SPE or the PPE focuses on CABAC while the rest perform other pre- and post- stages ?
If done on a SPE, the local store can still help if processing can be chunked, loops can be unrolled and memory latency can be hidden.
Depending on how bad the situation is... you can still throw multiple SPEs at a problem (if you have spare ones), you just get lesser speed up but the overall effect can still be faster than just 1 SPE. Some of these work can include speculative calculation. This is wasteful though (generally not recommended).
You mean random memory accesses ? I thought the SPE's async DMA is great for fetching consecutive memory. As long as the SPE can perform other stuff while waiting for its data to arrive, it should do fine.
Cell has been demoed decoding 12 HD streams simultaneously so why should 1 give it so much difficulty?
There were DSPs around 3 years ago which could decode H.264 and I doubt they'd even match a single SPE.
Even if there is a section which gives Cell problems it can always be modified to make it more Cell friendly.
BTW H.264 is another name for AVC, H.264 seems to have a small army of different names (including MPEG4 layer 10).
There were DSPs around 3 years ago which could decode H.264 and I doubt they'd even match a single SPE.
Even if there is a section which gives Cell problems it can always be modified to make it more Cell friendly.
BTW H.264 is another name for AVC, H.264 seems to have a small army of different names (including MPEG4 layer 10).