I am trying to read the header of several QuickTime files that appear to use zlib compression, but I'm running into a bit of a snag. Using the fantastic reference page
http://wiki.multimedia.cx/index.php?title=Apple_QuickTime#Decompressing_Compressed_moov_Atoms_With_zlib
I have been able to read the following aspects of the movie header which indicate that the header is compressed using zlib:
4 bytes
4 bytes: "moov"
4 bytes
4 bytes: "cmov"
4 bytes
4 bytes: "dcom"
4 bytes: "zlib" (the compression type)
4 bytes
4 bytes: "cmvd"
4 bytes: uncompressed size
According to the reference, the next sequence of bytes will represent the actual moov header in compressed form; by running it through zlib decompression, I should be able to extract the various aspects of the header. However, when I feed the compressed data into a zlib decompressor (I happen to be using Python), the zlib engine fails with an error saying that there was an error processing the stream. When I examined the first few bytes of the stream, I found that they did not match the typical magic number for a zlib-compressed chunk of data (PK\003\004, which translates to 50 4b 03 04). The first four bytes of data in my file immediately following the uncompressed size are x\234\264\233, which translates to 78 9c b4 9b. The 4-byte uncompressed size seems about right since it's roughly double the compressed size, so I believe that I am reading the compressed data chunk from the right location of the file.
I thought it might be using a different sort of compression like "adec", but my file clearly says it is using "zlib". I also thought there may be an endian issue since my header has b4 in the 3rd position, while zlib magic number has 4b in the 2nd position, but no luck. No matter what I try, I can't seem to find a way to inflate the compressed data.
