How detect end of x264 mp4-file?

[SCIF]

What hex code marks end of x264 mp4(coded by x264 cli)? It's a long story, now i have a dump of disk space, which begins from x264 header. At file allocation table this file is solid and guess i dumped whole file and some trash. I want to cut it. I seeked for 0x49736F4D65646961 (by advice RBF) and didn't found at all.

[SCIF]

:( Does anybody don't know solution?

[DarkZell666]

can't you encode a sample (20 frames should be enough)
and open it with a hexeditor yourself ?

Or even try downloading this sample for example :
http://files.x264.nl/force.php?file=./x264.429.cbs_csi_hdtv.sample.624x352.mp4

I have this at end of file :
http://tpechoc.free.fr/screen_hex_EOF_mp4.png

[DarkZell666]

any luck ?

[SCIF]

I'm not a lamer. It's idea i tryed first. I specially wrote "coded by x264 cli"! In attach i capture end(in hex) of two x264 encoded mp4 files.

[DarkZell666]

I'm not a lamer.
I never said that ;)

Here is what I get at end of MP4 file produced by x264.exe :

http://tpechoc.free.fr/EOF_x264cli_mp4.png

But !! I've done a second sample, and the EOF looks the same but doesn't have the same values :

http://tpechoc.free.fr/EOF_x264cli_mp4_2.png

[SCIF]

What value you offer to looking for me?:cool:

[unmei]

what makes you think there is such an unique end marker?
I ask because i suspect there isn't any.. For one, the h264 bitstream is packed into mp4, therefore if mp4 had any container level data after the payload in a packet, you would have to look for an mp4 end marker, but i suspect it has has not ("because" matroska has not). If it has not, the file data can either end with h264 bitstream data OR with payload of mp4 packets that do not contain h264 payload (metadata or the like). For h264 itself i suspect it has no concept of "end of file" because it is just a succession of frames that does not know its own "start" and "end".

[edit]
If you cannot confirm an end marker, i would look into mp4's ways of defining the file structure. Maybe it has a header field that specifies the file length, else you will have to repeat { identify packet start, read length, jump length forward } until you no longer find a packet start maker at the expected position.

[DarkZell666]

What unmei states is probably right I'm afraid.

Still, look for 0xF47374737A "ôstsz" and seek a couple of bytes further, since you can see that "ôstsz" appears in both screenshots, and that the following structure seems to be roughly the same.

I'll let you count the bytes I'm too lazy :p

Edit : you can even look for "(stco" : 0x287374636F, it's nearer to the end ;)
Edit2 : The "avcC" string : 0x61766343 may be more reliable since there is AVC in it :p but you might encounter others at the beginning.