I basically just took the next 2 bytes after ITKV and then little endian > decimal. I had it print all the chunk lengths to console and what is strange is that sometimes after converting to decimal it converts it to a negative number, so I had to include a check to make sure it's more than 0 before going on with the rest of the code.. but maybe there is something to that that I'm not seeing. I will continue to look today, would be nice to make a complete solution for all 264 files. I have checked on some other h264 files(not from my camera) and see no ITKV or HXVF so not sure why that is either. is h264 and 264 different?Some parts of the code are pretty straightforward, even with no prior knowledge of the Python code, but how exactly did you calculate the size of the chunks ? The length of the size field is at least two bytes, but it could be four, and therefore there could be chunks bigger than what can be coded with two bytes, which is FF FF = 65536. I just checked with Calc and the ITKV text file posted earlier : I don't see any larger than 65536, but there are many (apparently 1 in 18) about 10 times larger than the majority, with a size of about 40000 bytes. For instance, is the chunk starting at 55719 (ITKV header at 55703) extracted with a size of B3 32 = 45874 ?
Or another method, if the current code works for audio, would be to output all that remains once the audio part has been extracted.
+ Reply to Thread
Results 31 to 32 of 32
I basically just took the next 2 bytes after ITKV and then little endian > decimal. I had it print all the chunk lengths to console and what is strange is that sometimes after converting to decimal it converts it to a negative number, so I had to include a check to make sure it's more than 0 before going on with the rest of the code.. but maybe there is something to that that I'm not seeing.
(I don't know much about that, but had to look into this some months ago for a totally unrelated issue an attempt to manually recover a file which was wiped to 0 byte because of a NTFS SNAFU, and could not be recovered by R-Studio or WinHex, by directly examining its MFT records ; it proved unfruitful as the end of the file had been overwritten in the mean time it was my e-mail inbox, I had a backup a few days old so it wasn't a disaster but the part that was missing and which I hoped to reconstruct that way, corresponding to the newly received messages, was precisely at the end of the file , yet at least I learned how it works, i.e. how the exact locations of each segment of each file are coded in the MFT.)
Perhaps by taking the next 4 bytes after ITKV it would interpret those problematic values differently (the binary representation will not start with 1). Or perhaps there's a command switch in Python to differentiate "signed" and "unsigned" numbers.
From WinHex's integrated help :
Integer Data Types Format/Type Range Example signed 8 bit -128...127 FF = -1 unsigned 8 bit 0...255 FF = 255 signed 16 bit -32,768...32,767 00 80 = -32,768 unsigned 16 bit 0...65,535 00 80 = 32,768 signed 24 bit -8,388,608...8,388,607 00 00 80 = -8,388,608 unsigned 24 bit 0...16,777,215 00 00 80 = 8,388,608 signed 32 bit -2,147,483,648...2,147,483,647 00 00 00 80 = -2,147,483,648 unsigned 32 bit 0...4,294,967,295 00 00 00 80 = 2,147,483,648 signed 64 Bit -2^63...2^63-1 00 00 00 00 00 00 00 80 = -2^63 Unless stated otherwise, multi-byte numbers are stored in little-endian format, meaning that the first byte of a number is the least significant and the last byte is the most significant. This is the common format for computers running Microsoft Windows. Following the little-endian paradigm, the hexadecimal values 10 27 can be interpreted as the hexadecimal number 2710 (decimal: 10,000).I have checked on some other h264 files(not from my camera) and see no ITKV or HXVF so not sure why that is either. is h264 and 264 different?
Usually, as it's been alluded to in the first few posts on the first page, .h264 or .264 files are elementary streams of H.264 video, so just a raw stream with no container structures, it has to be muxed into a standard container (typically MP4 or MKV) for most players to recognize them as video. But this is a proprietary format, and those files obviously contain both video and audio, so it's probably not similar to those other "h264" files you examined.