Playing .264 files not working

[ljx34]

I have a .264 file from an IP cctv camera, it's a cheap chinese one, the .264 file contains audio aswell which is weird because I have read that 264 files are raw video files.

I have tried on many different players, VLC, PotPlayer, KMplayer, tried using FFmpeg, nothing has worked, I can extract the video out of it using some convert tool I found online here: https://www.spitzner.org/kkmoon.html, which gives an mp4 file, that if I then use FFmpeg on it, it gives me a workable video file. However, the file that I created out of the convert tool, if I play it with windows media player, it gives me 6hours of audio(I'm sure this isn't correct) as they are like 30-50mb files and the actual video lengths are 10-15minutes each, however, it is the correct audio, I'm just not how whats going on that its stretching it to 6hours, if I changed that converted file name to .aac and then played it with VLC, the audio is about 6mins long, too short. I am so confused.

I have uploaded a sample here:

https://anonfiles.com/P8u0n3Mcn1/P200109_164544_165544_264

If anybody can actually get a method to play this with audio I will be forever grateful.

[johns0]

Your sample doesn't play properly,has no audio,can you upload an uncut video?Limit here is 500Mb.

[ljx34]

That is an uncut and complete file.

Well, it won't play without doing something to it, thats my issue, it does have audio, it's just embedded in some way.

If you try using that convert.exe tool on it from https://www.spitzner.org/kkmoon.html, it gives a file that has audio, I will upload a sample converted file.

The attached file plays audio when opening with windows media player. You can ffmpeg on this file and it will output a file that plays video but no audio. It's all very strange.

[johns0]

Doing all that to get hidden audio that's put that way on purpose isn't worth it to me ,better to get a camera that gives you straight h264 with no needing to fix it.

[ljx34]

Very true, but there is a long story behind this, this isn't my camera, its a friend of mines, and there was a police matter that was caught on one of these cameras but it needs the audio.

[dvd_kosher]

I used Zamzar online file converter to convert the original .264 file to .avi. The result was a 99 MB video file that was like ten minutes long with still no audio. Even converting to .mp4 is same length video also no audio.

[Atak_Snajpera]

Most likely audio is stored in separated file. Files with .264 extensions often mean that it is a raw video stream only.

[ljx34]

Most likely audio is stored in separated file. Files with .264 extensions often mean that it is a raw video stream only.

But it isn't stored in a seperate file, thats what I said before, the audio is in the file and you can get it by doing the methods I described :/

Is it possible that the camera creators have just taken the .264 file and then added a aac file onto the end of the video file?

[El Heggunte]

@ljx34: the error messages returned by MPlayer convinced me that your friend's camera creates borked files...
The sample .MP4 you uploaded to this thread was multiplexed very-wrongly...

As a last (and only?) resort, you might record "What U Hear" from the Windows Media Player output, save as an AAC stream and then add this latter to the video

[ljx34]

@ljx34: the error messages returned by MPlayer convinced me that your friend's camera creates borked files...
The sample .MP4 you uploaded to this thread was multiplexed very-wrongly...

As a last (and only?) resort, you might record "What U Hear" from the Windows Media Player output, save as an AAC stream and then add this latter to the video

Yea, I have considered that option but the problem is windows media player is saying the audio is 6hours long for whatever reason, I can't match that to a 10minute video, I have tried to see if the audio just repeats itself for 6hours but it doesn't, I think its some weird seeking issue. I have tried letting it play but its very hard to figure out a start and end point when it's just bird noises aswell. I honestly can't wrap my head around all this weirdness, I'm usually pretty good at fixing this kind of stuff but yea.

Seems I'm all out of options, it's strange because the video files play fine along with the audio when the SD card is plugged into the camera and you connect from the provided app, I just don't have the chance to use the camera atm as my friend is on holiday, I will just have to wait.

[abolibibelot]

Weird indeed...

