Number of IDCTs for MPEG?

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

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.

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