Archive

Archive for the ‘avs4x26x’ Category

avs4x26x 0.10.0 ( x265, AviSynth+, x64, DGSourceIM, etc. )

28th August 2014, Thursday 10 comments

After the silence of nearly one year.

Download links ( source codes are here): avs4x26x

 

Changelog since 0.9.1:

1. Fix automatically invoking Source Filter for media input files with AviSynth+, using the same patch from BugMaster for x264.

2. Support x265, x264 and x262. That is why we change the name from avs4x264 to avs4x26x. Actually avs4x264mod already supports x265 by simply using --x264-binary, but now if your output file is *.265/*.h265/*.hevc, avs4x26x will launch “x265.exe” even without --x26x-binary or -L. Still, “x264_64” for other output for backward compatibility.

Note that x265 introduce another method: x265 input output. This would not be supported for the x264/x265 recognition. Either avs4x26x input.avs --output output.265 or avs4x26x input.avs -Lx265 output.265 or avs4x26x input.avs --x26x-binary x265 is OK. But if you write avs4x26x input.avs output.h265, x264_64 is implied.

3. Support automatically invoke DGSourceIM, if DGSource failed for “*.dgi” input

4. Since x265 does not support avs input yet, x64 version is reasonable for those who want to use x64 AviSynth with x64 x26x. Now here comes the x64 version, to be used with x64 avisynth.dll.

 

Recently I’m preparing for my wedding ceremony, x264-tMod might be delayed for several weeks.

Categories: avs4x26x, encode, x264

avs4x264mod 0.9.1

31st August 2013, Saturday 1 comment

Download links ( source codes are here): avs4x264mod-0.9.1-git-r64(105c53a).7z

0.9.1:
1. Prefers to use VapourSource for vpy input, as it is a native VapourSynth source filter. Put VapourSource.dll in AviSynth’s auto-load folder, or else x264 would try AVISource/HBVFWSource as before. Keep in mind that unlike HBVFWSource which will automatically imply –input-depth 16, with VSImport x264 wouldn’t know if the vpy output clip is 8-bit or not, so it is needed to manually set --input-depth depth if depth is not 8.
2. Prefers to use LSMASHVideoSource/LWLibavVideoSource as source filter than FFMS2 for many input formats, e.g., mp4/mov/mkv/m2ts/…. Still able to fall back to FFMS2 if LSMASH/LWL fails.

Categories: avs4x26x, encode, x264

x264 rev2230+696 tMod / avs4x264mod 0.9.0

11th November 2012, Sunday 12 comments

Sources on GitHub: https://github.com/astrataro/x264_tMod.

Use win32thread and fprofiled:
tMod/tMod-10bit/tMod+MixAQ/tMod+OreAQ:
Download:
x264_rev2230+696_tMod.7z : NMMMediaFireGitHub
No-opencl ver(Lite+MixAQ only): NMM
avs4x264mod-0.9.0-git-r62(691c5c4).7z: NMMMediaFireGitHub

By default uses old style progress indicator, and won’t break GUI’s progress parser. If you like r2204 style progress indicator, try --stylish, but keep careful if you are using GUIs. The difference between r2204 and this --stylish is that console title always uses old style indicator, so you won’t get meaningless raw numbers without labels on console title.

——————————–

Updates:
1. <x264> updated x264 core to 0.129.2230+696
2. <x264> (important!!) (should have) fixed a regression in fgo patch, usually occurs on still or slowly moving objects with clean background ( and it is quite possibly that this regression not only existed in my builds but also in many others’ builds with fgo patch ). If anyone used the fgo patch grabbed from rev2085 to rev2216, please replace your patch from here. Thanks \Noir/ for reporting and testing
3. <x264> high bit depth y4m support, with skipping depth filter enabled
4. <x264> all 8-bit builds except no-opencl version were built with opencl support (Catalyst™ 12.9 should have fixed the crashing), so they need OpenCL runtime installed in your system, otherwise use no-opencl version instead.
5. <avs4x264mod & x264> added support for .vpy file input via vfw interface (using AVISouce/HBVFWSource):

This slideshow requires JavaScript.

——————————–

My other tools list ( including some of the x264 builds ) : MediaFire, RSS

Categories: avs4x26x, encode, x264, x264-bin

fixtc for avs4x264mod

3rd July 2012, Tuesday Leave a comment

avs4x264mod automatically adds --timebase when using --tcfile-in since 0.7, but sometimes timecodes files are not accurate, and may break x264’s timecodes parser with correct timebase=1001/normal_NTSC_timebase_den. You can manually set --timebase to overwrite avs4x264mod’s decision, but it it not a good solution, as the problem is caused by the input timecodes files, and the value detected by avs4x264mod is more accurate than x264’s decision in such cases. Most of these timecodes files are generated by muxing video into matroska container and extracting timecodes from this mkv file, in which timestamp precision is by default reduced to 1ms when muxing. You can use --timecode-scale 1 to keep normal 0.000001ms precision when muxing with mkvmerge, if the input video’s timestamp is normal (e.g., when muxing standard NTSC mp4 into mkv, or specifying timecodes/fps when muxing). But it will increase the file size of muxed mkv files, and in most cases the source video one uses for encoding is not muxed by him/herself. So here I made a tiny tool for correcting such timecodes files.

Download – fixtc-v1.2.7z: MediaFire, NMM-Mirror
Edit: tctool-v1.3.44.7z
tctool is based on fixtc with richer features
old features work more stable for some strange timecodes, and some new features are still in TODO list
check tctool-help.txt/changelog.log/TODO in the archives file for details.

Usage(supports both timecodes v1 and v2):
fixtc.exe "input_timecodes.txt"

Output will be printed on screen. If you want to keep it in a single output file, use system stdout redirection:
fixtc.exe "input_timecodes.txt" > "output_timecodes.txt"

The fps values in timecodes v1 and the intervals between two timestamps in timecodes v2 will be automatically corrected to NTSC values if capable. Don’t try to use it for non-NTSC contents. x264 should be able to parse PAL timebase properly, for which fps is either 25 or 50, and timestamps are either 40, 80, 120,… or 20, 40, 60,…, so normally you won’t lose precision.

Examples:

timecodes v1:
before fixed:
# timecode format v1
# comment lines will be copied
Assume 23.976
0,467,23.9754
468,547,29.9738
548,583,23.9840
584,623,29.9625
624,667,23.9782
668,722,29.9728
invalid lines will be prompted and skipped
723,762,23.9664
763,777,30.0000
778,805,23.9726
806,815,29.9401
816,895,23.9808
896,925,29.9700
926,1197,23.9753

after fixed:
# timecode format v1
# comment lines will be copied
Assume 23.976024
0,467,23.976024
468,547,29.970030
548,583,23.976024
584,623,29.970030
624,667,23.976024
668,722,29.970030
723,762,23.976024
763,777,29.970030
778,805,23.976024
806,815,29.970030
816,895,23.976024
896,925,29.970030
926,1197,23.976024

timecodes v2:
before fixed:
# timecode format v2
# comment lines will be copied
0
42
83
125
167
invalid lines will be prompted and skipped
209
250
292
334
375
417
# break at invalid timestamp(current timestamp is earlier than previous one)
300
501
542

after fixed:
# timecode format v2
# comment lines will be copied
0.000000
41.708333
83.416667
125.125000
166.833333
208.541667
250.250000
291.958333
333.666667
375.375000
417.083333
# break at invalid timestamp(current timestamp is earlier than previous one)

Categories: avs4x26x, encode

avs4x264mod v0.8.0 ( supports .d2v/.dgi/.dga/.avi/.mkv/.mp4/.m2ts/.wmv/… input, and auto fps correction )

4th June 2012, Monday Leave a comment

Download links ( source codes are here):

normal version: avs4x264mod-0.8.0-git-r61(099ad2f).7z:
MediaFireGitHubNMM Mirror

excalibur version: avs4x264mod-0.6.2-9-git-excalibur-r52(b32dcfd).7z:
MediaFireGitHubNMM Mirror

excalibur version is a totally re-written experimental version by msg7086, and support --pipe-mt/--affinity/--x264-affinity. You can find more info by running it without options. But some latest updates of main branch may be missing in this version.

Changelog:

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

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

v0.3:
1. Fix invalid x264 binary path when both avs4x264 and x264 binary is given by full path
2. 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:
1. Directly output i422/i444 with AviSynth 2.6 new csp YV16/YV24. No forced ConvertToYV12 for these two csp any more. Thanks to SAPikachu.
2. Display version and help info when run with no options.

v0.5:
1. 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:
1. Fix pipe error with YV12. This bug was introduced in v0.4.

v0.6:
1. Do not add --input-res/--fps/--frames/--input-csp if already defined.
2. 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:
1. Correct --frames when used with --seek, faster --seek if no timecodes defined.
2. Show more script information when opening avs.

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

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

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

v0.7:
1. Automatically add “--timebase” when using “--tcfile-in“. When timebase is not specified, x264 reads timebase from input source.
2. 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.

v0.8:
1. Correct framerate to proper NTSC fraction if applicable, e.g., DSS’s 10000000/417083fps will be automatically corrected to 24000/1001, and DGSource’s 48000/2002 or 240000/10010 will be automatically reduced fraction to 24000/1001.
2. Fix some regressions in input file name detection with x264-audio, such as avs4x264mod.exe --audiofile "audio.avs" "video.avs" --output "output.mp4".
3. When one switch has been specified twice, use the latter, except for input file name, for which the first one is always used. E.g., for avs4x264mod "input_1.avs" "input_2.avs" --input-depth 8 --input-depth 10 -o output_1.mp4 -o output_2.mkv, “input_1.avs” will be used as input file, “output_2.mkv” will be used as output path, and input-depth will be set to 10. This is exactly what x264 do when one parameter has been specified twice or more, so avs4x264mod just follow the same logic.
4. Update for x264’s new style --tff/bff instead of old --interlaced switch
5. Add support for direct .d2v/.dga/.dgi input, and some media file input. Now you can simply use avs4x264mod "input.dgi" -o "output.264" or avs4x264mod "input.avi" -o "output.264" to encode.

———————————————————————–


avs4x264mod - simple AviSynth pipe tool for x264
Version: 0.8.0.61, built on Jun 4 2012, 02:45:33

Usage: avs4x264mod [avs4x264mod options] [x264 options]

Supported input formats:
.avs
.d2v: requires DGDecode.dll
.dga: requires DGAVCDecode.dll
.dgi: requires DGAVCDecodeDI.dll or DGDecodeNV.dll according to dgi file
.avi: try to use AVISource -> FFVideoSource(normal) -> DSS2 -> DirectShowSource
.m2ts/.mpeg/.vob/.m2v/.mpg/.ogm/.ogv/.ts/.tp/.ps:
try to use FFVideoSource(demuxer="lavf" and seekmode=-1) -> DSS2 -> DirectShowSource
seek-mode will be forced to "safe" for these formats
.mkv/.mp4/.m4v/.mov/.flv/.webm:
try to use FFVideoSource(normal) -> DSS2 -> DirectShowSource
.rmvb/.divx/.wmv/.wmp/.asf/.rm/.wm:
try to use DSS2 -> DirectShowSource

Options:
-L, --x264-binary User defined x264 binary path. [Default="x264_64"]
--seek-mode Set seek mode when using --seek. [Default="fast"]
- fast: Skip process of frames before seek number as x264 does if no
--tcfile-in/--qpfile specified;
otherwise freeze frames before seek number to skip process,
but keep frame number as-is.
( x264 treats tcfile-in/qpfile as timecodes/qpfile of input
video, not output video )
Normally safe enough for randomly seekable AviSynth scripts.
May break scripts which can only be linearly seeked, such as
TDecimate(mode=3)
- safe: Process and deliver every frame to x264.
Should give accurate result with every AviSynth script.
Significantly slower when the process is heavy.

Categories: avs4x26x, encode, x264

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

19th May 2012, Saturday 1 comment

Download links ( source codes are here):

normal version: avs4x264mod-0.7.0-git-r51(552ce8c).7z:
MediaFireGitHubNMM Mirror

excalibur version: avs4x264mod-0.6.2-9-git-excalibur-r52(b32dcfd).7z:
MediaFireGitHubNMM 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.

Categories: avs4x26x, encode, x264

avs4x264mod v0.6.4 ( Fix my stupid fix )

11th April 2012, Wednesday Leave a comment

Download links ( source codes are here):
avs4x264mod-0.6.4-git-r48(a15d375).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.

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

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