Error occurs if the file name to be loaded by avs contains Japanese characters.

[buccimoni]

I'm currently using "x265-Asuna-3.4+13-g729a838d3+38". I'm using "x265-Asuna-3.4+13-g729a838d3+38" to encode the avs file directly. If I do the same and change the binary to "x265-Yuuki-3.5+2-g2b25c9ba0+45", I get an error.

--- error begin .\bin\x265-Yuuki-3.5-gcc-10-lite.exe --input .\demux_Plus.avs --output test.265 avs+ [info]: AviSynth+ 3.7.0 (r3382, 3.7, x86_64) avs+ [error]: Error loading file: MPEG2Source: Could not open one of the input files. (.\demux_Plus.avs, line 52) x265 [error]: unable to open input file <.\demux_Plus.avs> --- error end

I am using MPEG2Source() in the avs file to load the d2v file, and the cause seems to be the presence of Japanese in the name of the source file described in the d2v file. If you use only alphabetic file names, the error does not occur and the encoding can be done normally.

If possible, I would like to pass avs directly like x265-Asuna to encode the file.

[buccimoni]

Additional Notes. If the character encoding of the d2v file output by DGIndex is SJIS, AviSynth+ outputs an error on x265-Yuuki, but not on x265-Asuna 3.4. If you convert the d2v file to UTF-8, it will be encoded correctly. However, the tool I'm running at the same time doesn't seem to work unless the d2v file is in SJIS. It would be nice if x265-Yuuki 3.5 could also handle SJIS.

[msg7086]

Sounds like a missing patch on Yuuki branch. I'll check when I have time.

[tana3n]

I tried it, and it seems to be caused by this commit(b5a411d52ce086cdcd2d38f38d47c666598d5ba7).

The same thing seems to be reported with x264(in Japanese diary). x264 UTF-8になったとかそんなところのメモ - ..たれろぐ.. This seems to occur in non-UTF-8 environments.

When I checked, changing from UTF-8 to Shift-JIS in the activeCodePage of x265res.manifest.in improved the problem. However, other problems may occur. It's not bad for individuals to build and use, but I don't know if it should be merged considering the UTF-8 environment.

[buccimoni]

I tried it, and it seems to be caused by this commit(b5a411d).

The same thing seems to be reported with x264(in Japanese diary). x264 UTF-8になったとかそんなところのメモ - ..たれろぐ.. This seems to occur in non-UTF-8 environments.

When I checked, changing from UTF-8 to Shift-JIS in the activeCodePage of x265res.manifest.in improved the problem. However, other problems may occur. It's not bad for individuals to build and use, but I don't know if it should be merged considering the UTF-8 environment.

Thank you very much for your kind information. When the activeCodePage part was corrected to Shift-JIS and the build was performed, the operation as expected could be performed. Although this is contrary to the trend toward UTF-8, I personally would like to use the one I built myself.

[msg7086]

https://down.7086.in/x265-Yuuki-Asuna/x265-gcc-multilib-full-ansi-test.7z Can you please try this version?

[buccimoni]

https://down.7086.in/x265-Yuuki-Asuna/x265-gcc-multilib-full-ansi-test.7z Can you please try this version?

I tried x265-gcc-multilib-full-ansi-test.7z and was able to encode successfully on Windows 10 Shift-JIS environment. My build is working, but I would like to use this binary. Many thanks!

[msg7086]

大丈夫そうですね。今後はANSIバージョンもいれます。