10-bit Encoding with DitherTools

[MysteryX]

I'm trying to do 10-bit encoding with DitherTools as described here.

My script ends with Dither_out() and I run this command

Encoder\avs2yuv.exe -raw "Job1_Script.avs" -o - | Encoder\x264-10b.exe --demuxer raw --input-depth 16 --input-res 940x720 --fps 25 --preset veryslow --crf 24 --psy-rd 1:0.05 --output "Job1_Output.264" --frames 13710

x264 throws an error "No input file" and then exits.

Any idea what I'm doing wrong?

[sneaker_ger]

You forgot the "-" (stdin input) in the x264 command.

[MysteryX]

... yeah that works

[AzraelNewtype]

Incidentally, if you're using the latest avs2yuv, you can just be doing:

Encoder\avs2yuv.exe -depth 16 "Job1_Script.avs" - | Encoder\x264-10b.exe --demuxer y4m --preset veryslow --crf 24 --psy-rd 1:0.05 --output "Job1_Output.264" --frames 13710 -

It's nice if you're using non-standard resolutions and don't want to remember exactly what you have.

[MysteryX]

Originally Posted by AzraelNewtype

Incidentally, if you're using the latest avs2yuv

Perhaps the DitherTools documentation could be updated to reflect this? This would have saved me some time; and saved the forum from this thread

[AzraelNewtype]

Originally Posted by MysteryX

Perhaps the DitherTools documentation could be updated to reflect this? This would have saved me some time; and saved the forum from this thread

Well, no, because you'd still have forgotten the - on x264 side, and that's never going to stop being necessary. The depth hack isn't magic, it just lets y4m headers handle some of the grunt work of connecting.

[MysteryX]

The code to pipe through x264 as y4m was already written; I wouldn't have had to retouch that code and develop a bunch of other "stuff" around it to get the right values through.

[MysteryX]

I downloaded v0.24bm3 here
http://avisynth.nl/index.php/Avs2YUV

First time I tried it, the script froze during initialization.

The second time it started encoding and then froze at 4.2%.

No error message or anything, just froze. It's not using the CPU anymore. This isn't working.

I'll go back to the RAW method unless there is a solution to this.

Edit: It appears v0.24bm3 is broken as the RAW method isn't working either. If I revert back to the version of avs2yuv I had before, it's working in RAW format. I don't know which version I have but the file is 20,480 bytes (while the latest version is 39kb)

[Sparktank]

I use this from taro_06:
http://tmod.nmm-hd.org/avs4x26x/

"avs4x26x.exe" --x26x-binary "x264_kMod\k8_64.exe" --demuxer raw --input-depth 16 --input-res 1920x1080 --othersettings -o "output.mkv" "script.avs"

He renamed it because it now supports piping AVS to: x262, x264, x265. Should support all various builds (vanilla, tmod, kmod, etc).

[MysteryX]

And his build doesn't require the use of command pipe.

By the way, I encoded this video with a 10-bit encoding chain
10-bit encoding (90.9 MB)
8-bit encoding (92.2 MB)

I ended my script like this to provide 10-bit output

Double="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=2)"""
SuperRes(2, 0.43, 0, Double, lsb_upscale=true, lsb_out=true)
Dither_out()

Now here's what's interesting. The two videos have the same dimensions (940x720), but they are stretched differently vertically, in favor of the 10-bit version. The 8-bit video is losing a few lines at the bottom and the video is stretched (distorted) vertically! Any idea why this is happening?

[Sparktank]

Are all of what you're using updated?

Don't know what your command looks like piping to what.

[MysteryX]

My command pipe is written in the first post. To execute that from a program, I have to run "cmd /c" followed by the rest of the command

[Groucho2004]

Originally Posted by MysteryX

To execute that from a program, I have to run "cmd /c" followed by the rest of the command

Why don't you use CreateProcess()? It provides much better control of the child process.
Maybe I'm missing something here?

[MysteryX]

Originally Posted by Groucho2004

Why don't you use CreateProcess()? It provides much better control of the child process.
Maybe I'm missing something here?

Piping with '|' is a feature of the command shell. If I want to execute a process directly, I would have to somehow implement that feature myself (complicated). The simplest workaround is to start the process "cmd" which has that feature instead of starting the "avs2yuv" process directly.

With that being said... does avs4x26x support FFMPEG?

And I was also using avs2yuv to execute scripts that write values into a text file; can I use avs4x26x for that?

[Sparktank]

Originally Posted by MysteryX

does avs4x26x support FFMPEG?

No, just the x26x encoders.

[MysteryX]

Yeah... I'll have to stick to avs2yuv then. I use ffmpeg for 8-bit encoding and a separate x264.exe for 10-bit encoding. Plus I use it to run quick scripts.

Any idea why the latest version of avs2yuv is freezing?

Or I'll stick to 'raw' mode; that works.

[MasterNobody]

Originally Posted by MysteryX

Yeah... I'll have to stick to avs2yuv then. I use ffmpeg for 8-bit encoding and a separate x264.exe for 10-bit encoding. Plus I use it to run quick scripts.

Any idea why the latest version of avs2yuv is freezing?

Or I'll stick to 'raw' mode; that works.

I would guess your freezing problem is due your AviSynth version and not due avs2yuv itself. What AviSynth version do you use? Probably some of the non-official versions with MT support that is cause of the most problems a specially when using with plugins developed without thread safety in mind (which is ok for ST official builds but not for MT builds). Try one of official builds to check if it freeze also. Also you can try to set add SetMTMode(0,0) at start of the script to disable multithreading in MT-build. As for why your avs2yuv do not freeze is probably because it is so old that it doesn't add Distributor() for MT automatically and so you still use it as single-threaded.

[MysteryX]

I use AviSynth 2.6 MT.

I was recommended specifically *NOT* to add "Distributor" at the end of the script as it just creates additional threads on top of the multi-threading already taking place.

[Groucho2004]

Originally Posted by MysteryX

I was recommended specifically *NOT* to add "Distributor" at the end of the script as it just creates additional threads on top of the multi-threading already taking place.

Using named pipes presents a different scenario. When you transfer frames from Avisynth to x264 via stdout, the tool piping the frames and the encoder have to call "Distributor()".

[MysteryX]

Originally Posted by Groucho2004

Using named pipes presents a different scenario. When you transfer frames from Avisynth to x264 via stdout, the tool piping the frames and the encoder have to call "Distributor()".

Why?

In any case, the old version of avs2yuv works with AviSynth 2.6 MT and it is multi-threaded otherwise performance would be much lower on my 8-core system.