avs4x265 0.5 released - x265 with avisynth as input

[Kurtnoise]

I've made a port of avs4x264 (http://komisar.gin.by/tools/avs4x264/) in order to use x265 binary...

Package available here (http://kurtnoise.free.fr/x265/) (sources included).

Changelog:

- v0.1 : initialization
- v0.2 : added a switch to specify the x265 binary to use.
- v0.3 : replaced the old avisynth_c.h header file by the new one provided in FFmpeg in order to take account the new colorspaces. Thanks to qyot27
- v0.4 : added some enhancements mentioned by Reel.Deel in this post : http://forum.doom9.org/showthread.php?p=1682882#post1682882
- v0.5 : display full x265 command line used to stdout


Minimum command line used :

avs4x265.exe --bitrate x -o output.hevc input.avs
or
avs4x265.exe -q y -o output.hevc input.avs

Where x is the bitrate value and y the QP value. All x265 options are available of course...;-)

http://uppix.net/G9NVQE.png (http://uppix.net/G9NVQE)

Enjoy :)

[masterkivat]

Excellent, Kurt.
Now I can play a bit with 'x265' :D

[Overdrive80]

New toy, thanks ;)

[Kurtnoise]

Build 0.2 released...link in the 1st post.

- Added a switch to specify the x265 binary to use. Hence, we can run Avisynth 32bits within the x265 64bits, for example.
- Also tweaked the x265 encoder in order to have the stdin for y4m input files + the version # during encoding (available in the 0.2 package).

[lauguru]

hello
what would be the command to maintain the highest quality and no loss. Could you give an example?

[Kurtnoise]

This is quite subjective you know...It might be good quality for you but not for someone else.

With no loss, you mean lossless ? There is no such thing for the moment.

[edison]

Does the --crf really works ?

[fumoffu]

yes, probably will work even better in future but it works ok now

[nakTT]

Build 0.2 released...link in the 1st post.

- Added a switch to specify the x265 binary to use. Hence, we can run Avisynth 32bits within the x265 64bits, for example.
- Also tweaked the x265 encoder in order to have the stdin for y4m input files + the version # during encoding (available in the 0.2 package).
Are you also the one who made the avs4x265 that is currently used in MeGUI? If yes, can I simply replace that one with this new one (Build 0.2) that you just released? Thank you in advance.
:thanks:

[Kurtnoise]

Are you also the one who made the avs4x265 that is currently used in MeGUI?
yes...

If yes, can I simply replace that one with this new one (Build 0.2) that you just released?
If you mean the x265 executable then yes...You can replace it.

[nakTT]

If you mean the x265 executable then yes...You can replace it.
Thanks for the reply.

No, I mean in MeGUI/Tools/x265/ you have 2 files: avs4x265.exe and x265.exe

My question is for the former.

[Kurtnoise]

No, this is the same...why would you do this ?

[nakTT]

No, this is the same...why would you do this ?
Because I thought avs4x265 0.2 is the latest version of the avs4x265 that come from MeGUI update server thus I thought it must be better.

Meaning that this avs4x265 0.2 is the same as the one that come from MeGUI update server? Sorry for my bad english, it is not my mother tongue.

[Kurtnoise]

The tool avs4x265 is the same between this package and the one from MeGUI server...The x265 build is different coz you can update this executable without modifying the avs4x265.

I will update the megui x265 encoder asap.

[nakTT]

The tool avs4x265 is the same between this package and the one from MeGUI server...The x265 build is different coz you can update this executable without modifying the avs4x265.

I will update the megui x265 encoder asap.
Yes, changing the encoder (x265.exe) is what I manually did all this while, the same goes with x264.exe during the hight of its devolepment.

I can see that I misunderstood about avs4x265.exe, because I thought the version 0.2 that you post is the better (in doing what is suppose to do) version of the avs4x265.exe.

I also know that this avs4x265.exe is not the encoder, the x265.exe is.

[foxyshadis]

Too bad there isn't yet an avisynth_c.h at version 5, it'd be nice to be able to use this with the new colorspaces and 16-bit support.

