Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th September 2011, 20:31   #1  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
avs4x26x v0.10.0 ( support high-bitdepth avs & customized x264/x265 path & avs+ )

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:
Code:
-- 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.
Code:
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.
Code:
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
Attached Files
File Type: 7z avs4x264mod-0.9.0-git-r62(691c5c4).7z (14.8 KB, 582 views)
File Type: 7z avs4x264mod-0.9.1-git-r64(105c53a).7z (25.6 KB, 2174 views)
File Type: 7z avs4x26x-0.10.0-git-r70(28fdd98).7z (28.1 KB, 190 views)
File Type: 7z avs4x26x-0.10.0-1-git-r71(db90333).7z (28.3 KB, 578 views)

Last edited by 06_taro; 28th January 2015 at 10:51. Reason: avs4x26x-0.10.0-1-git-r71(db90333).7z
06_taro is offline   Reply With Quote
Old 25th October 2011, 18:47   #2  |  Link
DarkT
Registered User
 
Join Date: Dec 2006
Posts: 280
So... Ummm... What does this do again? *grins*
DarkT is offline   Reply With Quote
Old 10th November 2011, 23:11   #3  |  Link
Fullmetal Encoder
Registered User
 
Join Date: Jan 2011
Posts: 107
Just wanted to say thanks for this excellent tool. It's very useful and easy to use.
Fullmetal Encoder is offline   Reply With Quote
Old 29th November 2011, 04:22   #4  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
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

Last edited by 06_taro; 11th November 2012 at 14:32.
06_taro is offline   Reply With Quote
Old 12th December 2011, 20:35   #5  |  Link
vdcrim
Registered User
 
Join Date: Dec 2011
Posts: 191
I was looking for something to correctly pipe 16 bits to x264. Thanks for improving this tool.
vdcrim is offline   Reply With Quote
Old 13th January 2012, 00:05   #6  |  Link
Zerofool
VR, 3D & HDR UHD fan
 
Join Date: Mar 2006
Location: Sofia, Bulgaria
Posts: 53
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.

Code:
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.
Zerofool is offline   Reply With Quote
Old 13th January 2012, 01:46   #7  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
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

Last edited by 06_taro; 13th January 2012 at 01:48.
06_taro is offline   Reply With Quote
Old 13th January 2012, 02:36   #8  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by Zerofool View Post
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.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 13th January 2012, 03:35   #9  |  Link
Zerofool
VR, 3D & HDR UHD fan
 
Join Date: Mar 2006
Location: Sofia, Bulgaria
Posts: 53
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?
Quote:
Originally Posted by kemuri-_9 View Post
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 .

Last edited by Zerofool; 13th January 2012 at 05:17.
Zerofool is offline   Reply With Quote
Old 14th January 2012, 00:30   #10  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by Zerofool View Post
do you know how MeGUI decides which one to use over the other?
No, not a clue - I don't use MeGUI.

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

Quote:
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.
__________________
custom x264 builds & patches | F@H | My Specs

Last edited by kemuri-_9; 14th January 2012 at 00:36.
kemuri-_9 is offline   Reply With Quote
Old 14th January 2012, 21:27   #11  |  Link
Zerofool
VR, 3D & HDR UHD fan
 
Join Date: Mar 2006
Location: Sofia, Bulgaria
Posts: 53
Quote:
Originally Posted by kemuri-_9 View Post
No, --video-filter is very different functionality.
I was originally referring to the last clauses of this and this
I see, thanks.

Quote:
Originally Posted by kemuri-_9 View Post
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):
Quote:
Originally Posted by Alf Bundy View Post
Quote:
Originally Posted by Zathor View Post
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 :
Quote:
- 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"
Quote:
- 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 ?
Quote:
Originally Posted by MuLTiTaSK View Post
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
Quote:
Originally Posted by Zathor View Post
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).
Quote:
Originally Posted by JoeH View Post
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:
Quote:
Originally Posted by Zathor View Post
In my benchmarks there has been no real difference between both wrappers.
Quote:
Originally Posted by Zathor View Post
Quote:
Originally Posted by [ReX] View Post
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:
Quote:
Originally Posted by Zathor View Post
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.
Zerofool is offline   Reply With Quote
Old 17th January 2012, 21:26   #12  |  Link
Zathor
Registered User
 
Join Date: Nov 2009
Posts: 2,144
Thanks, 06_taro. I added your program to MeGUI.
Zathor is offline   Reply With Quote
Old 21st February 2012, 08:09   #13  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 789
The laa build opened a new world. Now I can use 12 threads and 3GB memory in my avs scripts with no hiccups.

Thanks.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 9th March 2012, 15:37   #14  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,646
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.
aufkrawall is offline   Reply With Quote
Old 9th March 2012, 23:02   #15  |  Link
vdcrim
Registered User
 
Join Date: Dec 2011
Posts: 191
Quote:
Originally Posted by aufkrawall View Post
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).
vdcrim is offline   Reply With Quote
Old 9th March 2012, 23:22   #16  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,646
Quote:
Originally Posted by vdcrim View Post
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.
aufkrawall is offline   Reply With Quote
Old 21st March 2012, 13:20   #17  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
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.

Last edited by 06_taro; 21st March 2012 at 13:26.
06_taro is offline   Reply With Quote
Old 21st March 2012, 16:51   #18  |  Link
Nevilne
Registered User
 
Join Date: Aug 2010
Posts: 134
I wonder if avisynth x264-audio support is possible?
Nevilne is offline   Reply With Quote
Old 22nd March 2012, 05:13   #19  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
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.
06_taro is offline   Reply With Quote
Old 22nd March 2012, 14:45   #20  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 597
Quote:
Originally Posted by 06_taro View Post
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.
__________________
my repositories
Chikuzen is offline   Reply With Quote
Reply

Tags
avisynth+, avs4x264, avs4x265, avs4x26x, x264, x265

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.