Re: Re: ISFT

> Adam Li wrote:
> 
> >Hi Christian,
> >
> >I am not sure if someone has brought this up. I am
> pasring some AVI file
> >generated with 1.4.13. It seems that the size of
> the ISFT chunk in the
> >INFO list is off by 1 byte. The length really
> should be 0x16, but in thecc
> >file it is 0x15. It is probably caused by the '\0'
> at the end of the
> >string.
> >
> >Hope it would be helpful.
> >
> >Adam
> >  
> >

Hi

Actually this is not an error.
I had a look at the VirtualDub code that write those
kind of data in the file and noticed this :
When writing a chunk in the file VirtualDub write
first the ID (FourCC code) of the chunk, then the size
of the chunk (the real size), and the data to write in
the chunk.
But if the actual size of the data is odd then it pads
the chunk with an extra 0x00 byte.
Similarly when parsing an AVI file VirtualDub read the
chunk ID, then its size, add 1 to this size when it is
odd and then read the data in the chunk (with its size
corrected). So VirtualDub has no problems reading back
the file (since it takes into account the padding).

So I wondered why this padding (I didn't know that
RIFF specs need a WORD - 2 bytes - alignment) and also
why AVI parsers hadn't problems with the generated
file.
After a quick search on the Net I find an old tool
previously bundled with the Windows SDK and called
RIFFWALKER. I tested generated files with it and
indeed without this padding the program complains and
doesn't read correctly the file (it goes always 1 byte
too far when the size of a chunk is odd and that there
is no padded 0x00 byte).
So I decided to search for RIFF specs since it
obviously appeared that a WORD aligment was needed
(alignment that I wasn't aware of).

I found this :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/avirifffilereference.asp
and as you can read a RIFF file must be WORD aligned,
meaning that if the actual size of a chunk is odd,
then this chunk must be padded with an extra 0x00 byte
...
In other words when we write the name of the software
("VirtualDubMod 1.4.13", which represents 21 bytes,
including the ending 0x00 byte - end-of-string) the
chunk header tell you there are 21 bytes but actually
22 bytes are written (because we pad the chunk with an
extra 0x00 byte).

Here is the interesting part of the page I gave the
link :
"A chunk has the following form: 
ckID ckSize ckData

where ckID is a FOURCC that identifies the data
contained in the chunk, ckData is a 4-byte value
giving the size of the data in ckData, and ckData is
zero or more bytes of data. The data is always padded
to nearest WORD boundary. ckSize gives the size of the
valid data in the chunk; it does not include the
padding, the size of ckID, or the size of ckSize."

Best regards
Cyrius

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en