VLC Media Player doesn't read it indeed, but SMPlayer plays the video straight away (only with a “00:00:00” duration, but there's a timestamp displayed on the video itself).
Tried mp4box : outputs many lines saying “[MPEG-2 TS] TS Packet XXX does not start with sync marker”, and can't remux the file.
Tried ffmpeg : indeed the file can be converted but only has a video stream.
Tried to remux the ffmpeg converted MP4 with mp4box, output has about the same size and it doesn't change anything.
Tried to scan the file as a raw device image with both R-Studio and Photorec, they found nothing (no known header).
TSMuxer crashes.
MKVToolNix detects a 27.3MB AAC audio stream, but then converts it (with no error or warning) as a 6.71MB MKA file — which is completely silent when played with VLC. O_o
Well, not exactly : there's some audible content here and there, for instance near 4m25s, but nothing identifiable.
MPlayer extracts a 0 byte audio stream and a 27.3MB video stream.
But Audacity can load the MKA created by MKVToolNix, the duration is 8m10, and the birds can be heard chirping. So by combining the MP4 video remuxed with ffmpeg and the MKA audio loaded into Audacity and exported as WAV or FLAC or AAC, it should be possible to get a playable video with audio, only problem is to get the correct synchronization since the durations don't match. The audio seems normal, so it should be obtained either by setting a delay, or by changing the framerate, or both ; perhaps 11FPS would work (5383 frames / 490 seconds = 10.98).
SMPlayer also recognizes the MKA audio correctly.

Général
Identifiant unique                       : 222556958592217758854793457599491381424 (0xA76EE93D17B9806527592F26A85C98B0)
Nom complet                              : H:\P200109_164544_165544.mka
Format                                   : Matroska
Version du format                        : Version 4
Taille du fichier                        : 6,71 Mio
Durée                                    : 9 min 38s
Débit global moyen                       : 97,4 kb/s
Date d'encodage                          : UTC 2020-01-18 00:13:47
Application utilisée                     : mkvmerge v35.0.0 ('All The Love In The World') 64-bit
Bibliothèque utilisée                    : libebml v1.3.9 + libmatroska v1.5.2

Audio
ID                                       : 1
Format                                   : AAC LC SBR
Format/Info                              : Advanced Audio Codec Low Complexity with Spectral Band Replication
Nom commercial                           : HE-AAC
Paramètres du format                     : Explicit
Identifiant du codec                     : A_AAC-2
Durée                                    : 9 min 38s
Débit                                    : 96,0 kb/s
Canaux                                   : 1 canal
Channel layout                           : C
Echantillonnage                          : 32,0 kHz
Images par seconde                       : 15,625 Im/s (2048 SPF)
Mode de compression                      : Avec perte
Taille du flux                           : 6,68 Mio (100%)
Default                                  : Oui
Forced                                   : Non

[aedipuss]

LOL if it's a police matter you can' t alter or convert the original files at all. not acceptable as evidence. otherwise you could add any audio you wanted.

[ljx34]

Weird indeed...

VLC Media Player doesn't read it indeed, but SMPlayer plays the video straight away (only with a “00:00:00” duration, but there's a timestamp displayed on the video itself).
Tried mp4box : outputs many lines saying “[MPEG-2 TS] TS Packet XXX does not start with sync marker”, and can't remux the file.
Tried ffmpeg : indeed the file can be converted but only has a video stream.
Tried to remux the ffmpeg converted MP4 with mp4box, output has about the same size and it doesn't change anything.
Tried to scan the file as a raw device image with both R-Studio and Photorec, they found nothing (no known header).
TSMuxer crashes.
MKVToolNix detects a 27.3MB AAC audio stream, but then converts it (with no error or warning) as a 6.71MB MKA file — which is completely silent when played with VLC. O_o
Well, not exactly : there's some audible content here and there, for instance near 4m25s, but nothing identifiable.
MPlayer extracts a 0 byte audio stream and a 27.3MB video stream.
But Audacity can load the MKA created by MKVToolNix, the duration is 8m10, and the birds can be heard chirping. So by combining the MP4 video remuxed with ffmpeg and the MKA audio loaded into Audacity and exported as WAV or FLAC or AAC, it should be possible to get a playable video with audio, only problem is to get the correct synchronization since the durations don't match.
SMPlayer also recognizes the MKA audio correctly. The audio seems normal, so it should be obtained either by setting a delay, or by changing the framerate, or both ; perhaps 11FPS would work (5383 frames / 490 seconds = 10.98).

