avs4x264mod v0.7.0 ( automatically add “–timebase” with “–tcfile-in” )
Download links ( source codes are here):
excalibur version is a totally re-written experimental version by msg7086, and support
--x264-affinity. You can find more info running it with no options.
– Fix capability with high bit depth avs.
– Add parameter to customize x264 binary.
– Print full command line used by x264.
– Delete ugly blank space in command line, which was generated in v0.1 if “
– Fix invalid x264 binary path when both avs4x264 and x264 binary is given by full path
– Add switch
-L as a short name of
-L C:\x264.exe is equal to
– 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.
– Improve capability with more styles of parameters in x264.
– Fix pipe error with YV12. This bug was introduced in v0.4.
– Do not add
--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.
--frames when used with
--seek if no timecodes defined.
– Show more script information when opening avs.
"--seek-mode" paramters, and some minor bug fixes.
– Fix crash on XP/Server 2003, thanks to maki_rxrz.
– Made a mistake in my last “Fix crash on XP/Server 2003”, details: here. Thanks for bug report.
– 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
--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.
"--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.