summaryrefslogtreecommitdiffstats
path: root/player/external_files.c
Commit message (Collapse)AuthorAgeFilesLines
* player: make track language matching case insensitivewm42017-12-231-1/+1
| | | | | | | | | There is no reason not to do this, and probably saves the user some trouble. Mostly untested. Closes #5272.
* player: match subtitles with language tags with --sub-auto=exactwm42017-11-271-18/+15
| | | | | | Apparently a relatively widespread convention, and almost as strict as the old "exact" semantics. (So it's not going to auto load radically unrelated files.)
* player: readd smi subtitle extensionwm42017-08-081-1/+1
| | | | | | | Fixes #4626. Previously removed because the original smi entry was added by someone who did not agree to LGPL relicensing. I'm not sure if the original change was copyrightable, but this commit for sure does not fall under that author's copyright.
* external_files: change license to LGPLwm42017-06-201-10/+10
| | | | | | | | | | | | | | | | | | | | | While we could easily ifdef-out this file for a LGPL core, it's still annoying, and also the only GPL file remaining in player/ that is not based on mplayer.c. This file originates from subreader.c. It's not clear whether the original author of it gave us permission to relicense to LGPL (he probably did, but without further clarification it's sort of ambiguous), but the subtitle file search code was written by other authors anyway (see 7eef93819f9d). One contribution (574eb892ea) is a bit of a corner case, as test_ext_list() now does a bstrcasecmp(). But I don't think the copyright remains here. (I asked the author anyway, just in case. But I didn't wait for the answer.) In some other cases, contributors who could not be reached added some subtitle extensions. I don't think those are copyrightable on their own, but I dropped them anyway just to be sure.
* external_files: parse ~ in --{sub,audio}-pathsrr-2017-05-311-3/+7
|
* external_files.c: add GPL headerwm42017-04-211-0/+17
| | | | | | It's been missing since mplayer2 times, not sure why. It originates from subreader.c. No analysis on whether it can be relicensed to LGPL was done yet.
* external_files: enable autoloading with URLsRicardo Constantino2017-04-011-3/+4
| | | | Closes #3264
* external_files: actually try to autoload from fallback pathsRicardo Constantino2017-04-011-2/+2
| | | | | | The 'sub' and 'audio' configuration subdirectories are supposed to be fallbacks for sub-paths and audio-file-paths respectively, but they weren't being scanned even if they existed.
* sub: remove .txt as text subtitle extensionwm42017-02-031-1/+1
| | | | | | | | | | | | | | | | If used with fuzzy matching, the player tends to pick up random text files, sometimes with interesting results. The most interesting interaction is when the user uses --log-file=something.txt, and mpv tries to open its own log file. It essentially "freezes" during probing, because every time it reads from it, it will write some more data, which in turn will cause more data to be read - until the 2MB max. probing size is slowly reached. This is not even an obscure corner case, but happened to multiple users. The .txt extension has been considered a subtitle extension ever since the code was added to MPlayer's subreader.c, but I'm not seeing many actual subtitle files with this extension, so just get rid of it.
* osx: consistent normalisation when searching for external filesAkemi2017-02-021-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | several unicode characters can be encoded in two different ways, either in a precomposed (NFC) or decomposed (NFD) representation. everywhere besides on macOS, specifically HFS+, precomposed strings are being used. furthermore on macOS we can get either precomposed or decomposed strings, for example when not HFS+ formatted volumes are used. that can be the case for network mounted devices (SMB, NFS) or optical/removable devices (UDF). this can lead to an inequality of actual equal strings, which can happen when comparing strings from different sources, like the command line or filesystem. this makes it mainly a problem on macOS systems. one case that can potential break is the sub-auto option. to prevent that we convert the search string as well as the string we search in to the same normalised representation, specifically we use the decomposed form which is used anywhere else. this could potentially be a problem on other platforms too, though the potential of occurring is very minor. for those platforms we don't convert anything and just fallback to the input. Fixes #4016
* player: add .scc subtitle extensionwm42017-01-311-1/+2
| | | | | | | | | Requested. Supposedly "scenarist closed captions". (The list of getting quite full. But it's probably still better than trying to probe the files by contents, because the external subtitle loader code will initially look at _all_ files in the same directory as the main file.)
* ta: remove old and redundant macrowm42016-05-171-1/+1
|
* player: add wv to list of external audio file extensionsMartin Herkt2016-03-261-0/+1
|
* player: fix previous commitwm42015-12-251-11/+17
| | | | | | | OK, this made the --sub-paths and --audio-file-paths synonyms, which is not what we wanted. Actually restrict the type of file loaded as well. Really fixes #2632.
* options: add --audio-file-pathswm42015-12-251-15/+22
| | | | | | | | Requested. It works like --sub-paths. This will also load audio files from a "audio" sub directory in the config file (because the same code as for subtitles is used, and it also had such a feature). Fixes #2632.
* external_files: deduplicate bstr functionsKevin Mitchell2015-11-091-20/+4
|
* player: add wav to list of external audio file extensionswm42015-10-041-1/+2
| | | | Fixes #2378.
* player: rename and move find_subfiles.cwm42015-09-201-0/+284
This was in sub/, because the code used to be specific to subtitles. It was extended to automatically load external audio files too, and moving the file and renaming it was long overdue.
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 04:32:09 +0000