Général
Identifiant unique                       : 222556958592217758854793457599491381424 (0xA76EE93D17B9806527592F26A85C98B0)
Nom complet                              : H:\P200109_164544_165544.mka
Format                                   : Matroska
Version du format                        : Version 4
Taille du fichier                        : 6,71 Mio
Durée                                    : 9 min 38s
Débit global moyen                       : 97,4 kb/s
Date d'encodage                          : UTC 2020-01-18 00:13:47
Application utilisée                     : mkvmerge v35.0.0 ('All The Love In The World') 64-bit
Bibliothèque utilisée                    : libebml v1.3.9 + libmatroska v1.5.2

Audio
ID                                       : 1
Format                                   : AAC LC SBR
Format/Info                              : Advanced Audio Codec Low Complexity with Spectral Band Replication
Nom commercial                           : HE-AAC
Paramètres du format                     : Explicit
Identifiant du codec                     : A_AAC-2
Durée                                    : 9 min 38s
Débit                                    : 96,0 kb/s
Canaux                                   : 1 canal
Channel layout                           : C
Echantillonnage                          : 32,0 kHz
Images par seconde                       : 15,625 Im/s (2048 SPF)
Mode de compression                      : Avec perte
Taille du flux                           : 6,68 Mio (100%)
Default                                  : Oui
Forced                                   : Non

You sir, are a legend.

[abolibibelot]

LOL if it's a police matter you can' t alter or convert the original files at all. not acceptable as evidence. otherwise you could add any audio you wanted.

Well, considering the general level of regular cops in such technical matters, unless that's a federal case this shouldn't be an issue !

You sir, are a legend.

I am humbled by dat.
(I would need to hear something like this on a regular basis for my self-esteem to reach a non-threatening level. é_è)

Actually, I checked again, the audio played in SMPlayer is 9m38s, so it may be already synchronized after all — well, almost, as the video is supposed to be 9m58s. I don't know why Audacity (through the ffmpeg import module) displays it as being shorter. You'll have to do some tests and see what works best.

If the MKA is converted to WAV with ffmpeg, the duration of the output is also 8m10s, and there are many warnings.

...
Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
[aac @ 00000000006637c0] invalid band type
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 2.8 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 2.1 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 2.3 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] Reserved bit set.
[aac @ 00000000006637c0] Number of bands (5) exceeds limit (3).
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 3.9 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 2.10 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 3.2 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] Reserved bit set.
[aac @ 00000000006637c0] Number of bands (40) exceeds limit (20).
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 00000000006637c0] Inconsistent channel configuration.
[aac @ 00000000006637c0] get_buffer() failed
Error while decoding stream #0:0: Invalid argument
[aac @ 00000000006637c0] channel element 2.1 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 3.15 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] Prediction is not allowed in AAC-LC.
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 00000000006637c0] Too large remapped id is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs,
 it means that your file has a feature which has not been implemented.
[aac @ 00000000006637c0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
[aac @ 00000000006637c0] channel element 2.9 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] Prediction is not allowed in AAC-LC.
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 3.1 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
[aac @ 00000000006637c0] channel element 3.13 is not allocated
Error while decoding stream #0:0: Invalid data found when processing input
size=   61208kB time=00:09:38.04 bitrate= 867.4kbits/s speed= 286x
video:0kB audio:61208kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000124%

Perhaps someone, somewhere, knows what it all means...

And mp4box refuses to remux the MKA file, with the same kind of error warnings as for the MP4 processed by ffmpeg.
But gMKVExtract extracts a 6.73MB AAC track. And now mp4box can remux this AAC track.
But that AAC track loaded into Audacity also has a duration of 8m10s...
I tried muxing the MP4 / AVC from ffmpeg with the MKV / AAC from MKVToolNix with MKVToolNix, setting the framerate to 9.31FPS (5383 / 578) : the resulting file has a matching duration of 9m38 for the video and audio streams, the audio is mostly silent in VLC Media Player, but it plays fine in SMPlayer. It seems about synchronized, judging from the Doopler effect of the cars passing by.

