Quote:
Originally Posted by Heaud
I never got y4m to work outside of 8-bit with my local setup consisting of: If the overhead performance cost is negligible for using raw over y4m, then I am fine with piping raw. |
Of course it wouldn't work with >8bit, you're not using AviSynth+. x265 doesn't support inputting the Stacked/DoubleWidth hack formats and reconstituting them into high bit depth. There was never a patch for that (the one for x264 to allow that was implemented in the avs input module; x265 doesn't have a dedicated avs input), and AviSynth+ made such a patch irrelevant anyway.
And that build doesn't output MKV, since that's just a normal build from the main project's development tip, and there is no containered output support in the main project's bitbucket repo (Yuuki-Asuna supports both MKV and MP4 output). You're outputting raw .hevc with an incorrect extension.
Quote:
|
Originally Posted by `Orum
Ah, thanks, I wasn't aware there were builds linked against LAVF. I know the x264 builds I use, while supporting 10-bit input, still don't work directly with 10-bit output from an avs script though for some reason (can't recall right now what it was and I'm not on my usual encoding machine). I'm still piping via avs2yuv64 there, but if either x264/x265 supported the 10-bit input directly from the script, that'd be much more convenient.
|
x264 is simply set up to always output 4:2:0 unless the user overrides it (even if the input wasn't 4:2:0). Normally, bit depth wasn't a part of it, because x264 only gained multi-bit support on
December 24th, 2017. Despite now having 8-bit and 10-bit in a single build, multi-bit builds still default to 8bit rather than outputting in the same depth as the input, likely for the same reason you have to override it so it doesn't automatically convert your input to 4:2:0 - hardware compatibility. H.264-capable hardware players are almost always restricted to 8-bit 4:2:0.