Both MPlayer and Mencoder can be used from the command line (shell). MPlayer also includes Mencoder which is a powerful video conversion program. It handles many file formats, and can play CDs, VCDs and DVDs. MPlayer is a multi-platform media player. 8.3.8.1 Increase or decrease gamma, contrast, brightness, saturation.8.3.5 Rip DVD into quality compressed avi.
8.3.2 Split a video in a series of static images.8.3.1 Create an animation from a series of static images.8.2 Frame rate conversions and slow-motion.
So maybe on other languages it may not be perfect, I won't pretend that my small subset of subtitles is relevant to the whole world, but it sure looks better in my particular case.Īnd assuming that uchardet (based on the same algorithm) works the same, looks like it would be a lot better than present situation.
On the other hand, I tested the chardetect utility which is a re-implementation of the Mozilla auto-detection code in python and it gave me 100% good answers on a dozen of subtitle files (some using UTF-8, others EUC-KR or CP949) with a 0.99 confidence. So basically that's "normal" that detection fails all the time because Japanese and Korean are indeed not supported. Right now, I get 100% detection failure on Japanese and Korean subtitles as soon as they don't use UTF-8.Īlso by checking further, I see that enca -list languages would give a list of languages which confirms the website. Well it can't be worse than the current situation. So could we reopen the current feature request? :-) Of course in a perfect world, everybody would just switch to UTF-8, but in the current flawed world, a lot of people are still writing subtitles with other encoding (in Asian countries at least).
This has been bothering me for years (in mplayer as well, and in other video players under Linux most FLOSS software are not very "encoding-friendly" to non-westerners). And this is annoying that each time they were not written in UTF-8, I have to get the command line out to specify an encoding. I am myself regularly reading Korean subtitles, and sometimes Japanese subtitles. On the other side, uchardet seems to support quite a bit of encoding, and I imagine that Mozilla Firefox algorithm should not be too crappy if they want to be used in every country in the world. Moreover from the last release post: « enca is in maintenance mode only and I have no intentions to write new features » That seems quite limited (and in particular in the Asian side, except for Chinese), with mostly Latin and Cyrillic languages.
So I assume the rpmfusion build is compiled with ENCA on.Īlso I read in the ENCA package description on Fedora: « Currently, it has support for Belarussian, Bulgarian, Croatian, Czech, Estonian, Latvian, Lithuanian, Polish, Russian, Slovak, Slovene, Ukrainian, Chinese and some multibyte encodings (mostly variants of Unicode) I have no idea where to find the spec file which made the mpv RPM, but when I check ENCA to be uninstalled, it requires me to uninstall mpv as well. I am using the rpmfusion build for Fedora 22. Is there a runtime way to know whether or not the mpv binary is compiled with ENCA on?