strange framerate and missing ctts reported with x264

[azsd]

x264 build 272B,using MeGUI automated 3pass encoding for an anime clip@23.976 (haven't mux by mp4box in job list)

encoded mp4 files have an 8517000.000 fps shown in mediainfo.

report by matroska tools (I remember earlier x264 builds worked fine):

"Warning: 'V:\DvdRip\Recode\Target\Midori\midori 01 [nr][x264]v1.mp4' track 1: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to."

[azsd]

header avaliable here:

hxxp://my1993.com/PpsDES/midori_mp4_header.zip

Mp4UI report:

Type Video
NumberOfSamples 34068
VideoType invalid
Bitrate 0 kbps
Duration 0:00.004 minutes
Framerate 8517000.000 fps
Width x Height 0 x 0

[bond]

i need a small part of the original .mp4

and i need a small part of the input source, so i can reproduce it myself

[azsd]

but the small part of the input source produced an mp4 get playing fine.

hxxp://my1993.com/PpsDES/midori851700.rar

I trimed first 6MB of the orginal mp4 to a new mp4 by WinHex,and Trimmed first 1024 frame in to new mkv using VDM.
[Midori]vol01[neroavc].avs is the script whitch I used yesterday,have packed into archive too.

yesterday I use the entire source and get the corrupt mp4 (124MB),
x264 272B,MeGUI 0.2.1.2 AVC Automate 3pass,730k@High Profile
today night I'll try to reproduce the results.

[bond]

azsd: i need your exact commandline you used with x264

but the small part of the input source produced an mp4 get playing fine.

hxxp://my1993.com/PpsDES/midori851700.rar

I trimed first 6MB of the orginal mp4 to a new mp4 by WinHex,and Trimmed first 1024 frame in to new mkv using VDM.
[Midori]vol01[neroavc].avs is the script whitch I used yesterday,have packed into archive too.plz stop working with a hexeditor on mp4 files :rolleyes:

trimming a .mp4 file with a hexeditor will output an unuseable .mp4 file
you simply cant cut a normal .mp4 file (special ones you can) with a hexeditor without destroying the .mp4 file

a new rule of thumb: if you have no clue about the internals of a file format, dont cut it with a hexeditor and also dont think that you can extract the headers with a hexeditor (the "header file" you posted before didnt include the headers)... :p

for cutting a .mp4 file use mp4box :search:

[bond]

azsd: ok i now took the time and tried it myself

i loaded your input .mkv via the following avs script into x264:
directshowsource("blabla.mkv",fps=23.976)i used the haali parser and the ffdshow decoder

i used the following commandline:
x264 --bitrate 700 --ratetol 1 --threads 1 --bframe 3 --b-pyramid --ref 5 --filter -5:-5 --analyse all --8x8dct --weightb --progress -o output.mp4 input.avsso basically everything enabled

result:
the output .mp4 has a perfect ctts and 23.976 framerate as it should be


i am sure your problem is not caused by x264

about the framerate: if i look at your setup i see that you go via this strange .grf loading in avs, with a funky "#" (is this necessary?). why dont you simply load the file directly via directshowsource()? you could also try to export the xvid stream from .mkv to .avi and feed x264 directly with this .avi

the missing ctts problem is propably caused by mkvmerge always looking for the ctts even on files which dont have b-frames and therefore dont have a ctts (as the ctts is only needed for b-frames) i assume

moved to an own thread as it doesnt belong in this one

[Isochroma]

... but not with Matroska. Check my post out here:

http://forum.doom9.org/showthread.php?t=96977

[azsd]

the 3 pass commandline arg generate by MeGUI 0.2.1.2.
yes I have tested before I post that partical source:"but the small part of the input source produced an mp4 get playing fine.",with same commandline generate by same MeGUI option except the video runing time.

Next job job1-1 is a video job. encoder commandline:
"F:\Program Files\VideoTools\mencoder\x264.exe" --pass 1 --bitrate 730 --stats "2pass.log" --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "V:\DvdRip\Recode\[Midori]vol01[neroavc].avs"

Next job job1-2 is a video job. encoder commandline:
"F:\Program Files\VideoTools\mencoder\x264.exe" --pass 3 --bitrate 730 --stats "2pass.log" --analyse all --8x8dct --progress --no-psnr --output "V:\DvdRip\Recode\Target\Midori\midori 01 [nr][x264]v1.mp4" "V:\DvdRip\Recode\[Midori]vol01[neroavc].avs"

Next job job1-3 is a video job. encoder commandline:
"F:\Program Files\VideoTools\mencoder\x264.exe" --pass 3 --bitrate 730 --stats "2pass.log" --analyse all --8x8dct --progress --no-psnr --output "V:\DvdRip\Recode\Target\Midori\midori 01 [nr][x264]v1.mp4" "V:\DvdRip\Recode\[Midori]vol01[neroavc].avs"

these mp4 files I placed at myweb at /PpsDES/Midori/ path.
I cannot use the second arg(entire mp4 only 4ms),so I splitt it to serials 6mb files,
midori 01 [nr][x264]v1_001.mp4 is the first part.
midori 01 [nr][x264]v1.mp4 was orginal corrupted mp4 file.

[bond]

as i said its likely that your strange input .avs f*s things up, try a normal one, like the one i posted

also which decoder and parser did you use? haali and ffdshow?

[azsd]

I had make an complete test of diffrent connetion use GraphEdit,
Halli/gabest splitter,ffdshow/xvid decoder,and use DirectShowSource to load the grahicfile.

halli+xvid
halli+ffdshow
halli+xvid+fps
halli+ffdshow+fps
gabest+xvid
gabest+ffdshow
gabest+xvid+fps
gabest+ffdshow+fps

xvid as decoder required fps param or else avisynth report "can't determinate fps of video" error.
then I get 6 encoded files (I spend 2days for these 23:40 encoding)

at last I found if use the ffdshow as decoder and not special fps arg in directshowsource filter,the encoded files will have a unaccessable fps.

I think using ffdshow reported fps(or timecode) info instead set it manuely in DirectShowSource filter caused the x264 produced incorrect mp4 files.

"ctts missing" warning still exists when mux playable mp4 file using mmg,but the muxed mkv files were playable too.
only shorter mp4 files have not the warning,it may come with special frame type that shorter mp4 havn't contain.
and the shorter mkv(decode by ffdshow) without fps parameter in DirectShowSource working fine with x264 in my test.

[bond]

i think for directshowsource() you always have to set the fps manually

[vidhead]

a 2-pass mp4 video using MeGUI (MeGUI-0.2.1.9) without audio when mux with mkvmerge produced the exact error warning:

"...track 1: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to."

what the hack is 'CTTS' atom? i did watch the file and so far it look and sounds normal.

the mp4 was made with default settings except for +6 alpha deblocking. x264 core:34 svn-285M.

the result play without issue on Mplayer /Core player /classic media player. g-spot cannot recognise the video format. Mplayer (MPUI GUI) playing output looks normal.

[bond]

by default x264 uses no b-frames.when no b-frames are used its not necessary to have a ctts in .mp4 files and therefore mkvmerge will also not find one
still the .mp4 file is perfectly fine


btw you can check whether the .mp4 file has a ctts atom (which stores the timevalues of the frames) with the dumpster tool from apple available here (http://developer.apple.com/quicktime/quicktimeintro/tools/index.html)

open the .mp4 in it, go to moov -> trak -> mdia -> minf -> stbl -> ctts

if the ctts atom is there and contains lots of values than everything is correct and mkvmerge reports the missing ctts wrongly

x264 should output a correct ctts always

[vidhead]

dumpster result on a .mp4 made with MeGUI and x264:

under stbl there are 5 atom types:
stsd - Sample description atom
stts - Time-to-sample atom
stss - Sync sample atom
stsc - Sample-to-chunk atom
stsz - Sample size atom

there are some $values ($values) along the left side of each. and that is all. no ctts atom like mkvmerge says?

found this :
http://lists.matroska.org/pipermail/matroska-devel/2005-January/002351.html

which may be relevant...but its akkadian to me. (shrugs) anyhow the mkv result muxed with audio and subs plays well on various players i've tried

[bond]

read the first sentence in my last post again. did you use b-frames?

[Sirber]

the 3 pass commandline arg generate by MeGUI 0.2.1.2.
yes I have tested before I post that partical source:"but the small part of the input source produced an mp4 get playing fine.",with same commandline generate by same MeGUI option except the video runing time.

Next job job1-1 is a video job. encoder commandline:
"F:\Program Files\VideoTools\mencoder\x264.exe" --pass 1 --bitrate 730 --stats "2pass.log" --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "V:\DvdRip\Recode\[Midori]vol01[neroavc].avs"

Next job job1-2 is a video job. encoder commandline:
"F:\Program Files\VideoTools\mencoder\x264.exe" --pass 3 --bitrate 730 --stats "2pass.log" --analyse all --8x8dct --progress --no-psnr --output "V:\DvdRip\Recode\Target\Midori\midori 01 [nr][x264]v1.mp4" "V:\DvdRip\Recode\[Midori]vol01[neroavc].avs"

Next job job1-3 is a video job. encoder commandline:
"F:\Program Files\VideoTools\mencoder\x264.exe" --pass 3 --bitrate 730 --stats "2pass.log" --analyse all --8x8dct --progress --no-psnr --output "V:\DvdRip\Recode\Target\Midori\midori 01 [nr][x264]v1.mp4" "V:\DvdRip\Recode\[Midori]vol01[neroavc].avs"

these mp4 files I placed at myweb at /PpsDES/Midori/ path.
I cannot use the second arg(entire mp4 only 4ms),so I splitt it to serials 6mb files,
midori 01 [nr][x264]v1_001.mp4 is the first part.
midori 01 [nr][x264]v1.mp4 was orginal corrupted mp4 file.
Why do you do the last pass 2 times? :scared:

[bond]

Why do you do the last pass 2 times? :scared:because he wants to do a 3pass encode (whether this makes sense is a different question)

--pass 3 does NOT mean that its the last pass of a 3pass encode

as the x264 settings tab shows:

-p, --pass <1|2|3> Enable multipass ratecontrol:
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats fileits perfectly fine of using first -p 1, than -p 3, than -p3 and than -p2 for making a 4 pass encode