avs4x26x v0.10.0 ( support high-bitdepth avs & customized x264/x265 path & avs+ )

[06_taro]

Piping faked 16-bit avs output ( MSB and LSB field interleaved clip ) to x264_64.exe using original avs4x264 results in wrong resolution and video. So I modified it to behave in a correct way. It is a command line tool to be used with x264 / x265, and you can also safely rename the executive file to "avs4x264.exe" and replace the original one in MeGUI's tools/x264 folder.

Download links ( source codes are here) :
avs4x26x-0.10.0-1-git-r71(db90333).7z

Modifications:

-- When x26x's parameter "input-depth" is set and is not equal to 8,
   divide "width" by 2. This makes faked 16-bit avs output, i.e.,
   MSB and LSB field interleaved clip, be treated correctly by x26x.
   If "input-depth" is not defined or equals to 8, avs4x26x acts
   in the same way as original avs4x264.

-- Print full command-line piped to x26x.exe to screen, prefixed
   by "avs4x26x [info]:".

-- Make x264_64.exe path changeable. The path of x26x binary can be
   set by --x26x-binary "x26x_path" or -L "x26x_path". If custom path
   is not set, default path "x264_64.exe" will be used in normal case,
   while if output file extension is *.265/.h265/.hevc, "x265" will be
   launched.

-- Directly output i422/i444 with AviSynth 2.6 csp YV16/YV24.

-- Show help info when running with no options.

-- Improve capability with more styles of parameters in x26x.
   E.g., --tcfile-in="timecode.txt", --input-depth=16,
         --x26x-binary="x264", -L=x264 and -Lx265.

-- Do not add --input-res/--fps/--frames/--input-csp if already defined.

-- Correct number of frames to be handled when --frames is defined.

-- Add "--seek-mode" to decide use "fast" seek mode or "safe" seek
   mode when has "--seek". Default is "fast".
   -- "fast" mode is similar to x26x'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 x26x regards qpfile or
      tcfile-in as qpfiles or timecodes of input files, not output files,
      so the frame numbers of input piped raw ( can be linearly seeked
      only in x26x ) has to be left untouched.
   -- "safe" mode uses a safer but slower method: delivering every
      untouched frame to x26x. 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.

-- Add "--timebase" when using "--tcfile-in".

-- Correct framerate to proper NTSC fraction if applicable.

-- Support direct .d2v/.dga/.dgi input, plus .vpy input with either
   VapourSource(VSImport) or vfw interface(AVISource/HBVFWSource), and
   some media file input such as .avi/.mkv/.mp4/.m2ts/etc.

-- Support AviSynth+.

-- Support x262/x265.
   However, the x265 style "x265 <infile> <outfile>" is not supported
   and probably never will. You need to use -o or --output before outfile.

avs4x26x - simple AviSynth pipe tool for x262/x264/x265
Version: 0.10.0.70, built on Aug 28 2014, 15:19:31

Usage: avs4x26x [avs4x26x options] [x26x options] -o <output> <input>

Supported input formats:
     .avs
     .d2v: requires DGDecode.dll
     .dga: requires DGAVCDecode.dll
     .dgi: requires DGAVCDecodeDI.dll, DGDecodeNV.dll or DGDecodeIM.dll according to dgi file
     .vpy: try to use VSImport -> AVISource -> HBVFWSource
           (VSImport requires VapourSource.dll)
           (HBVFWSource requires HBVFWSource.dll, and will force input-depth=16)
     .avi: try to use AVISource -> LWLibavVideoSource -> FFVideoSource(normal)
                      -> DSS2 -> DirectShowSource
     .mp4/.m4v/.mov/.3gp/.3g2/.qt:
           try to use LSMASHVideoSource -> LWLibavVideoSource
                      -> FFVideoSource(normal) -> DSS2 -> DirectShowSource
     .m2ts/.mpeg/.vob/.m2v/.mpg/.ogm/.ogv/.ts/.tp/.ps:
           try to use LWLibavVideoSource
                      -> FFVideoSource(demuxer="lavf" and seekmode=-1)
                      -> DSS2 -> DirectShowSource
           seek-mode will be forced to "safe" for these formats if ffms is used
     .mkv/.flv/.webm:
           try to use LWLibavVideoSource -> FFVideoSource(normal) -> DSS2
                      -> DirectShowSource
     .rmvb/.divx/.wmv/.wmp/.asf/.rm/.wm:
           try to use DSS2 -> DirectShowSource
     (FFVideoSource, LWLibavVideoSource, LSMASHVideoSource, DSS2, DirectShowSource
           requires ffms2.dll, LSMASHSource.dll, avss.dll, DirectShowSource.dll)

