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;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Libmpeg2-devel mailing list Libmpeg2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
