Playing .264 files not working

[ljx34]

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.

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?

[abolibibelot]

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.

Perhaps this :
http://www.technosoft.ro/KB/index.php?/article/AA-15440/0/The-negative-numbers-represe...on-in-hex.html
https://programmersheaven.com/discussion/222634/negative-numbers-in-hexadecimal
(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?

Well, any file can have any extension, and a file with a given extension does not necessarily contain the expected content usually associated with said extension...
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.