Hi Mateus,
You're right that the literal output of the inverse DCT is
saturated to
the range [-256 .. 255]. MPEG-2 pt. 2 calls this the
"transform data,"
f[y][x]. See clause 7.5.
Meanwhile, the motion vectors are applied to other pictures
to produce
blocks of "prediction samples," p[y][x].
The "final decoded samples," d[y][x], are computed
by adding together
f[][] and p[][] and then clipping to the range [0 .. 255].
See clause
7.6.8.
The output of mpeg2_idct_add...() isn't the transform data
f[][] -- it's
the final decoded samples d[][], after adding in the
prediction samples.
So that's why it's okay to clip to [0 .. 255].
I think mpeg2_idct_copy...() is the same deal, except you
use it in cases
without any prediction samples to add in (i.e. an
intra-coded block). But
its output is still d[][], not f[][], so that's why the
output is clipped
to be positive.
Best,
Keith
On Wed, 16 Apr 2008, Mateus Krepsky Ludwich wrote:
> Hello,
> I have a doubt about the "dest" parameter
in mpeg2_idct_copy and
> mpeg2_idct_add functions: according to IEEE STD 1180
the output of IDCT
> after
> clipping must be in range (-256, 255), i.e. 9 bits. The
dest parameter is a
> array of uint8_t, range(0, 255). How it can be? If is
used another variable
> that
> indicates the signal, with 8 bits we can represent
(-255, 255) even in this
> case
> the number -256 can't be represented. Someone can help
me here?
>
> Greetings,
>
> Mateus Krepsky Ludwich.
>
------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference
Don't miss this year's exciting event. There's still time to
save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Libmpeg2-devel mailing list
Libmpeg2-devel lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmpeg2
-devel
|