[plonk420]

not sure if this is an avs4x265 issue or x265 issue, but my encodes of movie crapped out at ~20k frames. i'm *pretty* sure it's not a script issue, as divx265 encoded the whole thing (albeit slowly... over 50% of it went at .5fps (720x360))

here's the resulting file (https://mega.co.nz/#!2RYgDQpQ!ekkQBm99IuAP9Wn2LDBddnLgmbJtmBUVb54r4nLqrM0) in its entirety.

encode settings to one of the attempts were "avs4x265 --crf 14 panicroom.avs -o panicroom-crf14slow.mp4 --preset slow"

ps, thanks for this app to get x265 more compatible! been having fun screwing around with what source material i have laying around! :D

[Maxiz]

Can someone help me to find the reasons for which i continue to have error failed to create process?

[Kurtnoise]

Can someone help me to find the reasons for which i continue to have error failed to create process?
you should post your entire error message...

not sure if this is an avs4x265 issue or x265 issue, but my encodes of movie crapped out at ~20k frames. i'm *pretty* sure it's not a script issue, as divx265 encoded the whole thing (albeit slowly... over 50% of it went at .5fps (720x360))

here's the resulting file (https://mega.co.nz/#!2RYgDQpQ!ekkQBm99IuAP9Wn2LDBddnLgmbJtmBUVb54r4nLqrM0) in its entirety.

encode settings to one of the attempts were "avs4x265 --crf 14 panicroom.avs -o panicroom-crf14slow.mp4 --preset slow"
D
x265 encoder doesn't support mp4 output...only raw h265 files. Did you retry with recent x265 builds ?

[Kurtnoise]

Too bad there isn't yet an avisynth_c.h at version 5, it'd be nice to be able to use this with the new colorspaces and 16-bit support.
I uploaded the 0.3 release in order to take into account this...let me know if you have any issues.

[Reel.Deel]

Hi Kurtnoise,

Thanks for this tool, with x265 picking up pace this tool should become very handy. :)

Any possibility of adding some of the enhancements of avs4x264mod (http://forum.doom9.org/showthread.php?t=162656)?

[Kurtnoise]

Hi,

Yes, sure...Which kind of enhancements would you like to have ?

[Reel.Deel]

Modifications:

-- When x264′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 x264. If “input-depth” is not defined or equals to 8, avs4x264mod acts in the same way as original avs4x264.

-- Print full command-line piped to x264_64.exe to screen, prefixed by “avs4x264 [info]:”.

-- Make x264_64.exe path changeable. The path of x264 binary can be set by --x264-binary "x264_path" or -L "x264_path". If custom path is not set, default path "x264_64.exe" will be used.

-- 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 x264.
E.g., --tcfile-in="timecode.txt", --input-depth=16, --x264-binary="x264", -L=x264 and -Lx264.

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

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

-- Correct framerate to proper NTSC fraction if applicable

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



Which kind of enhancements would you like to have ?

I think these would be a nice addition to avs4x265. If I only had to choose some I would choose:


-- When x264′s parameter “input-depth” is set and is not equal to 8, divide “width” by 2....


IMO this makes it a bit more straight forward and easier to use.


-- Make x264_64.exe path changeable. The path of x264 binary can be set by --x264-binary "x264_path"...


self-explanatory.


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

This option automatically adds the -- --input-csp ixxx to the x264 command line.


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

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

These options (--input-res/--fps/--frames/--input-csp) are defined by avs2x264 so there's no need for the user to input these.


-- Add "--seek-mode" to decide use "fast" seek mode or "safe" seek mode when has "--seek"....

Can be useful in certain cases.
.
-- Correct framerate to proper NTSC fraction if applicable.

May be useful for people like me who live in NTSC land. :)


I hope I'm not asking for too much.:o

[Kurtnoise]

Let's try with the 0.4 release (http://kurtnoise.free.fr/x265/avs4x265-0.4.7z) and tell me if all is fine...

[LigH]

Thank you for developing this tool, as little as it may be. Funny it got even smaller in the last version; now there may even be space for a changelog file in the archive?

