requesting info: fps location in x264 MP4

[Isochroma]

Due to a bug in x264, certain AVI files are compressed to an mp4 with 10,000,000 fps or 3,000,000 fps output. I have determined that the problem lies with editing a video >4293 frames in Vegas 6.0, then trying to compress the AVI with x264.

In order to further understand the problem, I need to know the hex offset of the fps value in an mp4 file produced by x264. If the offset is variable, then accompanying identification tags/hex sequences which can allow for a search using a hex editor.

Thank you in advance for any info you can give me.

[Sirber]

Vegas 6.0 uses the VFW version of x264? MP4 output is with the CLI version. :confused:

[Isochroma]

Sorry to have not provided more info... I exported the video to HFYU YUY2 and also tested RAW RGB24 with identical results.

Input to x264 was via AVS:

AVISource("e:\video\filename.avi")
ConvertToYV12()


New Info:

Using a source AVI file of ~12 frames, encoded with HFYU in YUY2 mode & 720x480, I've created five identical small mp4 files using x264, using an AVS script as above. All other parameters being identical, here are the specs:

File 1: 40fps, creation date 1
File 2: 40fps, creation date 2

File 3: 20fps, creation date 1
File 4: 20fps, creation date 2
File 5: 20fps, creation date 3

Only the time of creation existed as a difference between files of a given framerate. All other parameters, including filenames, scriptnames, and compression values were precisely identical.

After creation, it was noted that all files were exactly the same size. However, exactly 22 groups of two hex digits each were different, according to a binary comparison using HHD Hex Editor.

Of those 22, only 10 consistently remained the same between files of a given framerate, and also changed between files of a different fps.

Two pairs of hex values were found to be identically duplicated at a short offset from each other. These particular values also show an inverse relationship to the framerate. In decimal, they are:

20 FPS: 360
40 FPS: 180

A formula of n=7200/FPS suffices to describe the values (in decimal) located at these two offsets.

The remaining eight hex pairs are still a mystery, but by systematic analysis I will determine their correlation and derive equations linking them to the FPS value.

More info coming tomorrow including a precise table of forward and reverse offsets, and determining equations, and the RTF for an Excel spreadsheet with inbuilt function to give the correct values...

Until then, sleep tight and may your FPS always be right!

[sysKin]

I would not count on the values to be 8-bit aligned or 8-bit long, but good luck.
It's probably best to get the header specs.

[sysKin]

Follow x264's source/encoder/set.c::x264_sps_write() function and see where it writes i_num_units_in_tick (denominator) and i_time_scale (numerator). Both are 32-bits long (haha easy for you) but you need to figure out their position (in bits, not bytes!) which in turn will depends on resolution, number of reference frames, profile, aspect ratio and some other things I don't even understand :)

Good luck again

[bond]

Isochroma, did you use the vfw or cli version of x264?

azsd, upload a small snip of your .mp4 file somewhere

for checking the framerate of a .mp4 file i always simply use mp4ui

[Sharktooth]

however before saying it's a x264 bug double-triple check it even with other softwares... coz if the problem shows only with vegas there's a chance the bug is in vegas and not in x264...

[Isochroma]

Multiple attempts to get correct output from x264 were made:

1. video was reprocessed in Vdub using direct stream copy mode
2. video was reprocessed in Vdub using fast recompress to HFYU YUY2 mode
3. video was opened in 're-derive keyframe flags' mode with Vdub, then saved using fast recompress.
4. video was rendered as two smaller segment (the first of which encoded fine by itself), and the segments concatenated in the AVS fed to x264 using this script:

AVISource("file.seg1.avi") + AVISource("file.seg2.avi")
ConvertToYV12()

None of these methods works. No video software reports any problems with the AVI, and the first three methods described above recreate the AVI index block and/or renew the structure such that no corruption should remain in the source.

I would like to post the entire file, but it is about 1.2GB long. I will try compressing it to a lossy source (should still crash x264 fine!)...

[bond]

maybe i am too dumb, but i dont really understand what your problem is...

one time you talk about vegas than about virtualdub, than about HFYU than about x264, than about cli than about vfw

now what?

[Isochroma]

Here is the production path under consideration:

1. rip VOBs from dvd
2. index with DGIndex
3. specify d2v in AVS file #1
4. load AVS file #1 in Vdub
5. save as AVI in fast recompress with HFYU in YUY2 mode

6. load this AVI into vegas
7. edit
8. render to AVI with HFYU in YUY2 mode

9. create AVS script #2, specifying the above file or trial derivatives as explained in previous post.
10. feed AVS script to x264 (cli version, always)


It has been found that skipping steps 6-8 causes x264 to output a fully normal mp4 file. However, the output AVI from step 8 shows no signs of corruption, and as explained in previous post, recompressing/keyframing does not fix it.

My guess is that some weird difference in the AVI after editing causes x264 to have a problem...

[bond]

sounds to me like its not x264's but vegas fault

what do you need HFYU for? what do you edit?

[Isochroma]

Using Debugmode FrameServer, I served frames out of Vegas 6.0 directly to an AVS file, which contained:

avisource("e:\video\t1.avi")
killaudio()
converttoyv12()

killaudio() is used because the frameserver always exports the audio track: no options dialog is available in the Render As main dialog when the frameserver is selected as export filetype.

So the problem was with Vegas 6.0's file output producing slightly corrupt AVI frames past frame 4293!

Thanks to all those who helped with their replies to this problem, and good luck!

[Isochroma]

Thanks for all the helpful ideas and thoughts, everyone!

I've solved my problem (and also saved gigs of diskspace!) by exporting using DebugMode's frameserver software. It is free, and provides export to three colorspaces (RGB24, RGB32 and YUY2). However, only RGB24 seems to work - but that's fine!

By serving the frames directly thru this app (thru avi signpost), loaded into an AVS and converted to YV12, with killaudio() to drop the useless audio track everything works fine... it avoids Vegas 6's obviously buggy file-writing routines.

I have therefore stopped work on finding and deriving formulas for the framerate values in MP4 files, as such information is now redundant.