Garbled Progress Spinner on Windows

[kylophone]

This is the bit of code responsible for that spinner: https://github.com/Netflix/vmaf/blob/master/libvmaf/tools/vmaf.c#L298-L301

[1480c1]

I'm not so sure if any of the windows' terminals accepts the ansi escape sequences well (the \033[K) also looking at spiner.h, it looks like it contains unicode, and unicode support on Windows is pretty much something you either want to leave up to another library or will be the thing that causes you to curse windows' design

https://stackoverflow.com/questions/10882277/properly-print-utf8-characters-in-windows-console

[kylophone]

I'm not so sure if any of the windows' terminals accepts the ansi escape sequences well (the \033[K) also looking at spiner.h, it looks like it contains unicode, and unicode support on Windows is pretty much something you either want to leave up to another library or will be the thing that causes you to curse windows' design

I guess we should #ifdef this away. If you have a suggestion, I'm open to it.

[1480c1]

You could try what's mentioned in https://stackoverflow.com/a/19071749 using SetConsoleOutputCP(65001); and then immediately flushing it

[lusoris]

We addressed the two independent Windows console problems in VMAFx #1223: glyph encoding and erase-line handling.

The interactive CLI attempts to enable UTF-8 output and VT processing, restoring the previous console state afterward. If either capability is unavailable, the spinner helpers choose ASCII | / - \ instead of UTF-8 braille, and spaces instead of \033[K when VT is unavailable. That keeps a usable progress display on legacy consoles without assuming that changing the code page also enables ANSI escapes.

This is merged fork implementation guidance, not a Windows runtime validation of current upstream or the MSVC PRs. Our CLI is now C++, so its console-state guard would need adaptation for upstream's C CLI; the glyph/erase selection helpers are plain C.