[Kurtnoise]

It's smaller because I didn't include the compressor anymore...

About the changelog :


- v0.1 : initialization
- v0.2 : added a switch to specify the x265 binary to use.
- v0.3 : replaced the old avisynth_c.h header file by the new one provided in FFmpeg in order to take account the new colorspaces. Thanks to qyot27
- v0.4 : added some enhancements mentioned by Reel.Deel in this post (http://forum.doom9.org/showthread.php?p=1682882#post1682882).


I will add it in the package for the next versions...

[LigH]

^ v0.1 ;)

[Reel.Deel]

Let's try with the 0.4 release (http://kurtnoise.free.fr/x265/avs4x265-0.4.7z) and tell me if all is fine...

Thanks for the quick update Kurtnoise. :thanks:
Quickly encoded a small sample with 16-bit YV12 input to 10-bit x265, it seems to be working properly. I did not test --seek-mode or 8-bit x265 (will test more thoroughly this weekend).


I hate to bother again but if it's not too much trouble can you please add this:

-- Print full command-line piped to x264_64.exe to screen, prefixed by “avs4x264 [info]:”.

[Kurtnoise]

Done in the 0.5 release (http://kurtnoise.free.fr/x265/avs4x265-0.5.7z)...

[Zathor]

Thanks for the tool, Kurtnoise.

Sadly since 0.4 I get an error which does not appear when using 0.3.

My command line:
"D:\MeGUI\tools\x265\avs4x265.exe" --x265-binary ".\x64\x265.exe" --crf 23 --output "D:\MeGUI\_SAMPLE_VIDEOS\1.mkv.hevc" "D:\MeGUI\_SAMPLE_VIDEOS\1.avs"

avs4x265 output:
avs [info]: AviSynth 2.58, build:Dec 22 2008 [08:46:51]
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1080
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 3388
Error: Failed to create process <2>!

Reason is that the x265.exe cannot be located. The path must now be full qualified - so this command works:
"D:\MeGUI\tools\x265\avs4x265.exe" --x265-binary "D:\MeGUI\tools\x265\x64\x265.exe" --crf 23 --output "D:\MeGUI\_SAMPLE_VIDEOS\1.mkv.hevc" "D:\MeGUI\_SAMPLE_VIDEOS\1.avs"

So this is not an important problem. But perhaps you can add in the next version an error message when the exe cannot be located (and maybe revert to the old functionality that relative paths are ok). Thanks for your time!

[qyot27]

About the changelog :
- v0.3 : replaced the old avisynth_c.h header file by the new one provided in FFmpeg in order to take account the new colorspaces. Thanks to qyot27

Actually, that header is the one kemuri-_9 modified for x264 (and the C-plugin branch of FFMS2). FFmpeg uses it for consistency with them.

[kaefert]

could somebody compile a 64bit version?

avs [error]: Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins64/LSMASHSource.dll' :(

[Kurtnoise]

What you ask it's not related to this tool...

[LigH]

How about avs4x26x (http://forum.doom9.org/showthread.php?t=162656)? It has a 64-bit version too, and specifically supports AviSynth+.

[kaefert]

@LigH - thanks for the suggestion! that would work I guess, but I found an alternative that I like much more:

https://github.com/rdp/ffmpeg-windows-build-helpers/
contains a completely automated build script for ffmpeg with x265 (and a lot of other libraries) that has the parameter --high-bitdepth=y which makes it add the -DHIGH_BIT_DEPTH=ON cmake parameter for x265.
with that I can simplify my encoding a bit by doing encoding and packing into an mp4 container in a single step :)

[LigH]

Just a pity that ffmpeg will probably create an incomplete MP4 file, so you may still need to refresh the container with MP4Box.

[conc@n8]

Just a pity that ffmpeg will probably create an incomplete MP4 file, so you may still need to refresh the container with MP4Box.

Could you elaborate please? Thank you.

[LigH]

Well, as already documented many times: ffmpeg works like a "filter". It writes an output file preferably only once, so that it could also write to a pipe where "rewind and overwrite the header" is technically not supported. But there are containers which would need values in the header = the beginning of a file which are only known at the end of the conversion. A program which writes a complete container would have to know the whole content before it starts to write the file. ffmpeg may not do that well in all cases. MP4Box does that.

That is my current level of knowledge for years already. If I am wrong now, because ffmpeg improved in this case, please correct me.

[conc@n8]

Well, as already documented many times: ffmpeg works like a "filter". It writes an output file preferably only once, so that it could also write to a pipe where "rewind and overwrite the header" is technically not supported. But there are containers which would need values in the header = the beginning of a file which are only known at the end of the conversion. A program which writes a complete container would have to know the whole content before it starts to write the file. ffmpeg may not do that well in all cases. MP4Box does that.

That is my current level of knowledge for years already. If I am wrong now, because ffmpeg improved in this case, please correct me.

FFmpeg has implemented a few new muxing options recently, and perhaps -movflags faststart applies to such situations: http://ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv

[LigH]

@ Kurtnoise:

The direct link to the v0.5 release returns a valid ZIP download; but the "here" URL in your starting post returns an error page. Looks like you don't have a "website" there anymore.

[Kurtnoise]

I will check, thanks.

[benwaggoner]

FFmpeg has implemented a few new muxing options recently, and perhaps -movflags faststart applies to such situations: http://ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv
This stuff is specifically for writing fragmented MPEG-4 files ala DASH and Smooth Streaming. These aren't compatible with many older .mp4 file-based players.

Also, there is no requirement for mov/mp4 that the MOOV atom be at the front. It's good to have it at the front for progressive download from a server that doesn't support byte-range access; this is called a "fast start" file. But for local playback or from a server that allows random access, it doesn't really matter.

[hydra3333]

These aren't compatible with many older .mp4 file-based players.

Thanks.
Confirming I haven't had any issues with "-movflags faststart" using a chromecast-from-raspberry-pi-webserver or a WDTV-live media player.
It seemed like a good practice, so I put it in my encoding stream anyway.

Does "-movflags faststart" mean that LigH's concern is no longer an issue ?

[Floatingshed]

Is there a 64bit version of this?

[stax76]

Is there a 64bit version of this?

I think this method is not very popular. There are different tools used by GUIs and users. In staxrip that is ffmpeg, avs2pipemod and vspipe and they all work equally well.

If you are in the x265 dialog in staxrip there is a tab called Other where you can find an option called Piping Tool, in the same dialog at the bottom there is a dropdown that has a Show Command Line menu item, best open a source file before, that can show you example command lines on how to use this three piping tools.

Typically, piping is done by GUIs or scripts of power users because it's not completely simple, often the y4m format is used which has the limitation that it does not support the frame count which is needed for an encoder to show progress, a power user can write a script but for normal users it's too difficult.

This type of piping works only in cmd however, running cmd in powershell works like this:

cmd /s /c --% "regular command line without any escaping between this quotes"

It should also be noted that there are x265 builds that can open avs directly, maybe even vpy (vapoursynth), both frame servers are supported in ffmpeg (libavformat (lavf)) which these special x265 builds use.

[MeteorRain]

My x265 has a patch to support loading avs directly, just like in x264. avs4x265 was likely to be used with hacked high bit depth or to support running 32bit avs on 64bit x265.

[halls]

My x265 has a patch to support loading avs directly, just like in x264. 64bit x265.


Hi!


Can you write a short cmd syntax for that?

[stax76]

https://x265.readthedocs.io/en/latest/cli.html#cmdoption-input

[Patman]

Hi!

Can you write a short cmd syntax for that?

I think it is the same like x264.exe (only x265 Yuuki-Asuna by MeteorRain)

x265.exe --output NUL C:\input.avs

[halls]

I think it is the same like x264.exe (only x265 Yuuki-Asuna by MeteorRain)

x265.exe --output NUL C:\input.avs

ok.


Latest realese
ffmpeg is worinkg fine.
Maybe i did something wrong.

https://i.imgur.com/WjoVRjM.jpg