P200109_164544_165544 AVC ffmpeg + AAC MKVToolNix 9.31FPS.mkv

Général
Identifiant unique                       : 20841262181146544116170852363847900303 (0xFADE18F33E30C4903E694A01F809C8F)
Nom complet                              : H:\P200109_164544_165544 AVC ffmpeg + AAC MKVToolNix 9.31FPS.mkv
Format                                   : Matroska
Version du format                        : Version 4
Taille du fichier                        : 34,1 Mio
Durée                                    : 9 min 38s
Débit global moyen                       : 495 kb/s
Date d'encodage                          : UTC 2020-01-18 01:46:45
Application utilisée                     : mkvmerge v35.0.0 ('All The Love In The World') 64-bit
Bibliothèque utilisée                    : libebml v1.3.9 + libmatroska v1.5.2

Vidéo
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Profil du format                         : Main@L4.1
Paramètres du format                     : CABAC / 1 Ref Frames
Paramètres du format, CABAC              : Oui
Paramètres du format, RefFrames          : 1 image
Identifiant du codec                     : V_MPEG4/ISO/AVC
Durée                                    : 9 min 38s
Débit                                    : 397 kb/s
Largeur                                  : 1 920 pixels
Hauteur                                  : 1 080 pixels
Format à l'écran                         : 16/9
Type d'images/s                          : Constant
Images par seconde                       : 9,310 Im/s
Images/s d'origine                       : 9,000 Im/s
Espace de couleurs                       : YUV
Sous-échantillonnage de la chrominance   : 4:2:0
Profondeur des couleurs                  : 8 bits
Type de balayage                         : Progressif
Bits/(Pixel*Image)                       : 0.021
Taille du flux                           : 27,3 Mio (80%)
Default                                  : Oui
Forced                                   : Non

Audio
ID                                       : 2
Format                                   : AAC LC SBR
Format/Info                              : Advanced Audio Codec Low Complexity with Spectral Band Replication
Nom commercial                           : HE-AAC
Paramètres du format                     : Explicit
Identifiant du codec                     : A_AAC-2
Durée                                    : 9 min 38s
Débit                                    : 96,0 kb/s
Canaux                                   : 1 canal
Channel layout                           : C
Echantillonnage                          : 32,0 kHz
Images par seconde                       : 15,625 Im/s (2048 SPF)
Mode de compression                      : Avec perte
Taille du flux                           : 6,68 Mio (20%)
Default                                  : Oui
Forced                                   : Non

[aedipuss]

LOL if it's a police matter you can' t alter or convert the original files at all. not acceptable as evidence. otherwise you could add any audio you wanted.
Well, considering the general level of regular cops in such technical matters, unless that's a federal case this shouldn't be an issue !

good luck with that. prosecutors aren't beat cops.

[babygdav]

https://forum.videohelp.com/threads/341325-264-file-extension-Can-t-convert-using-h264-methods

[ljx34]

LOL if it's a police matter you can' t alter or convert the original files at all. not acceptable as evidence. otherwise you could add any audio you wanted.
Well, considering the general level of regular cops in such technical matters, unless that's a federal case this shouldn't be an issue !

good luck with that. prosecutors aren't beat cops.

Regardless, the guy is helping me, relax.

My sister was attacked with a car, litteraly run over by some crack addict ex girlfriend of my sisters current boyfriend.. so I need this footage as good as I can get it to be honest, even if it doesn't do justice with the police, it should do justice on social media about this girl(not sure if I'm going to go down that route yet).

[ljx34]

Well, this sucks, seems as though the file I uploaded when loaded into MKVtoolnix does provide an AAC file, but the one I need when added only provides a video file.. bad times. I guess the headers are so ****ed around that some will be noticed as an AAC, some as straight 264.

