Home > avs4x26x, encode, x264 > avs4x264mod v0.6.3 ( Fix crash on XP/Server 03 )

avs4x264mod v0.6.3 ( Fix crash on XP/Server 03 )

22nd March 2012, Thursday Leave a comment Go to comments

Download links ( source codes are here):
avs4x264mod-0.6.3-git-r47(a5b1251).7z:
MediaFireGitHubNMM Mirror

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.

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.

Categories: avs4x26x, encode, x264
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: