Will the PS3 be able to decode H264.AVC at 40 Mps?

[Npl]

By "sync-points" I guess you mean "I-frames". These might be every 0.5~1 seconds or perhaps even further apart. If you want to try that with HD data then you'd better have a lot of RAM.

I called them Sync-Points because I dont know a better word for them, and Mp3 calls its frame-boundary that way. Im NOT speaking about I-frames, even though in the worst case they will have the same starting point. A sync-point would simply add a Header with enough information to start CABAC-decoding from there, such headers are only a few bytes and I would expect encoders to be capable of adding them regulary, either each x frames or each x KB of (unCABACed) Data.

For the RAM-requirement: assume worstcase is one second and you have a 40Mps stream, thats 5MB worth of compressed data. Its going to expand after unCABACing, but its worth noting that the result is still heavily compressed, and a few orders of magnitude smaller than the uncompressed frames. CABAC is still just entropy-encoding like Huffman, and that aint very efficient in most cases and even in the best case its less than 1:8. So the requirement in RAM is not insignificant, but doable IMHO.

 

[Guden Oden]

And with a big honking cache, you can prefetch a lot more, which ends up having roughly the same effect as having SPU local store anyway.

Except, CPU L2 has a lot higher latency than SPU LS of course, 2-3x more at least at 3+GHz rates... And if your computations are memory-intensive (as you say they are in this case), how much room will there be for prefetching simultaneously?

 

[Simon F]

I called them Sync-Points because I dont know a better word for them, and Mp3 calls its frame-boundary that way. Im NOT speaking about I-frames, even though in the worst case they will have the same starting point. A sync-point would simply add a Header with enough information to start CABAC-decoding from there, such headers are only a few bytes and I would expect encoders to be capable of adding them regulary, either each x frames or each x KB of (unCABACed) Data.

Sorry - I can only claim the excuse of jet-lag - I thought you meant decoding an entire frame.

You are referring to "slices" and, yes, there is at least one slice per frame and you can, in theory, decode just the cabac contents independently in each slice as the statistics are reset for each.

You'd still have to have a fair bit of buffering though.

CABAC is still just entropy-encoding like Huffman, and that aint very efficient in most cases and even in the best case its less than 1:8. So the requirement in RAM is not insignificant, but doable IMHO.

Only 1:8? I can't recall all the details, since it's been a while since I looked at it, but the arithmetic decoder (i.e. pre-debinarization) can expand the data by up a factor of ~100 (though this is rather unlikely).

 

[Npl]

Sorry - I can only claim the excuse of jet-lag - I thought you meant decoding an entire frame.

You are referring to "slices" and, yes, there is at least one slice per frame and you can, in theory, decode just the cabac contents independently in each slice as the statistics are reset for each.

You'd still have to have a fair bit of buffering though.

single-digit MBs if theres 1 slice every frame. I only wasnt sure how frequent they were.

Only 1:8? I can't recall all the details, since it's been a while since I looked at it, but the arithmetic decoder (i.e. pre-debinarization) can expand the data by up a factor of ~100 (though this is rather unlikely).

I meant Huffman with 1:8, CAVLC is similar AFAIK. CABAC is claimed to produce 20% smaller data compared to CAVLC. I can only guess here as I dont know the specifics, but I would be surprised seeing more than 1:6 compression in anything but cornercases.
Arithmetic encoding could theoretically have any compression ratio (if youre doing it analytically), but the problem is that you need to store finite precision values.

 

[DemoCoder]

I would have thought it was the other way around. With encode you know the contexts in advance since you are doing the "binarisation" (i.e. VLC encoding) first which is then encoded with the arithmetic encoder on a bit-by-bit basis. When decoding, OTOH, you (usually) have to decode each bit in order to decide how to to do the next one.

Do you know the contexts in advance? Before I know which context to enter, won't I have to read the next bit of data? For example, whether I'm encoding a prediction mode, or a predicted prediction mode? In the former case, I'm encoding the actual prediction mode, in the latter, my prediction was correct, so I only need to encode whether I was correct or not.

CABAC diagrams I've use use a state machine to switch contexts, and the state machine transistions consist of more than one arrow.

In general, AC is more expensive on the decode, except in recent years, it has been improved (e.g. IBM Q-coder, approximate AC, all-integer versions) to a wash, but most of the context adaptive modeling compression algorithms I've seen chew way more CPU and memory on encode (PPM, PAQ, etc) I am not as familar with CABAC, but I guess they have pre-computed all the initial models ahead of time, in which case it would cheapen the encode, and they don't have to look backwards.

 

[Simon F]