Is there no tool that can extract anything that looks like aac from the file and extract it.

[abolibibelot]

Well, this sucks, seems as though the file I uploaded when loaded into MKVtoolnix does provide an AAC file, but the one I need when added only provides a video file.. bad times. I guess the headers are so ****ed around that some will be noticed as an AAC, some as straight 264.

What's odd (among other things) is that the second file (with the MP4 extension) is recognized by MKVToolNix as AAC audio, but the first file from the first post (.264 extension) is recognized as AVC video. If I understood correctly the second file was converted from the first one (supposedly the raw / native file) by that converter.exe tool ; so what happens when you process the file of interest with converter.exe, then load the output into MKVToolNix ?

Is there no tool that can extract anything that looks like aac from the file and extract it.

Normally MPlayer should be able to extract anything recognized as video with

mplayer [input.ext] -dumpvideo -dumpfile [video.264]

and anything recognized as audio with

mplayer [input.ext] -dumpaudio -dumpfile [audio.aac]

(with the relevant extensions depending on the format of the source, although it shouldn't affect the output)
but in this case the audio command doesn't work (0 byte output).
Problem is, without a proper header, and a reader able to deal with said header, binary data from an audio file or a video file is barely distinguishable from a random stream of bytes...

My sister was attacked with a car, litteraly run over by some crack addict ex girlfriend of my sisters current boyfriend..

Damn, this world is looking more and more like George Carlin's doomsday scenario...

[ljx34]

Well, this sucks, seems as though the file I uploaded when loaded into MKVtoolnix does provide an AAC file, but the one I need when added only provides a video file.. bad times. I guess the headers are so ****ed around that some will be noticed as an AAC, some as straight 264.

What's odd (among other things) is that the second file (with the MP4 extension) is recognized by MKVToolNix as AAC audio, but the first file from the first post (.264 extension) is recognized as AVC video. If I understood correctly the second file was converted from the first one (supposedly the raw / native file) by that converter.exe tool ; so what happens when you process the file of interest with converter.exe, then load the output into MKVToolNix ?

Is there no tool that can extract anything that looks like aac from the file and extract it.

Normally MPlayer should be able to extract anything recognized as video with

mplayer [input.ext] -dumpvideo -dumpfile [video.264]

and anything recognized as audio with

mplayer [input.ext] -dumpaudio -dumpfile [audio.aac]

(with the relevant extensions depending on the format of the source, although it shouldn't affect the output)
but in this case the audio command doesn't work (0 byte output).
Problem is, without a proper header, and a reader able to deal with said header, binary data from an audio file or a video file is barely distinguishable from a random stream of bytes...

My sister was attacked with a car, litteraly run over by some crack addict ex girlfriend of my sisters current boyfriend..

Damn, this world is looking more and more like George Carlin's doomsday scenario...

Yea I converted the other file using the converter tool and tried importing into mkvtoolnix, still the same AVC video. Even tried running ffmpeg on the converted file once then twice over to see if it would create some sort of readable audio file.. but still nothing. At the point of giving up.

Gotta love some george carlin

[aedipuss]

if you open P200109_164544_165544.mp4 with windows media player it's a 3hr 6min 37sec audio only file of what sounds like traffic occasionally driving by. don't know why nothing else plays it the same.

[abolibibelot]

Yea I converted the other file using the converter tool and tried importing into mkvtoolnix, still the same AVC video. Even tried running ffmpeg on the converted file once then twice over to see if it would create some sort of readable audio file.. but still nothing. At the point of giving up.

From the URL you provided :
“(If you have other garbled .264 files, feel free to contact me @ rasp AT spitzner.org)”
Have you tried that ?

I tried a very rough hexadecimal analysis, with little knowledge of video files binary structures beyond the basics, found out that :
- when comparing P200109_164544_165544.mp4 with P200109_164544_165544.264, it appears that the 32 first bytes are stripped on the .mp4 ;

- if synchronized at offset 0 / +32, both files appear identical up until a “ITKA” string appears in the .264 file — apparently each audio chunk begins with a 16 bytes header indicated by “ITKA” ;

- if deleting 16 bytes starting from “ITKA”, the files are identical again, up until a “ITKV” string appears in the .264 file — apparently each video chunk begins with a 16 bytes header indicated by “ITKV” ;

- if deleting 16 bytes starting from “ITKV”, the files are identical again, up until the next “ITKA”, and so on...

Anyway, an idea if all else fails would be to strip the first 32 bytes plus all the “ITKV” chunks from the .264 file, in the hope of getting something that contains only the audio and is somehow recognized as such by any one of those tools... But that's kinda tricky, at least with next to zero programming skills, especially since the audio and video chunks have varying lengths (about 2500-5500 bytes for video chunks and about 140-160 bytes for audio chunks). Did a thorough search : in this .264 file there are 5400 “ITKV” hits and 9375 “ITKA” hits {*} — so doing it manually would be crazy... If anyone has a better idea... é_è

{*} Sometimes there are two “ITKA” in a row ; but it is strange because with an average length of 150 bytes per audio chunk and 9375 chunks the total size of audio chunks would be about 1406250, much less than the size of the AAC stream detected by MKVToolNix which is about 6.7MB ; perhaps there are bigger chunks somewhere, or perhaps I got this all wrong...

[abolibibelot]

Apparently the converter.exe utility was made to process files with “HXVF” / “HXAF” video and audio header markers, the overall structure seems to be similar otherwise, so perhaps it would work as intended by replacing the relevant strings in the source code by “ITKV” / “ITKA”... and recompile it... I rarely ever had to compile source code so I couldn't help much in that regard...

[aedipuss]

can you upload the .264 file here to vh so i can see what the headers look like? the link to anonfiles is not reachable here.

[ljx34]

Yea I converted the other file using the converter tool and tried importing into mkvtoolnix, still the same AVC video. Even tried running ffmpeg on the converted file once then twice over to see if it would create some sort of readable audio file.. but still nothing. At the point of giving up.

From the URL you provided :
“(If you have other garbled .264 files, feel free to contact me @ rasp AT spitzner.org)”
Have you tried that ?

I tried a very rough hexadecimal analysis, with little knowledge of video files binary structures beyond the basics, found out that :
- when comparing P200109_164544_165544.mp4 with P200109_164544_165544.264, it appears that the 32 first bytes are stripped on the .mp4 ;

[Attachment 51583 - Click to enlarge]
- if synchronized at offset 0 / +32, both files appear identical up until a “ITKA” string appears in the .264 file — apparently each audio chunk begins with a 16 bytes header indicated by “ITKA” ;

[Attachment 51584 - Click to enlarge]
- if deleting 16 bytes starting from “ITKA”, the files are identical again, up until a “ITKV” string appears in the .264 file — apparently each video chunk begins with a 16 bytes header indicated by “ITKV” ;

[Attachment 51585 - Click to enlarge]
- if deleting 16 bytes starting from “ITKV”, the files are identical again, up until the next “ITKA”, and so on...

Anyway, an idea if all else fails would be to strip the first 32 bytes plus all the “ITKV” chunks from the .264 file, in the hope of getting something that contains only the audio and is somehow recognized as such by any one of those tools... But that's kinda tricky, at least with next to zero programming skills, especially since the audio and video chunks have varying lengths (about 2500-5500 bytes for video chunks and about 140-160 bytes for audio chunks). Did a thorough search : in this .264 file there are 5400 “ITKV” hits and 9375 “ITKA” hits {*} — so doing it manually would be crazy... If anyone has a better idea... é_è

{*} Sometimes there are two “ITKA” in a row ; but it is strange because with an average length of 150 bytes per audio chunk and 9375 chunks the total size of audio chunks would be about 1406250, much less than the size of the AAC stream detected by MKVToolNix which is about 6.7MB ; perhaps there are bigger chunks somewhere, or perhaps I got this all wrong...

If the ITKV is stripped from the MP4 file, then why does the MP4 contain audio still? I'm guessing the ITKV isn't the audio part. I can write a program in python to extract all these ITKV chunks but how do I know how the chunk ends? Does it have a certain footer at every chunk?

@aedipuss, sure, attached.

I have emailed the guy on the link, will see if he replies.

[abolibibelot]

If the ITKV is stripped from the MP4 file, then why does the MP4 contain audio still? I'm guessing the ITKV isn't the audio part. I can write a program in python to extract all these ITKV chunks but how do I know how the chunk ends? Does it have a certain footer at every chunk?

Only the 32 bytes general header (supposedly) at the beginning, and each 16 bytes chunk header (also supposedly) are removed, from what I could see. What remains still contains the actual binary content of both the video and audio (the size of the converted .mp4 is smaller but not by much, if the video chunks were removed the size would be much smaller). Why some tools identify this mix of video and audio with no standard structure as audio and others as video remains a mystery. (I tried to remove a few video chunks manually from the original .264 file, at the beginning or at the end, to see if it would be identified as audio in MKVToolNix, but it didn't work.)
I don't think that there's a specific footer indicating the end of every chunk, but (as explained in the page you linked) in each header, right after the "ITKV" or "ITKA" string, there's an hexadecimal value which corresponds to the length of the chunk that follows. For instance, at offset 185, there's "94 00", which reads as 00 94 in "little-endian", which translates to 148 in decimal base, and the length of the chunk that follows from 197 to 344 (starting right after the end of the 16 bytes header and ending right before the next "ITKx" string) is indeed 148 bytes. Then at 349 there's "C0 0E" => 0E C0 => 3776, and 361 to 4136 is indeed 3776. And so on...
Also, here are text files created following a thorough search of either "ITKV" strings or "ITKA" strings, indicating the position of each :
P200109_164544_165544.264 -- ITKV.txt
P200109_164544_165544.264 -- ITKA.txt
I tried to come up with something based on this but it didn't go very far.
The idea was to edit those lists (with TEDNotepad or Calc) to turn each line into a command for a little tool called dsfo, from here :
http://members.ozemail.com.au/~nulifetv/freezip/freeware/
But a Python script might be enough to do such a task without a third-party tool.

Hope it helps !

[aedipuss]

@aedipuss, sure, attached.

lol am i blind or did it not get attached

[ljx34]

If the ITKV is stripped from the MP4 file, then why does the MP4 contain audio still? I'm guessing the ITKV isn't the audio part. I can write a program in python to extract all these ITKV chunks but how do I know how the chunk ends? Does it have a certain footer at every chunk?

Only the 32 bytes general header (supposedly) at the beginning, and each 16 bytes chunk header (also supposedly) is removed, from what I could see. What remains still contains the actual binary content of both the video and audio (the size of the converted .mp4 is smaller but not by much, if the video chunks were removed the size would be much smaller). Why some tools identify this mix of video and audio with no standard structure as audio and others as video remains a mystery. (I tried to remove a few video chunks manually from the original .264 file, at the beginning or at the end, to see if it would be identified as audio in MKVToolNix, but it didn't work.)
I don't think that there's a specific footer indicating the end of every chunk, but (as explained in the page you linked) in each header, right after the "ITKV" or "ITKA" string, there's an hexadecimal value which corresponds to the length of the chunk that follows. For instance, at offset 185, there's "94 00", which reads as 00 94 in "little-endian", which translates to 148 in decimal base, and the length of the chunk that follows from 197 to 344 (starting right after the end of the 16 bytes header and ending right before the next "ITKx" string) is indeed 148 bytes. Then at 349 there's "C0 0E" => 0E C0 => 3776, and 361 to 4136 is indeed 3776. And so on...
Also, here are text files created following a thorough search of either "ITKV" strings or "ITKA" strings, indicating the position of each :

[Attachment 51663 - Click to enlarge]

[Attachment 51664 - Click to enlarge]
I tried to come up with something based on this but it didn't go very far.
The idea was to edit those lists (with TEDNotepad or Calc) to turn each line into a command for a little tool called dsfo, from here :
http://members.ozemail.com.au/~nulifetv/freezip/freeware/
But a Python script might be enough to do such a task without a third-party tool.

Hope it helps !

I emailed the guy at the URL, we emailed back and forth and he kept insisting that the file didn't contain any audio, he said my pc must have "random audio generators" in a sarcastic manner, guess there is no pleasing some people xD

I am doing the python script now, will update.

[ljx34]

Well, here is all the ITKA data attached. 1.6mb file :/

Now how to convert this to an audio file xD

Edit: Well, I will be damned, ffmpeg converted it to a real audio file.

Edit2: Well, problem solved, audio is 10minutes long and its all correct, special shoutout to mr abolibibelot, thanks a lot man.

Edit3: Attached python code to extract audio from files that contain ITKA. I tried making a full solution but for some reason it doesn't extract ITKV(video) correctly, it just outputs a 13mb file(tested on a 50mb file so youd imagine it would be bigger) and when ran through ffmpeg and played in VLC or others, only the upper 10% of the video image is viewable, the rest is just.. broken. So there must be more to ITKV than there is to ITKA. I'm completely winging it here so I don't know if I'm completely off/missed something.

import binascii
import struct
import sys

outdata = open("output.aac", "ab")
with open(sys.argv[1], "rb") as f:
    byte = f.read(1)
    while byte != b"":
        if byte == b"I":
            byte = f.read(1)
            if byte == b"T":
                byte = f.read(1)
                if byte == b"K":
                    byte = f.read(1)
                    if byte == b"A":
                        chunkcount1 = f.read(1)
                        binascii.hexlify(chunkcount1)
                        chunkcount2 = f.read(1)
                        binascii.hexlify(chunkcount2)
                        combinedchunk = chunkcount1 + chunkcount2
                        chunkcount = struct.unpack("<h", combinedchunk)
                        outdata.write(b"ITKA")
                        if int(chunkcount[0]) > 0:
                            x = 0
                            total = int(chunkcount[0]) + 10
                            while x != total:
                                byte = f.read(1)
                                outdata.write(byte)
                                x += 1
        byte = f.read(1)

Python 3, and yea, I'm not great at coding, but it works.
Got to run ffmpeg on it afterwards. output.aac should show up in same folder when finished.
Usage: Extactaudio.py [filename.264]

[abolibibelot]

Well, here is all the ITKA data attached. 1.6mb file :/

Yeah, that's about what I calculated above : “but it is strange because with an average length of 150 bytes per audio chunk and 9375 chunks the total size of audio chunks would be about 1406250, much less than the size of the AAC stream detected by MKVToolNix which is about 6.7MB ; perhaps there are bigger chunks somewhere, or perhaps I got this all wrong...”
And it is strange indeed, as the audio from the MKA file obtained earlier was 64kbps according to MediaInfo, consistent with the size of 6.7MB – or perhaps that bitrate value was attributed based on the size ?
But after a ffmpeg remux to M4A container, I do hear the same chirping birds with no apparent defect, and the duration is 9m59s, which almost perfectly matches the duration of the video obtained earlier, while the bitrate is now reported as 19kbps.

Attached python code to extract audio from files that contain ITKA. I tried making a full solution but for some reason it doesn't extract ITKV(video) correctly, it just outputs a 13mb file(tested on a 50mb file so youd imagine it would be bigger) and when ran through ffmpeg and played in VLC or others, only the upper 10% of the video image is viewable, the rest is just.. broken. So there must be more to ITKV than there is to ITKA. I'm completely winging it here so I don't know if I'm completely off/missed something.

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 emailed the guy at the URL, we emailed back and forth and he kept insisting that the file didn't contain any audio, he said my pc must have "random audio generators" in a sarcastic manner, guess there is no pleasing some people xD

Yeah, I very often get very disappointed by the reactions of (supposedly) fellow human beings... é_è It's especially strange in this case, as, judging from that article he wrote and that little tool he provided for free and his invitation to ask for personal guidance in similar but not quite identical situations, the dude seemed eager to help and open to accepting utter weirdness as a starting point...