Feed x264 with 16bit avs

[Motenai Yoda]

Hi,
I'm trying to encode an avs+ x64 16bit script using x264-10bit, but I can't get a dithered 10bit encode, but only an interleaved one...

Script
setmemorymax(4096)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("dss2",3)

dss2("test1.avs_lossless.mp4",preroll=100,pixel_type="YV12")

dither_convert_8_to_16()

dither_out()

Prefetch(4)
CLI
"%~dp0x264-10bit.exe" --input-depth 16 --input-res 1920x1080 --preset ultrafast --qp 0 -o %1_lossless_10_64.mp4 %1

edit: using avs4x26x and avs+ x86 all seems working fine
"%~dp0avs4x26x.exe" -L "%~dp0x264-10bit.exe" --qp 0 --preset ultrafast -o %1_lossless_10.mp4 --input-depth 16 %1

[Mug Funky]

If all you're doing is loading and encoding, it might be better to use ffmpeg built against 10-bit x264 and cut avisynth out completely.
Also vapoursynth is coming of age and could simplify things (though it has the potential to greatly complicate things too).

Sent from my Che2-L12 using Tapatalk

[qyot27]

A) The ability for x264 to fake 16bit input with AviSynth was a hack, contained in a patch and never applied to mainline. That's why it only appears in tMod builds and avs4x26x.

B) Even with AviSynth+ now supporting proper high bit depth output, you weren't doing that. You were outputting interleaved.

C) x264 still can't support proper high bit depth input from AviSynth+ because it has to have its locally-provided avisynth_c.h header and the input module updated to recognize the new pix_fmt constants. And that won't happen if priority is given to continuing to maintain support for AviSynth 2.5. The patch allowing FFmpeg to do so is currently being reviewed (they dropped 2.5 support pretty much as soon as 2.6 was released last year).

[Sparktank]

Have you tried:
Dither_quantize (bitdepth=10)
Dither_out ()

[Motenai Yoda]

@Mug Funky that was an example to reproduce the issue

@qyot27 *insert a thank you gif here*
you know if it is included into asuna/yuuki mod?

@Sparktank I tried, same result, but getting a 16bit interleaved dithered at 10bit

[StainlessS]

I am curious, is this the real Mug Funky, or some modern fake.

Mug Funky died decades ago, methinks.

(PS, if you really are the real Mug funky, nice to see you still alive and well).

PPS, what was it that woke you up ?

[Motenai Yoda]

I am curious, is this the real Mug Funky, or some modern fake.

Mug Funky died decades ago, methinks.

(PS, if you really are the real Mug funky, nice to see you still alive and well).

PPS, what was it that woke you up ?
Even Sharktooth too was pretty sick IIRC.

[qyot27]

@qyot27 *insert a thank you gif here*
you know if it is included into asuna/yuuki mod?
That's x265. x265-yuuki doesn't have a standalone AviSynth input module, scripts are loaded through libavformat if that's been compiled in and the libavformat build had AviSynth support enabled.

Unfortunately, I believe that the LAVF module in general is limited to 8bit or something, because when I tried that with my own builds of AviSynth+, ffmpeg, and x265-yuuki with the right patches in place, it did not want to recognize any >8bit file properly, script or not, -D setting correct or not.

FFmpeg itself will be able to, given the correct libs are used (10-bit libx264, multilib libx265). Once the patch goes through, anyway. It may take a few days for that to propagate out and end up in Zeranoe's builds, though.

@Sparktank I tried, same result, but getting a 16bit interleaved dithered at 10bit
Dither_out doesn't output real high bit depth with AviSynth. It only outputs interleaved (maybe stacked too, but I didn't mess with it too much). You have to use ConvertFromDoubleWidth(10) after you've messed with Dither to get AviSynth+ to hand real 10-bit video to the receiving application - provided that application also supports getting those pix_fmts from AviSynth+. Like this:
setmemorymax(4096)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("dss2",3)

dss2("test1.avs_lossless.mp4",preroll=100,pixel_type="YV12")

dither_convert_8_to_16()

dither_out()

ConvertFromDoubleWidth()

Prefetch(4)
Although that will give you 16bit, not 10bit. Use the bitdepth parameter in Dither_out and bits parameter in ConvertFromDoubleWidth to do 10/12/14 output.

