Hi I'd appreciate a sanity check on my back-of-the-envelope calculation of the number of IDCTs needed in an MPEG decode. If we have PAL 704x480 at 25 fps divided into 16x16 macroblocks, then we have 1320 macroblocks. If we are using YUV422 then each 16x16 macroblock has 4 8x8 blocks for Y and 2 each 8x8 block for U and V. If we do 8x8 IDCTs using a 1D 8-point IDCT then for each 8x8 block we do 8 IDCTS for the rows plus 8 for the columns, making a total of 16 IDCTs. We have a total of 8 8x8 blocks (for the Y and the UV) so we must do 16 * 8 = 128 IDCTs per 16x16 macroblock. So we need 1320 * 128 = 168960 IDCTs per frame. And at 25 fps we need 16890 * 25 = 4,224,000 IDCTs per second. This would be on an implementation that did not try to avoid doing the IDCTs by some trick. I didn't find a literature reference that quotes this figure, or derives it like this, so I'd be grateful if anyone can verify it is about right. Thanks, Chris Bore ================== www.bores.com

# Number of IDCTs for MPEG?

Started by ●February 12, 2008

Reply by ●February 12, 20082008-02-12

On 12 Feb., 14:07, Chris Bore <chris.b...@gmail.com> wrote:> Hi > > I'd appreciate a sanity check on my back-of-the-envelope calculation > of the number of IDCTs needed in an MPEG decode. > > If we have PAL 704x480 at 25 fps divided into 16x16 macroblocks, then > we have 1320 macroblocks. > > If we are using YUV422 then each 16x16 macroblock has 4 8x8 blocks for > Y and 2 each 8x8 block for U and V. > > If we do 8x8 IDCTs using a 1D 8-point IDCT then for each 8x8 block we > do 8 IDCTS for the rows plus 8 for the columns, making a total of 16 > IDCTs. > > We have a total of 8 8x8 blocks (for the Y and the UV) so we must do > 16 * 8 = 128 IDCTs per 16x16 macroblock. > > So we need 1320 * 128 = 168960 IDCTs per frame. > > And at 25 fps we need 16890 * 25 = 4,224,000 IDCTs per second. > > This would be on an implementation that did not try to avoid doing the > IDCTs by some trick. > > I didn't find a literature reference that quotes this figure, or > derives it like this, so I'd be grateful if anyone can verify it is > about right. > > Thanks, > > Chris Bore > ==================www.bores.comThat seems about correct for me. But then why care about the low rate of 4.2e6 IDCTs/s? I guess one could easily achieve 100e6 IDCTs/s (pipelined) with a fraction of a low cost fpga, and again less area adapting it for the low rate. And the other work of MPEG decoding needs far more resources than the IDCTs.

Reply by ●February 13, 20082008-02-13

On 12 Feb, 13:44, filter...@desinformation.de wrote:> On 12 Feb., 14:07, Chris Bore <chris.b...@gmail.com> wrote: > > > > > > > Hi > > > I'd appreciate a sanity check on my back-of-the-envelope calculation > > of the number of IDCTs needed in an MPEG decode. > > > If we have PAL 704x480 at 25 fps divided into 16x16 macroblocks, then > > we have 1320 macroblocks. > > > If we are using YUV422 then each 16x16 macroblock has 4 8x8 blocks for > > Y and 2 each 8x8 block for U and V. > > > If we do 8x8 IDCTs using a 1D 8-point IDCT then for each 8x8 block we > > do 8 IDCTS for the rows plus 8 for the columns, making a total of 16 > > IDCTs. > > > We have a total of 8 8x8 blocks (for the Y and the UV) so we must do > > 16 * 8 = 128 IDCTs per 16x16 macroblock. > > > So we need 1320 * 128 = 168960 IDCTs per frame. > > > And at 25 fps we need 16890 * 25 = 4,224,000 IDCTs per second. > > > This would be on an implementation that did not try to avoid doing the > > IDCTs by some trick. > > > I didn't find a literature reference that quotes this figure, or > > derives it like this, so I'd be grateful if anyone can verify it is > > about right. > > > Thanks, > > > Chris Bore > > ==================www.bores.com > > That seems about correct for me. > > But then why care about the low rate of 4.2e6 IDCTs/s? > I guess one could easily achieve 100e6 IDCTs/s (pipelined) with a > fraction of a low cost fpga, and again less area adapting it for the > low rate. > And the other work of MPEG decoding needs far more resources than the > IDCTs.- Hide quoted text - > > - Show quoted text -Thank you for the helpful reply. My aim is to show how the estimates can be made of processing for each step. What would you think typically dominates MPEG decoding? Chris