Opened 8 years ago

Last modified 4 years ago

#5721 new defect

bug in AviSynth reader

Reported by: stax76 Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: avisynth
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

On a English System with CP 1252 a AviSynth script can not have a Unicode file name because AviSynth supports only ANSI, on a Russian system with CP 1251 it's possible as long as the Unicode chars can be converted to the local Windows/ANSI CP. MPC can open such a script but not ffmpeg.

You can reproduce this by changing your locale to Russian like so:

http://www.fuzeqna.com/capcomsupport/wf/uploadfiles/image/languagechangevista.jpg

Now MPC and VirtualDub can open a script called Предприятий.avs but ffmpeg can't.

Change History (3)

comment:1 by Carl Eugen Hoyos, 8 years ago

Component: ffmpegundetermined
Keywords: avisynth added

comment:2 by Elon Musk, 4 years ago

Does this still happens?

comment:3 by stax76, 4 years ago

I made a test using a sample file Bär.mkv (German Umlaut) on CP 1252 (West Europe) and saved the avs file not as CP 1252 but UTF-8 without BOM, VirtualDub2, MPC-BE and ffmpeg are still able to open this, even though avs files are supposed to be encoded in the CP of the system, CP 1252 here.

I think it can be closed.

But I also think ffmpeg should use a Unicode manifest to enforce UTF-8, there might be some complaints then, it might break some applications etc.

There is clearly a new trend for enforcing UTF-8, see here:

https://github.com/staxrip/staxrip/wiki/AviSynth-Unicode-support-on-Windows-10-1903

If it won't be supported I guess I will patch it somehow.

Note: See TracTickets for help on using tickets.