[FFmpeg-devel] VQA v3 GSoC questions, need help

Vitor Sessak vitor1001
Sun Mar 29 23:03:02 CEST 2009

Vitor Sessak wrote:
> The Deep Explorer wrote:
>>> The demuxer has to recognize the chunks to know if it is audio or 
>>> video and
>>> send it to the right decoder. When the demuxer 
>>> (libavformat/westwood.c) find
>>> a chunk it does not know, it just skip it, and it is what it is doing 
>>> for
>>> VQFR chunks. Those chunks have to be send by the demuxer to video 
>>> decoder
>>> (and the decoder should be modified to be able to decode them). So you
>>> should also do a few modifications to libavformat/westwood.c .
>>> -Vitor
>> The VQFR chunk is getting detected in the wsvqa_read_packet where it
>> detects the other snd tags.
> Yes, I got confused. Indeed the current code already detect VQFR tags. 
> What I said applies to the VQFL tag.
>> In the  wsvqa_read_header where it catches the unknown types I added the
>> VQFL_TAG it is able to find it. What does this mean ? That in the
>> header these is a VQFL
>> and within which the first CBFZ is located ? If so how do I pass that
>> data to the decoder ?

I've given a look at nodlogo.vqa in a hexeditor. In the first few 
frames, there is no VQFL tag. So to begin you could try first to 
correctly decode the VQFFR frames. The decoder by now detect fine the 
CBFZ sub chunks...

> "VQFL" is a chunk tag
> "CBFZ" is a _sub_ chunk tag. So it should be _inside_ other chunks (and 
> since chunks are passed to the decoder, they should be handled in the 
> decoder not the demuxer)
>> So what do I need to change in the demuxer that it passes all the
>> right data to the decoder?
> The demuxer should do the same thing to VQFL chunks as it does now to 
> VQFR tags (passing it to the video decoder).

Just to add to what I say, this is not needed for the few first frames 
of this file

>> <<DEEP inside after avctx->codec->init
>> [wsvqa @ 0x88b7ad0]Skipping unknown chunk 0x534E324A
>>     Last message repeated 28 times
>> [wsvqa @ 0x88b7ad0]FOUND VQFL_TAG
>> [wsvqa @ 0x88b7ad0]Skipping unknown chunk 0x534E324A
>>     Last message repeated 16 times
>> In the vqavideo.c , where it parses the different chunk,
>> I added VPRZ_TAG and it is being detected.
>> It does detect the CBFZ tag as well and depending on the first byte
>> value decoding will take place.
>> However it does not find any VPTZ chunk and hence does not do the 
>> decoding.
> Not surprising. VQA v3 files have none. Please take a moment to glance 
> at the file in a hex editor. It will make clearer what tags the decoder 
> or demuxer can/should find. So the decoder shouldn't print an error when 
> it doesn't find such chunk.

By what I saw in the hex editor, what is missing in for nodlogo.vqa is 
to correctly handle VPRZ subchunks.

>> I am not being able to understand the decoding scheme for V3 , This is
>> what I have surmised so
>> far ( all from the document ) :
> I'm not really familiar with the format, so I hope someone who is can help you... 

Just my guess:

> 1) A CBFZ chunk is a codebook and the number of frames using it is
> given by the CBParts entry but it
>    is going to be the same value for the whole movie, ie. if it 10 it
> is going to be 10 frames apart.
>  I see one big CBFZ chunk getting detected and then much smaller
> VPRZ_TAG , which makes sense since it is  the codebook.
>  However I checked the CBPart , it was set to 0 . Where am I getting it wrong ?

My guess is that a file that never uses any CBP? tag do not need this 
value. It will just use a full codebook until the next is read.

> 2) First CBFZ chunk is inside the VQFR chunk ( the demuxer actually
> detects the VQFR chunk so are we fine in that
>     we dont need to modify the demuxer in westwood.c ?)

I don't think any modification is needed for these.

> 3) How do I find the VPTZ  and VQFL chunks?

In the file I saw, there is no VPTZ and few VQFL.

> 4) How do I find the VPRZ chunks ? ( how to decode it is explained in the doc)

Quoting one of yours previous messages:

> [vqavideo @ 0x88c0d70]  VQA video: Found unknown chunk type: VPRZ (5650525A)


More information about the ffmpeg-devel mailing list