Do you know the contexts in advance? Before I know which context to enter, won't I have to read the next bit of data? For example, whether I'm encoding a prediction mode, or a predicted prediction mode?

I'm a bit rusty on the details as it's been well over a year since I looked at this but hopefully the concepts should be correct. I'll just consider the IDCT coefficients since those are going to be the bulk of the data.

IIRC, CABAC breaks each N*N (e.g. 4x4 or 8x8) block into a few syntatic pieces. The first is a map of which values in the block are significant, i.e. non-zero. The format is something like one bit to indicate if the value is non-zero and, if so, then there's another bit to indicate if it's the last nonzero in the block. For example, "1 0 0 0 1 1", might indicate "Non-Zero (not last) Zero Zero Non-Zero (last)".

Each of these bits is encoded/decoded with AC and each bit can select a different context. Thus, when decoding, you have to decode each bit fully to know which context to use for the next decode.

Once you have the significance map, then you decode each non-zero coefficient. This consists of 1 bit to indicate if the magnitude is is greater than one (this has its own context). If greater than one, then it uses a burst of unary encoding (up to some number of bits). Each of these, IIRC, also has its own context. If the value is still large, then it uses exponential Golomb. Finally there is a sign bit.

On encode there is no problem because you can quickly determine the sequence of bits and contexts to use just by knowing the magnitude of the value, but when decoding you have to read each bit in turn and interpret it to decide how to decode the next bit.

In general, AC is more expensive on the decode,

CABAC only uses binary, so, AFAICS, its AC decode is about the same cost as encode.

Arithmetic encoding could theoretically have any compression ratio (if youre doing it analytically), but the problem is that you need to store finite precision values.

I think it keeps a window of about 7 (or maybe 8) bits hence I chose to stay under 128* expansion. Again, it is unlikely but technically possible to get such high rates of compression/decompression, at least in localised areas.

 

[Bohdy]

Such a misguided perspective as to the quality of AVC/H.264 from some people here.

Go to doom9.org, or better yet grab x264 (open source AVC encoder) and try some encoding yourself, and that confusion should disappear. I've used AVC, VC-1, etc, and a good implementation of AVC is by far the most powerful. Don't look at commercial encodes held back by immature encoders and hardware constraints that show just a fraction of the standard's potential and go on to condemn it.

AVC does have one "flaw" which has been noted however, and I should mention it, which is that it poorly preserves high-frequency noise like grain. I personally don't consider it much of a flaw, but that is the reason that the supplement of FGM (Film Grain Modeling) was invented.

I have no doubt that AVC will come into the fore once the implementation and tools are sufficiently mature, as the technology is there and well ahead of anything else.

 

[randycat99]

I'm assuming the inquiry behind the discussion topic is hypothetical? It will be a rare situation where the entire bitrate of the media would be devoted to just video, anyway. You have to remember that these new hd formats were designed not only to deliver one video and one audio track, but also interleave multiple language audio tracks and simultaneous IME programs along with the movie. A BR movie may also utilize fully uncompressed PCM audio tracks to go with a movie. Added to together, this can amount to a pretty hairy aggregated bitrate, and that is a motivation behind BR being designed with this bandwidth- to stream any number of advanced feature elements along with the main movie. It's not there just for a single video stream.

 

[patsu]

For me, I'm just curious how far the Cell architecture can go when applied to real world problems. ^_^

 

[hey69]

VC-1 on BD

.........Warner just confirmed for me that of their second wave of BD titles, Full Metal Jacket will be the only one that uses MPEG2. Lethal Weapon, Blazing Saddles, and Firewall will all be encoded using VC1.
.......

http://www.hometheaterspot.com/htsthreads/showflat.php/Cat/0/Number/808299/Main/808299/#Post808299

 

[Shifty Geezer]

About time too! If true.

 

[one]

Sorry for a bump but hey.
http://www.avsforum.com/avs-vb/showthread.php?p=8883546&&#post8883546

One thing to add about PS3 BD playback performance.

I fed CEDIA give-away disc which contains 40Mbps MPEG4-AVC streams and PS3 just played them flawlessly, without any stuttering, frame drops nor PQ degradation, even though I saw instantaneous bitrate exceeding over 50Mbps in some spots.

The suspicious about PS3's AVC playback performance just gone.

 

[avaya]

It's nice to have confirmation but was there anyone apart from Deadmeat and his minions who seriously doubted that PS3 could handle full bit-rate AVC?

 

[Rolf N]

It's nice to have confirmation but was there anyone apart from Deadmeat and his minions who seriously doubted that PS3 could handle full bit-rate AVC?

The reassuring thing here is that those are <15% of the votes. Reason is still strong with these forums.