[Ffmpeg-devel] DCT data

Michael Niedermayer michaelni
Mon Feb 19 12:44:11 CET 2007


Hi

On Mon, Feb 19, 2007 at 08:33:08AM +0100, paolo mosna wrote:
> Hi all,
> 
> I'm having strange problem extracting DCT data from an AVFrame structure.
> I have activated DCT debug with option FF_DEBUG_DCT_COEFF.
> Attribute dct_coeff of AVFrame is filled with data but I'm not sure how DCT
> data
> are stored inside this array.
> 
> Looking inside method "static av_always_inline void
> MPV_decode_mb_internal(MpegEncContext *s, DCTELEM block[12][64], int
> lowres_flag)"
> where dct_coeff array is filled with data, it seems to me that for Y
> (luminance) component, the first 4*64 short values represents 4 sub-blocks
> of 8x8 pixels
> of Y chromatic component.
> Respectively, if considering all those together, the first 64 shorts are for
> the upper left 8x8 block, the second 64 blocks for the upper right 8x8
> block, the third 64 short values
> are for bottom left 8x8 block and finally last forth 64 short values are for
> the bottom right 8x8 block. Remaining 64*2 short values represents 8x8 block
> data for chrominance components
> Cr and Cb. So I skip them for the moment.
> 
> Here the problem is how to verify DCT data once extracted with the
> aforementioned logic.
> I thought to apply idct on extracted data to rebuild the original Y frame.
> Unfortunately what it happened is that I'm no more able to re-obtain the
> original Y matrix until
> I do not reach the 10th frame of the sequence? I really do not why I'm
> having this behavior.
> 
> Does anybody have a clues about how DCT coeffs are stored in dct_coeff
> array?
> So I can resolve the rebus?

if your video is not intra only (when in doubt it isnt) then the dct coeffs
are differences from a motion compensated previous frame

to reconstruct the frame you will have to implement half a mpeg decoder

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070219/46ff22a7/attachment.pgp>



More information about the ffmpeg-devel mailing list