avs4x264mod v0.7.0 ( automatically add “–timebase” with “–tcfile-in” )

Download links ( source codes are here):

normal version: avs4x264mod-0.7.0-git-r51(552ce8c).7z:
MediaFire、GitHub、NMM Mirror

excalibur version: avs4x264mod-0.6.2-9-git-excalibur-r52(b32dcfd).7z:
MediaFire、GitHub、NMM Mirror

excalibur version is a totally re-written experimental version by msg7086, and support --pipe-mt/--affinity/--x264-affinity. You can find more info running it with no options.

Changelog:

v0.1:
– Fix capability with high bit depth avs.
– Add parameter to customize x264 binary.
– Print full command line used by x264.

v0.2:
– Delete ugly blank space in command line, which was generated in v0.1 if “--x264-binary” specified.

v0.3:
– Fix invalid x264 binary path when both avs4x264 and x264 binary is given by full path
– Add switch -L as a short name of --x264-binary, e.g., -L C:\x264.exe is equal to --x264-binary C:\x264.exe.

v0.4:
– Directly output i422/i444 with AviSynth 2.6 new csp YV16/YV24. No forced ConvertToYV12 for these two csp any more. Thanks to SAPikachu.
– Display version and help info when run with no options.

v0.5:
– Improve capability with more styles of parameters in x264.
E.g., --tcfile-in="timecode.txt", --input-depth=16, --x264-binary="x264", -L=x264 and -Lx264.

v0.5.1:
– Fix pipe error with YV12. This bug was introduced in v0.4.

v0.6:
– Do not add --input-res/--fps/--frames/--input-csp if already defined.
– Correct number of frames to be handled when --frames is defined. Now you can specify frame numbers to be encoded without getting errors.

v0.6.1:
– Correct --frames when used with --seek, faster --seek if no timecodes defined.
– Show more script information when opening avs.

v0.6.2:
– Add "--seek-mode" paramters, and some minor bug fixes.

v0.6.3 :
– Fix crash on XP/Server 2003, thanks to maki_rxrz.

v0.6.4 :
– Made a mistake in my last “Fix crash on XP/Server 2003”, details: here. Thanks for bug report.

v0.7.0 :
– Automatically add “--timebase” when using “--tcfile-in“. When timebase is not specified, x264 reads timebase from input source. For avisynth input, the timebase numerator should equal to framerate denominator, but for piped raw input without “--fps“, the assumed timebase will turn to be strange values, and causes timecodes parsing process generates strange timebase too. Adding “--timebase 1001” to NTSC 24000/30000 vfr source can solve such problems. I’ve been considering this fix for some time. I used to think people should always add --timebase with --tcfile-in by themselves, as automatically adding --timebase may sometimes gives unwanted results. E.g., after tivtc’s automatic vfr, if you don’t call AssumeFPS, the fps of avisynth script may be unnormal, say 345023/12111, and avs4x264mod adds 12111 as timebase numerator, which I’m sure you don’t want to see. Or sometimes the input script is 24000/1001fps, but your timecodes file is _for_some_strange_reason_ 25/1fps, so adding --timebase 1001 gives strange result. But anyway, avs4x264mod aims at completely replacing x264_64.exe in command line, and x264 itself has the same problems in these cases, so I decide to let avs4x264mod follow the same behavior. One can still override avs4x264mod’s decision by adding --timebase manually in your command line, just as he should do with x264 when he doesn’t add AssumeFPS after tivtc’s vfr process.
— Call VersionString() instead of VersionNumber() in version detect, as there are too many builds with same version number, like SEt’s mt/2.6 builds.

Explanation on "--seek-mode" ( string, "fast"/"safe", only affects how to deal with "--seek" )

– “fast” mode is similar to x264′s internal method of avs demuxer: skip frames until the frame --seek indicates. However, when used with --qpfile/--tcfile-in, it won’t skip but add a “FreezeFrame(0, seek, seek)” to avs script to actually skip the process of those frames. I have to play this trick because x264 regards qpfile/tcfile-in as qpfiles/timecodes of input files, not output files, so the frame numbers of input piped raw ( can be only linearly seeked in x264 ) has to be left untouched.
– “safe” mode uses a safer but slower method: delivering every untouched frame to x264. When the process of frames before “--seek” frame is heavy, the “useless” running time of processing those frames will be much longer than “fast” mode, but the result is safer for scripts like TDecimate(mode=3), which can only be seeked in a linear way.