RE: Re: ISFT

Hi Cyrius,

That's very helpful. Thanks a lot.

Adam


> -----Original Message-----
> From: Cyrius [mailto:[email protected]]
> Sent: Thursday, March 27, 2003 10:39 AM
> To: Adam Li; [email protected]
> Subject: Re: [Virtualdubmod-devel] 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