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 (https://github.com/astrataro/avs4x26x)) :
avs4x26x-0.10.0-1-git-r71(db90333).7z (http://tmod.nmm-hd.org/avs4x26x)

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 (http://blog.livedoor.jp/vxz62kb2/archives/6093846.html). 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]

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?
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 :confused:.

Sorry for going a bit off-topic http://www.freesmileys.org/smileys/smiley-ashamed001.gif.

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]

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 (http://git.videolan.org/?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279) and this (http://git.videolan.org/?p=x264.git;a=commit;h=819d121f6cf92b7b5f33e85181b0dcdb0ffbb84a)

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]

No, --video-filter is very different functionality.
I was originally referring to the last clauses of this (http://git.videolan.org/?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279) and this (http://git.videolan.org/?p=x264.git;a=commit;h=819d121f6cf92b7b5f33e85181b0dcdb0ffbb84a)
I see, thanks.

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):

Can you please try out the avs4x64 file and compare it in terms of speed to vfwx264? (Simply rename avs2x264 to vfw2x264)
Just updated to x264 1400 and made 2 quick tests :

- Test 1 : Source MPEG-2 decoded with DGmultiSource()
640x480 25fps (44min 35")

avs4x264.exe - Fast 1st pass : avg FPS = 72,92fps - 15min 16"
vfw4x264.exe - Fast 1st pass : avg FPS = 80,73fps - 13min 49"



- Test 2 : Source VC-1 ES decoded with DGmultiSource()
1280x544 23.976fps (1000 frames)

avs4x264.exe
- Fast 1st pass : avg FPS = 27,04fps - 36 sec
- 2nd pass : avg FPS = 3,5fps - 4min 46"

vfw4x264.exe
- Fast 1st pass : avg FPS = 27,69fps - 36sec
- 2nd pass : avg FPS = 3,51fps - 4min 45"

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 ?

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;)

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).

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:
In my benchmarks there has been no real difference between both wrappers.

;1365704']It's using vfw4x264.exe now instead of avs4x264.exe?

Why the change?

avs4x264.exe is faster here.
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:
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]

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]

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]

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 (http://www.up-cat.net/x264%255FL%252DSMASH%2Bunofficial%2Brepository.html).

[06_taro]

Hmm, it seems that x264-audio uses lavf as default audio demuxer, and lavf can handle pipe protocol....

[Nevilne]

Maybe something among the lines of creating 2 named pipes and feeding them to x264? Don't know how well it would work on windows though. Starting cygwin for a simple encode is kinda meh.

[06_taro]

Well, there is such a tool for windows: http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=631
What is need to do is to create two named pipes out with one tool, such as ffmpeg/libav, then let x264-audio get those two named pipes in simultaneously, like this:

libav -i input.avs -f wav -vn \\.\pipe\1001 -f yuv4mpegpipe -an \\.\pipe\1002

x264 \\.\pipe\1001 --audiofile \\.\pipe\1002 -o output.mp4

[Chyrka]

06_taro, are there any speed difference between avs2yuv and avs4x264mod? (x64 system)

[Nevilne]

libav -i input.avs -f wav -vn \\.\pipe\1001 -f yuv4mpegpipe -an \\.\pipe\1002

x264 \\.\pipe\1001 --audiofile \\.\pipe\1002 -o output.mp4

Am I missing something or it only allows one standard input pipe?
Like soranamedpipe \\.\pipe\123 | app -i - ouput

Speaking of which, this also doesn't work, hehe
avs2pipemod -wav audio.avs | avs4x264mod video.avs --audiofile - -o output

[06_taro]

06_taro, are there any speed difference between avs2yuv and avs4x264mod? (x64 system)

There shouldn't be any.
Here's a rough test: http://k4095-takuan.blogspot.co.uk/2011/12/blog-post.html

Am I missing something or it only allows one standard input pipe?
Like soranamedpipe \\.\pipe\123 | app -i - ouput

Speaking of which, this also doesn't work, hehe
avs2pipemod -wav audio.avs | avs4x264mod video.avs --audiofile - -o output
Oops, I mis-understood how soranamedpipe works.
Anyway,
avs4x264mod "video.avs" --audiofile "audio.avs" -o "output.mp4"
should work properly.

[Chyrka]

06_taro, I see. Thanks for link.

[06_taro]

Update to v0.8

FPS will be corrected to NTSC fraction if applicable. And now you can simply useavs4x264mod "input.dgi -o "output.264"oravs4x264mod "input.avi" -o "output.264"to encode, source filter will be selected and invoked according to extension of input file (requires dlls for those source filters to be loaded automatically).

[LigH]

Trying to download avs4x264mod-0.9.0-git-r62(691c5c4).7z from github (https://github.com/astrataro/avs4x264mod/downloads), I get:

File was not found.

[06_taro]

Edited.

GitHub stopped their upload service (https://github.com/blog/1302-goodbye-uploads), so please use NMM-Mirror, or wait for attachment to be approved.

[Kazuya]

Hi,
I'm trying to encode several patterns in 10bit 4:4:4 to make some comparisons between renderers, video outputs...

But, I still have an YV12 conversion warning in execution window...
Or I can convert it with ConvertToYV24 but I think YV24 is 8bit, am I wrong ?
And can't find any "ConvertToY410" working with avisynth...

Is there a way to avoid any conversion ?

Thanks !

(my image source is a handmade png 16 bit image under photoshop CS3)

My command line to encode x264 :

C:\avs4x264mod.exe --x264-binary "C:\x264\x264_10bit.exe" --fps 5 --output-csp i444 --output "E:\output.mp4" "E:\Script encodage.avs"

Execute window :

http://img209.imageshack.us/img209/3486/sanstitreyyj.png

[06_taro]

(my image source is a handmade png 16 bit image under photoshop CS3)
What is the final pixel format of your AviSynth script? avs4x264mod currently only supports outputting YV12/YV16/YV24 without forcing to convert them to YV12. If the final pixel format of your script is Y8/YV411/YUY2/RGB, then ConvertToYV12() is automatically invoked.

Or I can convert it with ConvertToYV24 but I think YV24 is 8bit, am I wrong ?
Exactly. However, thanks to Cretindesalpes for his dither package, we can use up to 16-bit YUV420/422/444 formats in AviSynth. There are two formats of such high bit depth colour space: stacked and interleaved. The former contains MSB and LSB stacked vertically, so it is easy for viewing and general filtering; while the latter actually put MSB data and LSB data in the same structure that native Planar YUV formats use, so it can be used for encoding: if you tell the receiver of this format (e.g. x264) that the raw YUV is yuv420p16, then x264 will treat this fake interleaved MSB/LSB as 16-bit yuv420. You can use yuv444p10 in the similar way by:ImageSource("input.png")

# convert RGB to stacked yuv444p16
Dither_Convert_RGB_TO_YUV(output="YV24", lsb=True)

# convert stacked yuv444p16 to interleaved yuv444p16 for encoding, you can also use Dither_out()
f3kdb(Y=0, Cb=0, Cr=0, grainY=0, grainC=0, input_depth=16, input_mode=1, output_depth=16, output_mode=2)Then feed the script to avs4x264mod with "--input-depth=16", then such raw yuv444p16 will be passed directly to x264 without unnecessary conversion.

If your raw yuv data is neither 8-bit nor 16-bit, then vanilla x264 will firstly shift it to 16-bit then dither it back to encoding bit depth using Sierra-2-4A error diffusion dithering. If you are using x264 built with the patch Skip bit depth filter when possible (https://github.com/astrataro/x264_tMod/commit/f4226ddc5e96070ac28af398558e64c5cbee4504), then you can even pass 10bit avs script to x264, and neither avs4x264mod nor patched x264 will do any conversion on the raw yuv:ImageSource("input.png")

# convert RGB to stacked yuv444p16
Dither_Convert_RGB_TO_YUV(output="YV24", lsb=True)

# convert stacked yuv444p16 to interleaved yuv444p10 for encoding
f3kdb(Y=0, Cb=0, Cr=0, grainY=0, grainC=0, input_depth=16, input_mode=1, output_depth=10, output_mode=2)Then feed the script to avs4x264mod with "--input-depth=10".

[Kazuya]

Thanks, it works very well ! :cool:
And improves a lot 8bit encodes by eliminate banding.

But I think the weight of encoded file is 3 times louder than the same encode in 10bit. I only encoded patterns, so I'm note sure.

I used your first call, because my png is 16bit.
And to encode in 8bit, I only change output depth and mode :

ImageSource("input.png")
Dither_Convert_RGB_TO_YUV(output="YV24", lsb=True)
f3kdb(Y=0, Cb=0, Cr=0, grainY=0, grainC=0, input_depth=16, input_mode=1, output_depth=8, output_mode=0)

[vdcrim]

If both your input and output are 16-bit you should use a source filter that can preserve that precision, like this modified ffms (http://www.sapikachu.net/%e8%bf%91%e6%9c%9fep%e4%bd%9c%e5%93%81%e6%b1%87%e6%80%bb/). ImageSource outputs 8-bit.
FFVideoSource("input.png", cache=False, seekmode=-1, enable10bithack=True) # stacked YV24
f3kdb(Y=0, Cb=0, Cr=0, grainY=0, grainC=0, input_depth=16, input_mode=1, output_depth=16, output_mode=2)

[Kazuya]

Thanks, I will try it ! :)

[Timothy_Gu]

I follow the link to source code and met a 404: https://github.com/astrataro/avs4x264mod

Did you delete your github account or something like that?

[06_taro]

Don't know why, works for me when I log in, but fails when I log out.
Didn't delete anything.

[nhakobian]

Github was having some file server problems yesterday, not sure if this is related or if its been fixed.

[Timothy_Gu]

Github was having some file server problems yesterday, not sure if this is related or if its been fixed.

OK, I can see the server status at https://status.github.com/. It reads:
We're still performing maintenance on several fileserver clusters. Some repositories are currently unavailable.

I think that's the problem.

[LigH]

But it certainly has one of the most elaborate 404 pages ever. The Jedi-on-Tatooine scene even moves parallactically with the mouse position. :D

http://frupic.frubar.net/shots/29375.gif

[06_taro]

Update to 0.10.0

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.

[LigH]

You forgot to update to your last version:

http://tmod.nmm-hd.org/avs4x26x/
http://tmod.nmm-hd.org/avs4x26x/avs4x26x-0.10.0-1-git-r71(db90333).7z

[06_taro]

Thanks. That was a tiny commit and I forgot to update here.

[anonymlol]

I'm using version 0.10.0.71, and it sometimes crashes at the beginning of x264 encodes (x265 seems to be fine, I was using it the past few days without problems).

My settings:

avs4x26x -L "x264_64-10bit" --level 5.1 --preset veryslow --crf 18.0 --input-depth 16 --log-level none --output "1080.mkv" "1080.avs"


Here's what I could find:

The thread 0xe5e4 has exited with code 0 (0x0).
Unhandled exception at 0x774C1AD6 (ntdll.dll) in avs4x26x.exe: 0xC0000005: Access violation reading location 0x00100110.

The thread 0xe39c has exited with code -1073741510 (0xc000013a).
The thread 0xe770 has exited with code -1073741510 (0xc000013a).
The thread 0xe648 has exited with code -1073741510 (0xc000013a).
The thread 0x7178 has exited with code -1073741510 (0xc000013a).
The thread 0x80f0 has exited with code -1073741510 (0xc000013a).
The thread 0xe730 has exited with code -1073741510 (0xc000013a).
The program '[55832] avs4x26x.exe' has exited with code -1073741510 (0xc000013a).

[foxyshadis]

That usually means your Avisynth script is crashing, not avs4x26x or x264. Can you post your script?

[anonymlol]

Here you go:


DGSource("src.dgi")
mrdaa2(resharpen=0)
flash3kyuu_deband_f3kdb(grainY=0, grainC=0, output_mode=2, output_depth=16)


mrdaa2 is a slightly modified version of MrdaaLame(). (http://forum.doom9.org/showthread.php?t=167480)


# modified version of mandarinka's MrdaaLame (http://forum.doom9.org/showthread.php?t=167480) by anonymlol
# Based on Daa: Anti-aliasing with contra-sharpening by Didée, modded by Terranigma for nnedi and by thetoof for merge
# fixed chroma shift by OnDeed

function Mrdaa2(clip c, float "resharpen", bool "OpenCL") {

resharpen = Default(resharpen, 0)
OpenCL = Default(OpenCL, true)

dblshift = (OpenCL) ? c.nnedi3x(field=1, dh=true).fturnright().nnedi3x(field=1, dh=true).fturnleft()
\ : c.nnedi3(field = 1,dh=true).fturnright().nnedi3(field = 1,dh=true).fturnleft()
dbl = dblshift.Spline36Resize(c.width,c.height,-0.5,-0.5,c.width*2,c.height*2).MergeChroma(dblshift.Spline36Resize(c.width,c.height,-1.0,-1.0,c.width*2,c.height*2))
dblD = mt_makediff(c,dbl,U=3,V=3)
shrpD = mt_makediff(dbl,dbl.blur(resharpen*0.2,MMX=false),U=3,V=3)
DD = shrpD.repair(dblD,13)

return dbl.mt_adddiff(DD,U=3,V=3)
}


edit: Got some errors in cmd this time: http://puu.sh/gpUdx/c37b6d35e5.png
Seems like the error is somewhere in
dblshift = (OpenCL) ? c.nnedi3x(field=1, dh=true).fturnright().nnedi3x(field=1, dh=true).fturnleft()
\ : c.nnedi3(field = 1,dh=true).fturnright().nnedi3(field = 1,dh=true).fturnleft()

I'll remove the condition for now and use it with nnedi3ocl as default. But I'd appreciate it if someone could explain to me why it crashes during that condition.

edit2: I'll continue with this issue in the nnedi3 ocl thread (http://forum.doom9.org/showthread.php?t=169766&page=6). Thanks for your help so far.

[Khyinn]

Hi,

Can avs426x be used in linux with native x264 or should i use x264 for Windows ?

I'm asking this because i'm currently using avs2pipe which works well on Linux with wine and pipes directly to linux's native x264 but avs2pipe is a bit old now...

[06_taro]

I haven't tested avs4x26x with wine on Linux. Since it's a single binary file, just give it a try? BTW, avs4x26x is also a bit old :P

[RRD]

Hello,
Thank you for your work.
What is the use of avs4x26x-x64.exe ? With 32-bit AviSynth it expectedly returns “avs [error]: failed to load avisynth”. Is it only for direct media file input?

[LigH]

It can be used to pipe output of a 64 bit AviSynth (rather AviSynth+ than the original project) to an encoder as YUV video stream.