[FFmpeg-devel] GSoC Qual VQA v3 : patch updated

[Michael Niedermayer]

On Mon, Apr 13, 2009 at 02:26:27PM -0400, The Deep Explorer wrote:
> >
> > I see nothing unclear in the desription of the algo on the wiki.
> 
> If you kindly point where is the algo for the vector index mechanism for V3 :(,

copy & pasted off the wiki:
The VPTR chunks

These chunks use some sort of differential, run-length algorithm that only records changes from the previous frame. Therefore, the previous frame bitmap must be maintained throughout all the frames (you could just draw the blocks that changed, though). This makes dropping frames (in case of bad performance) impossible. 

When decoding, you take a short int (Intel) from the chunk and examine its 3 most significant bits (bits 15,14,13). These bits make up a code prefix that determines which action is to be done. 

Here's a list of the prefixes I encountered and their description (Val is the short int value): 

 BITS - MEANING

  000 - Skip Count blocks. Count is (Val & 0x1fff).

  001 - Write block number (Val & 0xff) Count times.
        Count is (((Val/256) & 0x1f)+1)*2. Note that this can only
        index the first 256 blocks.

  010 - Write block number (Val & 0xff) and then write Count blocks
        getting their indexes by reading next Count bytes from
        the VPTR chunk. Count is (((Val/256) & 0x1f)+1)*2.
        Again, the block numbers range from 0-255.

  011 - Write block (Val & 0x1fff).

  101 - Write block (Val & 0x1fff) Count times. Count is the next
        byte from the VPTR chunk.

After this, you take the next short int and repeat the above process. 

Every row of blocks is processed individually of others. When you encounter the end of a row, proceed to the next row (blocks are processed left to right, top to down). Repeat this process until all blocks in the frame are covered and that's it! 

Note that the above implies an absolute maximum of 8192 blocks (0x1fff+1). Also note that prefix 100 is unused (at least in Tiberian Sun) but could be used somewhere else...? 

As for the VPRZ chunks, these are just VPTR chunks compressed with the standard Format80 algorithm. 

----------------


> 
> >
> >
> > [...]
> >> +static void vqa_decode_vptr(const unsigned char *src, int src_size,
> >> +    unsigned char *dest, int dest_size)
> >> +{
> >> +    int src_index = 0;
> >> +    int dest_index = 0;
> >> +    short int code_buf = 0;
> >> +    short int code = 0;
> >> +    int block_no = 0;
> >> +    int count = 0;
> >> +    int index = 0;
> >> +
> >> +    while (src_index < src_size) {
> >> +        memcpy(&code_buf, &src[src_index], 2);
> >> +        code = code_buf >> 13;
> >
> > this code makes no sense.
> >
> 
> reading the two bytes , then shifting it right 13 bits so that I have
> the bits 15,14,13 in 2,1,0

kostya already explained that you cannot do it that way.
Its basic C knowledge, to know how to read 2 bytes or how to read a littele
endian 16bit value.


> >
> >> +        code = code & 0x0007;
> >> +
> 
> Then I am masking out the rest to get the code...
> >> +        switch (code) {
> >> +
> >> +        case 0:
> >> +            count = code_buf & 0x1ff;
> >> +            dest_index += count;
> >> +            break;
> >> +        case 1:
> >> +            block_no = code_buf & 0x1ff;
> >> +            count = (((code_buf / 256) & 0x1f) + 1) * 2;
> >> +            for (index = 0; index < count; index++)
> >> +                dest[dest_index + index] = block_no;
> >> +            dest_index += index;
> >
> > this as well makes no sense, and i guess i could repeat that comment
> > a few more times
> >
> 
> Please then explain what would make sense ...

Its your job to write functioning code not ours, after all thats a
qualification, that is we want to find out if you can do it not if we
can do it.
In the actual SOC project in summer we of course would (or should at least)
be more helpfull

Anyway i can clarify what makes no sense, lets say putting 9 bits in 8 but
thats just part of it.


> 
> Write block number (Val & 0xff) Count times.
>          Count is (((Val/256) & 0x1f)+1)*2. Note that this can only
>          index the first 256 blocks.
> 
> As per the document, I found the block no, wrote it to the dest buff
> count times...

uhm
a little bit of common sense is helpfull, really

The text
"       Write block number (Val & 0xff) Count times.
        Count is (((Val/256) & 0x1f)+1)*2. Note that this can only
        index the first 256 blocks.
"
does not mean
"Write block_number X"
but
"Write the block with number X"
or shorter
"Write block, number X"


> I think may be I am getting it totally wrong ,

yes, that is an excelent summary


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

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090413/e90f5a04/attachment.pgp>