Options:
 -L, --x26x-binary <file>   User defined x26x binary path.
                                Default: "x265" if output file is *.h265/.265/.hevc
                                         otherwise "x264_64"
     --seek-mode <string>   Set seek mode when using --seek. [Default="fast"]
                                - fast: Skip process of frames before seek number as x26x does if no
                                        --tcfile-in/--qpfile specified;
                                        otherwise freeze frames before seek number to skip process, 
                                        but keep frame number as-is.
                                        ( x26x 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 x26x.
                                        Should give accurate result with every AviSynth script.
                                        Significantly slower when the process is heavy.

avs4x26x.exe --x26x-binary "C:\x264_64-10bit.exe" --output "out.264" --input-depth 16 "in.avs"
avs4x26x input.avs -o output.h265
avs4x26x -o output.h265 input.avs --input-depth 16

[DarkT]

So... Ummm... What does this do again? *grins*

[Fullmetal Encoder]

Just wanted to say thanks for this excellent tool. It's very useful and easy to use.

[06_taro]

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="C:\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" switch, 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:
-- Automatically add "--timebase" when using "--tcfile-in". When timebase is not specified, x264 reads timebase from input source.
-- 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:
-- 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.
-- Fix some regressions in input file name detection with x264-audio, such as avs4x264mod.exe --audiofile "audio.avs" "video.avs" --output "output.mp4".
-- 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.
-- Update for x264′s new style --tff/bff instead of old --interlaced switch
-- Add support for direct .d2v/.dga/.dgi input, and some media file input

v0.9:
-- Add support for direct .vpy input with vfw access

[vdcrim]

I was looking for something to correctly pipe 16 bits to x264. Thanks for improving this tool.

[Zerofool]

Hello, 06_taro,

Thank you for your work on this mod, it definitely is very helpful.

I'd like to report a strange thing I encountered.
I'm experimenting with RGB source, encoded in 4:4:4.

avis [error]: unsupported input format (YV24)

I used MeGUI at first, but I switched to command prompt because after each error, MeGUI would disable the usage of avs4x264.exe. Then I opened the log files to copy my command line, and I noticed that MeGUI uses vfw4x264.exe instead of avs4x264.exe, and renaming the mod to that one fixed my problem. Anyway, I hope that helps someone that encounters the same "error" .

I wonder what's the difference between avs4x264 and vfw4x264 (the original ones).

Thanks once again for your mod, I hope it will officially replace the original one(s) in the MeGUI pack someday.

[06_taro]

Actually many people encountered the same thing with official build of avs4x264 in MeGUI. I'm not a developer of MeGUI. I use avs4x264 as a cli tool only because it is convenient and does not require many tweaks in command line like other pipe tools, and I have never used it with MeGUI ( though I decided not to change the behavior of avs4x264mod so that it can safely replace avs4x264 in MeGUI ). So I have no idea why in some cases MeGUI uses vfw4x264 while in other cases it uses avs4x264. Maybe asking a developer of MeGUI would be helpful

[kemuri-_9]

Originally Posted by Zerofool

I wonder what's the difference between avs4x264 and vfw4x264 (the original ones).

The APIs used in reading the file are different:

vfw4x264 uses the Windows VFW APIs to open the file up.
x264 itself used this until I rewrote it to use the avisynth APIs.
the original code didn't support anything but YV12 as well, so I doubt that whoever authored vfw4x264 bothered to support more than that.

avs4x264 uses the Avisynth APIs to open the script/file.
x264 itself now uses this methodology of reading in avisynth scripts and other files if ffms/lavf were not enabled/purposefully skipped.
This allows for the ability of using extra Avisynth functions to control the input into x264, such as colorspace conversion and weaving separated field input.

When i looked at the code for both of these utilities a long time ago, they were practically exact copies of what x264 once had (vfw) or used at the time (avs).
I have no idea if anyone bothers to update them.

[Zerofool]

Thank you both for the info.
As 06_taro suggested, I should probably ask this in the MeGUI thread, but still, kemuri-_9, do you know how MeGUI decides which one to use over the other?

Originally Posted by kemuri-_9

This allows for the ability of using extra Avisynth functions to control the input into x264, such as colorspace conversion and weaving separated field input.

Are you talking about the "--video-filter" portion of x264, or that's completely different thing? And what happens to these capabilities if avisynth isn't installed? I mean... there's no info in the x264 help that it requires avisynth for a specific function (like the ones you describe) to work .

Sorry for going a bit off-topic .

Edit: OK, I just did a fast search and found few possible answers - vfw4x264 is somewhat faster, and certain MPEG-2 sources have troubles with avs4x264 .

[kemuri-_9]

Originally Posted by Zerofool

do you know how MeGUI decides which one to use over the other?

No, not a clue - I don't use MeGUI.

Are you talking about the "--video-filter" portion of x264, or that's completely different thing?

No, --video-filter is very different functionality.
I was originally referring to the last clauses of this and this

Edit: OK, I just did a fast search and found few possible answers - vfw4x264 is somewhat faster, and certain MPEG-2 sources have troubles with avs4x264 .

I don't see where that information came from, there's overhead in the vfw system when interfacing with avisynth so using vfw4x264 is actually slower. also the latter point doesn't make sense.

[Zerofool]

Originally Posted by kemuri-_9

No, --video-filter is very different functionality.
I was originally referring to the last clauses of this and this

I see, thanks.

Originally Posted by kemuri-_9

I don't see where that information came from, there's overhead in the vfw system when interfacing with avisynth so using vfw4x264 is actually slower. also the latter point doesn't make sense.

That's what I found with a quick search, not my personal experience.

Here are some quotes (from 2009-2010):

Originally Posted by Alf Bundy

Just updated to x264 1400 and made 2 quick tests :

Win7 x64, C2D E7400 @ 3Ghz, GPU = NV 9800GTX+
MeGUI 0.3.3.0, DG tools build 2005


PS : about MeGUI's version , in update (dev. server) I see Existing version 0.3.3.0 / latest version 0.3.2.3
Is that normal ?

Originally Posted by MuLTiTaSK

try with vfw4x264.exe instead it's faster for me and others it also doesnt corrupt MPEG2 streams loaded with MPEG2Source("") like avs4x264.exe does

Originally Posted by Zathor

Are you using the latest dev build? I'm asking because the latest build is using vfw4x264 and not avs4x264 because of some problems (e.g. with mpeg2 input).

Originally Posted by JoeH

Zathor,

I just tried the latest development build with vfw4x264.

It works great, and for me runs even slightly faster (between .5% and 2%) than the avs4x264!

But I also found these now:

Originally Posted by Zathor

In my benchmarks there has been no real difference between both wrappers.

Originally Posted by Zathor

Because avs4x264 produces garbage if the source is mpeg2 with DGDecode_mpeg2source serving this file (I do not know if dgmpg is the source of the problem or mpeg2 in general or avs4x264). vfw4x264 has no known problems.

And the MPEG-2 problem was fixed, obviously:

Originally Posted by Zathor

I have updated a few tools (x264, mkvtoolnix, dgindexnv). I'm only writing this because I have moved to the x264 build from Komisar and replaced the avs4x264 file with a new one from alwa. This should fix the problem with DGDecode_mpeg2source but I did not test it and therefore vfw4x264.exe is still used for x64.

[Zathor]

Thanks, 06_taro. I added your program to MeGUI.

[tormento]

The laa build opened a new world. Now I can use 12 threads and 3GB memory in my avs scripts with no hiccups.

Thanks.

[aufkrawall]

Is there a way to set the x264 child process to high priority?
With several "/high"s here and there I only could get avs4x264mod to get high priority, but not x264.

[vdcrim]

Originally Posted by aufkrawall

Is there a way to set the x264 child process to high priority?
With several "/high"s here and there I only could get avs4x264mod to get high priority, but not x264.

It works with priorities below 'normal'. It seems that by default a child process inherits its parent's priority but limited to 'normal'. The solution would be check avs4x264mod's priority and pass the appropriate flag to CreateProcess (I didn't try it).

[aufkrawall]

Originally Posted by vdcrim

It works with priorities below 'normal'. It seems that by default a child process inherits its parent's priority but limited to 'normal'. The solution would be check avs4x264mod's priority and pass the appropriate flag to CreateProcess (I didn't try it).

That would mean recompile, wouldn't it?
There's also a patch for x264 by komisar that makes it possible to select priority, but I'd rather favor a simple CLI trick.

[06_taro]

Updated to 0.6.3.
Only laa build was built, as it should work well on all machines.
Fixed crash on XP/Server 03, thanks to maki_rxrz's patch.

aufkrawall
I have no plan on the x264 thread priority trick in avs4x264mod.

[Nevilne]

I wonder if avisynth x264-audio support is possible?

[06_taro]

No, piping video and audio raw stream in the same time is not possible. x264 cannot separate them properly.
And IIRC, x264-audio's audio encoding cannot handle pipe in. CMIIW.

[Chikuzen]

Originally Posted by 06_taro

And IIRC, x264-audio's audio encoding cannot handle pipe in. CMIIW.

no, x264-audio can handle pipe in
see the last of this page.