While it sounds appealing, x265 isn't really that useful at this point outside of personal testing and/or development. If you don't know how to compile and/or use the command prompt executables it's probably not a good idea to use it at this time. Ease of use GUIs will come when it is suitable for mass use.

The real problem is that neither the updated 14496-15 3rd edition nor the Matroska specs on storing HEVC have been finalized, so HEVC-in-MP4 or -MKV files created now may not work correctly later. Although, at least HEVC can be decoded by libavcodec and the various relevant demuxers in libavformat have been updated to include HEVC demuxing; those'll simply need to be tweaked a little when the final specs are published.

Further, Zarx264gui now relies on accessing libx264 through FFmpeg. libx265 currently cannot be used through libavcodec, and the patch that was posted to libav-devel as a proof-of-concept has already gotten outdated by x265's currently moving API. So even though you can use the x265 binary itself, it's not yet reached enough of a plateau to reliably get integrated with other programs.

It's gotten some pretty massive improvements recently, though: stdin support for YUV and Y4M*, preset/tune support (and newer, saner defaults to go along with it), crf support, rext** stuff (although I've barely tested with that), and the assembly optimizations are coming through in a fairly steady stream so it is much faster (and getting faster) than the glacial speeds of the HM encoder or builds from when x265 was first publicly announced back in July.

*AviSynth input is still not there; but since FFmpeg supports AviSynth, you can pipe from FFmpeg to x265:

**read: 4:2:2 and 4:4:4, some 10-bit and 12-bit stuff; all of which is still very much a work in progress on that front, but it does potentially mean that users who've gotten used to using 10-bit H.264 won't have to drop back to 8-bit H.265/HEVC before going being able to do 10-bit encodes again (although currently, the aforementioned assembly optimizations are focusing mainly/only on the 8-bit parts of x265; so using the 16-bit build will be much slower).

That ffmpeg is 64-bit. Unless you're using AviSynth64 or a 64-bit build of AviSynth+ (the 64-bit support in which is still in an early development phase) with 64-bit plugins, that will fail. You have to use 32-bit ffmpeg with 32-bit AviSynth(+) and 32-bit plugins. A 32-bit ffmpeg can pipe to a 64-bit x265, though.

Qyot27 wrote:That ffmpeg is 64-bit. Unless you're using AviSynth64 or a 64-bit build of AviSynth+ (the 64-bit support in which is still in an early development phase) with 64-bit plugins, that will fail. You have to use 32-bit ffmpeg with 32-bit AviSynth(+) and 32-bit plugins. A 32-bit ffmpeg can pipe to a 64-bit x265, though.

It also goes without saying that 64-bit builds of AvxSynth can be used with 64-bit builds of ffmpeg on Linux and OSX, but that's generally irrelevant for the average user (also, because one of the stated goals for AviSynth+ is to add cross-platform support, which will eclipse AvxSynth entirely).

The issue is that you're passing YUY2 (yuyv422 in ffmpeg parlance) instead of YV12 (yuv420p). Use ConvertToYV12() at the end of the script; the rext support that would be able to do 4:2:2 is not ready to use at this point. Also there seems to be something that wasn't compiled against a static libgcc, but checking both Zeranoe's build of ffmpeg from October 26th and avs4x265, neither one of them shows that as a dependency.

The problem seems to be that something about the Command Prompt is broken. It's not expanding the %1 and %~n1 placeholders correctly (insert obligatory 'this is why I prefer bash' comment). That might also serve to explain why running this stuff plain wasn't working either - if the Prompt is borked, then who knows what's actually wrong.

Qyot27 wrote:The problem seems to be that something about the Command Prompt is broken. It's not expanding the %1 and %~n1 placeholders correctly (insert obligatory 'this is why I prefer bash' comment). That might also serve to explain why running this stuff plain wasn't working either - if the Prompt is borked, then who knows what's actually wrong.

What brings you to that conclusion? I would assume the user would be complaining about software such as zarxgui not working if that were the case. I have heard that ffmpeg only works well with AviSynth 2.6, but I don't know exactly how that would error out.