You can also do it the hard way and pipe it end to end:
ffmpeg -i fake10.avs -vcodec rawvideo -f raw - | ffmpeg -s 1920x1080 -r 24 -pix_fmt yuv420p10le -i - [other encoding options]
Or something like that. I wouldn't worry about it too much when that tactic is about to become obsolete.

[Sparktank]

Wow, I never realized how much went in (didn't go in) to >8bit.

Well, it's going to be fun over the next while to see how everything turns out. :devil:

[shekh]

What about using avs2pipemod to send y4m stream directly to x264? Does it work?

[Reel.Deel]

DJATOM just updated his Avs2YUV mod (https://github.com/DJATOM/avs2yuv/releases) to support AviSynth+'s new HBD color formats. It it considered 'unstable' so right now is the perfect time to test and report any bugs. To see what's new, take a look at the changelog (https://github.com/DJATOM/avs2yuv/blob/Unstable/Changelog).

[Motenai Yoda]

@qyot27 I was referring to yuuki mod of x264 which should be a fork of the taro's one

@Reel.Deel my goal is to use/pipe avs+ 64bit directly to x264 I'm trying this mod but getting Error: failed to load avisynth.dll

[qyot27]

@qyot27 I was referring to yuuki mod of x264 which should be a fork of the taro's one
If it has SAPikachu's avs 16bit patch included, then yeah.

And yes, it looks like it does. (https://github.com/msg7086/x264_tMod/commit/f32e89bc1345d172a5a2f8f00151f1cdbe0b0772)

[MasterNobody]

I released Avs2YUV 0.24 BugMaster's mod 5 (https://github.com/MasterNobody/avs2yuv/releases/tag/v0.24bm5) with support for AviSynth+ high bit-depth pixel formats.
It should be still compatible with AviSynth 2.5x. And if all will be ok (no serious problems detected) than I will add such support to x264 directly.

[DJATOM]

@Reel.Deel my goal is to use/pipe avs+ 64bit directly to x264 I'm trying this mod but getting Error: failed to load avisynth.dll
There are 2 builds: for x86 and x64 arch. You should use avs2yuv64.exe for x64 avisynth (:

[Mug Funky]

Yep, it's me. Was working outside of video for a while but I'm doing a bit of it these days.
Also as you can see from my avatar, life happened (a couple of times), which limited my ability to spend time on forums.

[DJATOM]

Error: failed to load avisynth.dll
Managed to trigger that bug. Using latest avisynth+ dll solves it. I'll investigate later.

[Motenai Yoda]

Ok tried them
- MasterNobody: I get an horizontal scrolling stuff with unaligned scrolling chroma
- DJATOM now work but I get only a green video, with values only as lsb, and scrolling to the left as MasterNobody's one.

avs+ 64bit version r2172

script:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource",3)
lsmashvideosource("tt1.avs_lossless.mp4")

Dither_convert_8_to_16()

dither_out()
#~ ConvertFromStacked()
ConvertFromDoubleWidth()
Prefetch(threads=4)

batch:
"%~dp0avs2yuv64.exe" -depth 16 %1 -o - | "%~dp0x264-10bit.exe" --qp 0 --preset ultrafast --input-res 1920x1036 --fps 24000/1001 --input-depth 16 -o %1_lossless.mp4 -

[MasterNobody]

Ok tried them
- MasterNobody: I get an horizontal scrolling stuff with unaligned scrolling chroma
- DJATOM now work but I get only a green video, with values only as lsb, and scrolling to the left as MasterNobody's one.
...
"%~dp0avs2yuv64.exe" -depth 16 %1 -o - | "%~dp0x264-10bit.exe" --qp 0 --preset ultrafast --input-res 1920x1036 --fps 24000/1001 --input-depth 16 -o %1_lossless.mp4 -

You need to use "-raw" option for avs2yuv with such x264 command line.
Or better you should use "--demuxer y4m" option for x264 than you wouldn't need "--input-res 1920x1036 --fps 24000/1001 --input-depth 16" there as it would get this info from y4m format (which is default in avs2yuv without "-raw" option).

[Motenai Yoda]

You need to use "-raw" option for avs2yuv with such x264 command line.
Or better you should use "--demuxer y4m" option for x264 than you wouldn't need "--input-res 1920x1036 --fps 24000/1001 --input-depth 16" there as it would get this info from y4m format (which is default in avs2yuv without "-raw" option).

ok so with --demux y4m or -raw and --demux raw both works well.

[tormento]

Resurrection of a very old thread: done. :)

There is something I need your help with x264 encoding.

Perhaps I am now a bit spoiled with x265 HBD support and I tried to have the same thing in x264.

I tried to use the x264 (8 bit) --input-depth 16 parameter (unfortunately no --dither found) but what I got is

avs [info]: AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
avs [info]: avisynth 16bit hack enabled
avs [info]: 960x800 0:0 @ 24/1 fps (cfr)

instead of dealing with the original 1080p source.

Is there a way to let x264 properly manage a HDB source?

[stax76]

I don't know why you get this avisynth 16bit hack enabled, I'm not getting it:

Width : 1280
Height : 720
Frames : 638
Time : 00:21.561
Framerate : 29.590176 (200000/6759)
Format : YUV420P16

x264 --crf 22 --synth-lib D:\AviSynth.dll --output aaa.h264 aaa.avs

avs [info]: using external Avisynth library from: "D:\AviSynth.dll"
avs [info]: AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
avs [info]: 1280x720 0:0 @ 200000/6759 fps (cfr)
avs [info]: color matrix: bt709
x264 [info]: AVC Encoder x264 core 161 r3048+25 be33c5d [Mod by Patman]
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile: High 10, level: 3.1, subsampling: 4:2:0, bit-depth: 10-bit

Please note that --input-depth can only be used for raw input, the avs reader is not raw, only pipe or .yuv file can be raw.

[tormento]

I don't know why you get this avisynth 16bit hack enabled, I'm not getting it
I am feeding StaxRip with the following .avs

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_53 gentlemen, The\gentlemen.dgi",ct=140,cb=140,cl=0,cr=0)
SMDegrain (tr=4, thSAD=400, refinemotion=false, n16_out=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Prefetch(6)

AND I am using x264 8 bit. not 10 bit one. Plus source is 1080p, don't know if relevant.

VersionString: AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 15:47:06 (UTC)
PluginDir2_5 (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64
PluginDir+ (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64+
Please note that --input-depth can only be used for raw input, the avs reader is not raw, only pipe or .yuv file can be raw.
So how should I feed a 16 bit source?

[tormento]

Nobody? :(

[stax76]

Think about it, you are asking about a x264 problem, and then you are not even posting the full x264 output, so we don't even know what type of x264 build you use, I think you should try a Patman or DJATOM build.

[MasterNobody]

I am pretty match sure that he has problems exactly because he use unofficial build of x264. Official x264 doesn't have "avisynth 16bit hack enabled" patch which looks like to cause problems for him.

[tormento]

I think you should try a Patman or DJATOM build.
I was using DJATOM one. Will do another try with the one now included with StaxRip.

[tormento]

Ok, just ripped a BD to do another try. Same issue.

Original video:

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Duration : 1 h 55 min
Bit rate mode : Variable
Maximum bit rate : 35.9 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

AVS script:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_55 Pantera Rosa, La\pantera.dgi",ct=132,cb=132,cl=0,cr=0)
CompTest24(1)
SMDegrain (tr=4, thSAD=400, refinemotion=false, n16_out=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Prefetch(6)

Plain vanilla StaxRip log:

------------------------- System Environment -------------------------

StaxRip : 2.1.8.5
Windows : Windows 10 Enterprise 2009
Language : Italian (Italy)
CPU : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
GPU : NVIDIA GeForce GTX 1060 3GB, Intel(R) HD Graphics 3000
Resolution : 1920 x 1080
DPI : 96
Code Page : 1252

----------------------- Media Info Source File -----------------------

F:\In\1_55 Pantera Rosa, La\pantera_4.avs

General
Complete name : F:\In\1_55 Pantera Rosa, La\pantera_4.avs
File size : 979 Bytes

---------------------------- Configuration ----------------------------

Template : x264
Video Encoder Profile : x264
Container/Muxer Profile : MKV (mkvmerge)

--------------------------- AviSynth Script ---------------------------

Import("F:\In\1_55 Pantera Rosa, La\pantera_4.avs")

------------------------- Source Script Info -------------------------

Width : 1920
Height : 816
Frames : 3327
Time : 02:18.764
Framerate : 23.976023 (24000/1001)
Format : YUV420P16

------------------------- Target Script Info -------------------------

Width : 1920
Height : 816
Frames : 3327
Time : 02:18.764
Framerate : 23.976023 (24000/1001)
Format : YUV420P16

--------------------------- Video encoding ---------------------------

x264 0.161.3048+25-gcc10.2.0 Patman Mod

D:\Eseguibili\Media\StaxRip\Apps\Encoders\x264\x264.exe --crf 20 --preset slow --aq-mode 2 --colorprim bt709 --colormatrix bt709 --transfer bt709 --input-depth 16 --opencl --output "F:\In\1_55 Pantera Rosa, La\pantera_4_temp\pantera_4_out.h264" "F:\In\1_55 Pantera Rosa, La\pantera_4_temp\pantera_4.avs"

avs [info]: AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
avs [info]: avisynth 16bit hack enabled
avs [info]: 960x816 0:0 @ 24000/1001 fps (cfr)
avs [info]: color matrix: bt709
x264 [info]: AVC Encoder x264 core 161 r3048+25 be33c5d [Mod by Patman]
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation NVIDIA GeForce GTX 1060 3GB
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile: High, level: 3.1, subsampling: 4:2:0, bit-depth: 8-bit
x264 [info]: opencl=1 cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=2:1.00
x264 [info]: frame I:142 Avg QP:16.55 size: 78167
x264 [info]: frame P:870 Avg QP:20.05 size: 13960
x264 [info]: frame B:2315 Avg QP:22.14 size: 3353
x264 [info]: consecutive B-frames: 5.6% 1.1% 11.5% 81.9%
x264 [info]: mb I I16..4: 11.2% 80.0% 8.9%
x264 [info]: mb P I16..4: 1.2% 4.9% 0.4% P16..4: 41.9% 14.5% 8.9% 0.0% 0.0% skip:28.1%
x264 [info]: mb B I16..4: 0.0% 0.3% 0.0% B16..8: 41.8% 3.0% 0.5% direct: 1.3% skip:52.9% L0:39.9% L1:55.2% BI: 4.9%
x264 [info]: 8x8 transform intra:78.9% inter:71.5%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra: 85.0% 67.7% 40.6% inter: 9.0% 13.2% 0.2%
x264 [info]: i16 v,h,dc,p: 39% 18% 8% 34%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 9% 6% 9% 13% 12% 12% 11% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 6% 3% 13% 17% 15% 13% 11% 12%
x264 [info]: i8c dc,h,v,p: 29% 33% 26% 12%
x264 [info]: Weighted P-Frames: Y:3.0% UV:2.4%
x264 [info]: ref P L0: 66.1% 13.8% 14.2% 3.2% 2.7% 0.0% 0.0%
x264 [info]: ref B L0: 89.5% 8.7% 1.6% 0.3%
x264 [info]: ref B L1: 95.7% 4.3%
x264 [info]: kb/s:1787.67
encoded 3327 frames, 14.63 fps, 1787.67 kb/s, duration 0:03:47.42

Start: 09:08:00
End: 09:11:51
Duration: 00:03:50

General
Complete name : F:\In\1_55 Pantera Rosa, La\pantera_4_temp\pantera_4_out.h264
Format : AVC
Format/Info : Advanced Video Codec
File size : 29.6 MiB
Writing library : x264 core 161 r3048+25 be33c5d [Mod by Patman]

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings : CABAC / 5 Ref Frames
Format, CABAC : Yes
Format, Reference frames : 5 frames
Width : 960 pixels
Height : 816 pixels
Display aspect ratio : 1.176
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 161 r3048+25 be33c5d [Mod by Patman]
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

---------------------------- Muxing to MKV ----------------------------

mkvmerge 55

D:\Eseguibili\Media\StaxRip\Apps\Support\MKVToolNix\mkvmerge.exe -o "F:\In\1_55 Pantera Rosa, La\pantera_4.mkv" "F:\In\1_55 Pantera Rosa, La\pantera_4_temp\pantera_4_out.h264" --ui-language en

mkvmerge v55.0.0 ('Waiting For Space') 64-bit
'F:\In\1_55 Pantera Rosa, La\pantera_4_temp\pantera_4_out.h264': Using the demultiplexer for the format 'AVC/H.264'.
'F:\In\1_55 Pantera Rosa, La\pantera_4_temp\pantera_4_out.h264' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'F:\In\1_55 Pantera Rosa, La\pantera_4.mkv' has been opened for writing.
The cue entries (the index) are being written...
Multiplexing took 0 seconds.

Start: 09:11:51
End: 09:11:52
Duration: 00:00:00

General
Complete name : F:\In\1_55 Pantera Rosa, La\pantera_4.mkv
Format : Matroska
Format version : Version 4
File size : 29.6 MiB
Duration : 2 min 18 s
Overall bit rate : 1 790 kb/s
Encoded date : UTC 2021-03-15 08:11:52
Writing application : mkvmerge v55.0.0 ('Waiting For Space') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings : CABAC / 5 Ref Frames
Format, CABAC : Yes
Format, Reference frames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2 min 18 s
Bit rate : 1 788 kb/s
Width : 960 pixels
Height : 816 pixels
Display aspect ratio : 1.176
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.095
Stream size : 29.6 MiB (100%)
Writing library : x264 core 161 r3048+25 be33c5d [Mod by Patman]
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

---------------------------- Job Complete ----------------------------

Start: 09:07:59
End: 09:11:52
Duration: 00:03:52

Output video:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2 min 18 s
Bit rate : 1 788 kb/s
Width : 960 pixels
Height : 816 pixels
Display aspect ratio : 1.176
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.095
Stream size : 29.6 MiB (100%)
Writing library : x264 core 161 r3048+25 be33c5d [Mod by Patman]
Encoding settings : opencl=1 / cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[qyot27]

As the others said before, don't use --input-depth. At all. Period. x264 does not require special arguments to understand AviSynth+'s high bit depth formats.

The 16bit hack was a way of getting around the fact that Interleaved16 format is twice the width of the intended output, and using --input-depth was the method by which you could override the avs module's treatment of a script as 8bit (in the days before AviSynth+ supported high bit depth and x264 could accept those formats - both of which were possible by September 2016), which made the module perform essentially the same function as ConvertFromDoubleWidth() and pass the content over to the encoder as 16bit and the correct width instead of 8bit and double width.

[tormento]

As the others said before, don't use --input-depth. At all. Period. x264 does not require special arguments to understand AviSynth+'s high bit depth formats.
Huh, ok. I thought it was the same switch as with x265, as I saw that --input-depth could get from 8 to 16 as parameter.

[jpsdr]

Hum...
https://github.com/jpsdr/x264/commit/c27fa60a845fb105343846bf95f7892b6e208806
According what avs is now, do you think it should be removed in the future builds ?
And just keep

info->csp |= X264_CSP_HIGH_DEPTH;

[MasterNobody]

Hum...
https://github.com/jpsdr/x264/commit/c27fa60a845fb105343846bf95f7892b6e208806
According what avs is now, do you think it should be removed in the future builds ?
And just keep

info->csp |= X264_CSP_HIGH_DEPTH;

Remove this patch at all or fix condition to:
if( opt->bit_depth > 8 && !(info->csp & X264_CSP_HIGH_DEPTH) )

[tormento]

According what avs is now, do you think it should be removed in the future builds ?
It would be nice to have the same behaviour of x265 for input-depth and an added dither parameter.

[qyot27]

Hum...
https://github.com/jpsdr/x264/commit/c27fa60a845fb105343846bf95f7892b6e208806
According what avs is now, do you think it should be removed in the future builds ?
And just keep

info->csp |= X264_CSP_HIGH_DEPTH;


The only reason to keep it is for anybody still clinging to 2.6 instead of switching to Plus, because if they're using Plus, the high bit depth formats are correctly handled without the patch, and if they have to rely on plugins that still haven't been updated to support native high bit depth and still output as Interleaved16, Plus provides its own function - ConvertFromDoubleWidth (in the ConvertStacked plugin that's distributed with the core) - that does the job of stitching it back into a proper 16bit image without having to have the client program muck around with it.

Whereas, there's a danger of the 16bit hack being always enabled instead of only on-demand and screwing up HBD input by bit-shifting non-double-width HBD content (which is probably the source of the complaint here, because --input-depth is supposed to be a no-op for any formats that have their properties detected, like avs and y4m). Keeping the patch with its current behavior would likely mean that the only correct way to use it with Plus and >8bit is to use ConvertToDoubleWidth in the script to tell Plus to output in Interleaved16, completely defeating the purpose of supporting those formats correctly.

[tormento]

The only reason to keep it is for anybody still clinging to 2.6 instead of switching to Plus, because if they're using Plus
There is absolutely no reason not to switch to AVS+ from 2.6, as there are no compatibility issues or limitations. Sometimes it's necessary to move on.

[jpsdr]

I'll go with MasterNobody's fix.
:thanks:

[videoh]

There is absolutely no reason not to switch to AVS+ from 2.6 I'll second that.

[Richard1485]

There is absolutely no reason not to switch to AVS+ from 2.6, as there are no compatibility issues or limitations. Sometimes it's necessary to move on.

Agreed. It took me a long time to jump ship to AviSynth+, but even I've moved on.

[tormento]

Any update, guys?

[StainlessS]

Any update, guys?

Yeh, I'll third and forth it. :)

[tormento]

Yeh, I'll third and forth it. :)
Too slang for me. Please translate :)

[StainlessS]

I'll go with MasterNobody's fix.
:thanks:
I'll second that.
Any update, guys?
Yeh, I'll third and forth it. :)
Sorry T, not so amusing. :)

[jpsdr]

I don't intend to make a new build for now, as it take a long time, and the last update has no effect on PC build. I'll make a new build only when there is a "significant" update => A fix, or a new feature.
But i've updated the github, so, feel free... ;)

[tormento]

I'll make a new build only when there is a "significant" update => A fix, or a new feature.
Having x264 to accept 16 bit format is a great update. :p

Any chance to include the -dither part of x265 into x264?

I hope someone more skilled than me will compile that build. :D

[jpsdr]

I forgot. I made a quick not frofiled t_mod test build for FranceBB to test his xavc patch, this build include the 16 bits avs fix, you can check/test it.

[tormento]

I forgot. I made a quick not frofiled t_mod test build for FranceBB to test his xavc patch, this build include the 16 bits avs fix, you can check/test it.
Already testing. :)

Using internal dither is way faster than dithering with AVS+ scripts, we are talking about 15-20% when going from 16bit to 8/10 bit.

[FranceBB]

feeding 16bit planar works like a charm! :)
XAVC Classes also work like a charm! :D

So... I think the Changelog is something like:

- It's now possible to feed 16bit planar directly from Avisynth+
- It's now possible to encode in XAVC Intra Class 50, 100, 200, 300 and 480

x264.exe "AVS Script.avs" --avcintra 50 --avcintra-flavor sony

x264.exe "AVS Script.avs" --avcintra 100 --avcintra-flavor sony

x264.exe "AVS Script.avs" --avcintra 200 --avcintra-flavor sony

x264.exe "AVS Script.avs" --avcintra 300 --avcintra-flavor sony

x264.exe "AVS Script.avs" --avcintra 480 --avcintra-flavor sony

ColorBars in XAVC Intra Classes: https://we.tl/t-Sza28LpyXo

Now I'm finally happy here at work! :D

Once enough people have tested it, if you could make a final build with OpenCL enabled in x64 that would be great!

(and only if you have time and just for my old computer sitting at home, an x86 XP compatible build would be very sweet too for me and other xp die-hard)

[jpsdr]

I don't do OpenCL, and post #43 still valid. Check on my standard realeases if x86 builds are XP compliant, the next ones will not be different.

[FranceBB]

I don't do OpenCL

Oh, that's a shame...



Check on my standard realeases if x86 builds are XP compliant

Nope, Bcrypt and AcquireSRWLockExclusive are missing... Well, it doesn't matter...

The important thing is that I've got the classes on Win10. ;)

[jpsdr]

New proper released build, not a quick version.