summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* ytdl_hook: add length parameter to delay-loaded tracks only oncewm42020-02-211-3/+3
| | | | | This was done for each media type, so muxed tracks had it twice, which logged a dumb warning. Move it out of the per-media type loop.
* ytdl_hook: remove bitrate estimation from file sizewm42020-02-211-4/+0
| | | | | I think this is unnecessary, and at worst done by youtube-dl itself (didn't check).
* ytdl_hook: use tbr for all tracks if vbr/abr not availablewm42020-02-211-0/+9
| | | | | | | | | | | | | | | | | | vbr and abr are the video and audio bitrates. Sometimes there is a weird mix of any of them available, but in these cases, it's not good to fall back to tbr if a specific track has no vbr/abr. For example, the alphabetic site provides tbr only for the muxed fallback stream, but using tbr would make the primitive mpv hls_bitrate selection pick the compatibility stream for audio, because it appears to have a higher bitrate than the other audio-only streams (because the bitrate includes video). So we must not use tbr in this case. On the other hand, formats coming from youtube-dl HLS master playlist use will only have tbr set. So as a heuristic, use the tbr only if it's the only bitrate available in any track entry.
* ytdl_hook: replace skip_muxed with force_all_formats optionwm42020-02-211-26/+10
| | | | | | | | | | | | | I don't think the skip_muxed option was overlay useful. While it was nice to filter out the low quality muxed versions (as it happens on the alphabetic site, I suspect it's compatibility stuff), it's not really necessary, and just makes for another tricky and rarely used configuration option. (This was different before muxed tracks were also delay-loaded, and including the muxed versions slowed down loading.) Add the force_all_formats option instead, which handles the HLS case. Set it to true because they are also delay-loaded now, and don't slow down startup as much.
* ytdl_hook: delay-load interleaved fileswm42020-02-211-23/+36
| | | | | | (Or if it's about HLS, just "muxed"/multiplexed streams.) This only affects all_formats=yes,skip_muxed=no modes.
* ytdl_hook: signal duration in all_formats modewm42020-02-201-1/+6
| | | | | | If all streams were delay loaded, there was actually no duration present at all in the EDL metadata. So the length was considered unknown by the player frontend.
* ytdl_hook: attempt to filter out muxed streams if all_formats is usedwm42020-02-201-74/+147
| | | | | | | | | | | | | See manpage additions. We would have to extend delay_open to support multiple sub-tracks (for audio and video), and we'd still don't know (?) whether it might contain more than one stream each (thinking of HLS master streams). And if it's a true interleaved file (such as a "normal" mp4 file provided as fallback for more primitive players), we'd either have to signal such "bundled" tracks, or waste bandwidth. This restructures a lot. The if/else tree in add_single_video for format selection was a bit annoying, so it's split into separate if blocks, where it checks each time whether a URL was determined yet.
* ytdl_hook: remove forgotten debug messagewm42020-02-201-1/+0
| | | | It even has a typo.
* ytdl_hook: use bitrate fields for bitrate metadata instead of file sizeswm42020-02-201-1/+8
| | | | If available.
* ytdl_hook: try to skip interleaved streams with all_formatswm42020-02-201-2/+11
| | | | | | | | | | | | | | | | | If a "format" has both audio and video codec set, it might contain both audio and video. all_format assumes that each format is just a quality variant containing a single track. This seems to happen with sites that provide a HLS master URL. youtube-dl tends to "butcher" it, and the result isn't very ideal. I guess HLS "renditions" simply don't map well to youtube-dl's output format and what mpv expects. Playing master HLS directly is also less than ideal, because of libavformat's stupid probing. Fix this by not using the delay-opening mechanism if it appears like we detected such a case. Add a metadata override to set the track titles to "muxed-N", to indicate that they form a single unit. (Mostly helpful for testing.)
* ytdl_hook: iterate format list by array orderwm42020-02-201-1/+1
| | | | | Shouldn't have any consequences. Probably makes the user-visible order more stable.
* player: change bitrate in track listing back to kilobitswm42020-02-201-1/+1
| | | | Because the --hls-bitrate option takes the same unit.
* scripting: add a way to run sub processes as "scripts"wm42020-02-192-10/+80
| | | | | | | | | | This is just a more convenient way to start IPC client scripts per mpv instance. Does not work on Windows, although it could if the subprocess and IPC parts are implemented (and I guess .exe/.bat suffixes are required). Also untested whether it builds on Windows. A lot of other things are untested too, so don't complain.
* ytdl_hook: add all_formats optionwm42020-02-191-18/+85
| | | | | | | | | Pretty worthless I guess. I only tested one site (and 2 videos), it's somewhat likely that it will break with other sites. Even if you leave the option disabled (the default). Slightly related to #3548. This will allows you to use the bitrate stream selection mechanism, that was added for HLS, with normal videos.
* ytdl_hook: add a way to not pass --format to the command linewm42020-02-191-2/+5
| | | | Might be helpful for... whatever.
* player: print manifest per-stream bitrate information to terminalwm42020-02-191-0/+2
| | | | | Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the track title use this.
* audio: remove outdated commentwm42020-02-191-2/+0
| | | | | | Neither does it (directly) mess with filters, nor does it return a bool. As noticed by a comment in #6333.
* sub: make filter_sdh a "proper" filter, allow runtime changeswm42020-02-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, filter_sdh was simply a function that was called by sd_ass directly (if enabled). I want to add another filter, so it's time to turn this into a somewhat more general subtitle filtering infrastructure. I pondered whether to reuse the audio/video filtering stuff - but better not. Also, since subtitles are horrible and tend to refuse proper abstraction, it's still messed into sd_ass, instead of working on the dec_sub.c level. Actually mpv used to have subtitle "filters" and even made subtitle converters part of it, but it was fairly horrible, so don't do that again. In addition, make runtime changes possible. Since this was supposed to be a quick hack, I just decided to put all subtitle filter options into a separate option group (=> simpler change notification), to manually push the change through the playloop (like it was sort of before for OSD options), and to recreate the sub filter chain completely in every change. Should be good enough. One strangeness is that due to prefetching and such, most subtitle packets (or those some time ahead) are actually done filtering when we change, so the user still needs to manually seek to actually refresh everything. And since subtitle data is usually cached in ASS_Track (for other terrible but user-friendly reasons), we also must clear the subtitle data, but of course only on seek, since otherwise all subtitles would just disappear. What a fucking mess, but such is life. We could trigger a "refresh seek" to make this more automatic, but I don't feel like it currently. This is slightly inefficient (lots of allocations and copying), but I decided that it doesn't matter. Could matter slightly for crazy ASS subtitles that render with thousands of events. Not very well tested. Still seems to work, but I didn't have many test cases.
* ytdl_hook.lua: delay load subtitleswm42020-02-151-2/+12
| | | | | | | | | | | | | | | | Uses the infrastructure added in the previous commits. This is admittedly a bit weird (constructing EDL URLs and such). But on the other hand, adding this as "first class" mechanism directly to the sub-add command or so would increase weirdness and unexpected behavior in other places, or at least that's what I think. To reduce confusion, this goes through the effort of mapping the webvtt codec, so it's shown "properly" in the codec list. Without this it would show "null", but still work. In particular, any non-webvtt codecs should still work if libavcodec supports it. Not sure if I should remove the --all-subs hack from the code. But I guess it does no harm.
* audio: slightly simplify pull underrun message printingwm42020-02-131-1/+4
| | | | | | | | | | | | | | | A previous commit moved the underrun reporting to report_underruns(), and called it from get_space(). One reason was that I worried about printing a log message from a "realtime" callback, so I tried to move it out of the way. (Though there's little justification other than a bad feeling. While an older version of the pull code tried to avoid any mutexes at all in the callback to accommodate "requirements" from APIs like jackaudio, we gave up on that. Nobody has complained yet.) Simplify this and move underrun reporting back to the callback. But instead of printing the message from there, move the message into the playloop. Change the message slightly, because ao->log is inaccessible, and without the log prefix (e.g. "[ao/alsa]"), some context is missing.
* player: consider audio buffer if AO driver does not report underrunswm42020-02-131-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AOs can report audio underruns, but only ao_alsa and ao_sdl (???) currently do so. If the AO was marked as not reporting it, the cache state was used to determine whether playback was interrupted due to slow input. This caused problems in some cases, such as video with very low video frame rate: when a new frame is displayed, a new frame has to be decoded, and since there it's so much further into the file (long frame durations), the cache gets into an underrun state for a short moment, even though both audio and video are playing fine. Enlarging the audio buffer didn't help. Fix this by making all AOs report underruns. If the AO driver does not report underruns, fall back to using the buffer state. pull.c behavior is slightly changed. Pull AOs are normally intended to be used by pseudo-realtime audio APIs that fetch an audio buffer from the API user via callback. I think it makes no sense to consider a buffer underflow not an underrun in any situation, since we return silence to the reader. (OK, maybe the reader could check the return value? But let's not go there as long as there's no implementation.) Remove the flag from ao_sdl.c, since it just worked via the generic mechanism. Make the redundant underrun message verbose only. push.c seems to log a redundant underflow message when resuming (because somehow ao_play_data() is called when there's still no new data in the buffer). But since ao_alsa does its own underrun reporting, and I only use ao_alsa, I don't really care. Also in all my tests, there seemed to be a rather high delay until the underflow was logged (with audio only). I have no idea why this happened and didn't try to debug this, but there's probably something wrong somewhere. This commit may cause random regressions. See: #7440
* player: add ab-loop-count option/propertywm42020-02-083-1/+9
| | | | | | | | | | | | As requested I guess. It behaves quite similar to the --loop* options. Not quite happy with the idea that 1) the option is mutated on each operation (but at least it's consistent with --loop* and doesn't require more properties), and 2) the ab-loop command will do nothing once all loop iterations are done. As a concession, the OSD shows something about "disabled". Fixes: #7360
* js: require: directory-scripts: first look at <dir>/modules/Avi Halachmi (:avih)2020-02-072-0/+10
| | | | | Also, add the function mp.get_script_directory() to let scripts know if they're loaded as a directory and where.
* js: require: don't use ~~/scripts/modules.js/Avi Halachmi (:avih)2020-02-071-1/+6
| | | | | | | | | Directories inside ~~/scripts/ are now loaded as scripts, so don't use it also for modules. Now there are no default module paths. To compensate, we now try to run ~~/.init.js right after defaults.js, so the user may extend the js init procedure via this script, e.g. for adding default paths to mp.module_paths .
* osc: use cache state cache-duration fieldwm42020-02-071-1/+1
| | | | Avoids an additional property access; see previous commit.
* command: add cache-duration to cache state propertywm42020-02-071-0/+3
| | | | Convenience; see following commit.
* console: fix typo in previous commitwm42020-02-071-1/+1
| | | | Now keypad enter actually works.
* console: manually map numeric keypad (KP*) bindingswm42020-02-071-0/+7
| | | | | | | | | | | | | | | While mpv normally uses the text a key produces (as opposed to physical key mappings), this is different with the keypad. This is for the sake of making it possible to distinguish between these keys and the normal number keys on the left side of a full size keyboard. There were complaints that the keypad doesn't interact with console.lua, so manually map them. This ignores numlock (behaves as if it's always on), and maps KP_DEC to "." (even though it's mapped to "," on some keyboards). The /*-+ keys produce ASCII on mpv (at least with X11) as an inexplicable inconsistency, so there are no mappings for these. Fixes: #7431
* screenshot: fix typo in commentwm42020-02-071-1/+1
| | | | | It was not meant to imply that screenshots are male. Female (and other) screenshots are also welcome to this project.
* player: make screenshot each-frame mode more accuratewm42020-02-074-5/+11
| | | | | | | | | | | | | | | | | | | | | | | Due to asynchronicity, we generally can't guarantee that a video frame matches up with other events such as playback time change exactly (since decoding, presentation, and property update all happen at different times). This is a complaint in the referenced bug report, where screenshot filenames in each-frame screenshot did not use the correct timestamp, and instead was lagging behind by 1 frame. But in this case, synchronicity was already pretty much forced with wait calls. The only problem was that the playback time was updated at a later time, which results in the observed 1 frame lag. Fix this by moving the place where the screenshot is triggered in this mode. Normal screenshots may still have the old problem. There is no effort made to guarantee the timestamps absolutely line up, same as with the OSD. (If you want a guarantee, you need to use a video filter, such as libavfilter's drawtext. These will obviously use the proper timestamp, instead of going through the somewhat asynchronous property etc. system in the player frontend.) Fixes: #7433
* lua: fix typo in commentwm42020-02-061-1/+1
|
* options.lua: avoid unnecessary on_update callsOscar Manglaras2020-02-061-1/+1
| | | | | | | The script was set up to only call on_update when the changelist was non-empty. However, since the size operator does not operate on dicts, it always returned 0 (which is truthy), thus on_update would always be called when the script-opts property changed.
* stats: fix incorrect ass formatting on 3rd page when vo was switchedsfan52020-02-061-0/+1
| | | | | | When switching between having a video visible or not, stats.lua now picks up the required formatting changes for the cache stats page to display correctly.
* scripting: give proper name to scripts using a directorywm42020-02-061-2/+8
| | | | | | | | | | | | | | | | | The recently added feature to load scripts from a sub-directory. A problem was that the script name was still derived from the actual script source file that was loaded, which was always "main.lua" (or similar), resulting in "main" as name. Fix this by using the directory name. One odd corner case is that you can do "--script=/path/foo////". As by POSIX semantics, the extra "/" are ignored. However, the newly added code strips only one separator, so mp_basename() returns "" (as it should), and the empty name makes mp_new_client() fail in turn. I don't really care about this, just don't do it. But mp_new_client() failure was silent (since it normally never happens), so add at least an error message for that, instead of being entirely silent.
* lua: use mp_path_is_absolute() for checking package pathswm42020-02-061-1/+1
| | | | | This makes it work with the shitty OS. Behavior on Linux should be the same.
* lua: fix highly security relevant arbitrary code execution bugwm42020-02-061-14/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears Lua's package paths try to load .lua files from the current working directory. Not only that, but also shared libraries. WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING? mpv isn't setting this package path; currently it's only extending it. In any sane world, this wouldn't be a default. Most programs use essentially random working directories and don't change it. I cannot comprehend what bullshit about "convenience" or whatever made them do something this broken and dangerous. Thousands of programs using Lua out there will try to randomly load random code from random directories. In mpv's case, this is so security relevant, because mpv is normally used from the command line, and you will most likely actually change into your media directory or whatever with the shell, and play a file from there. No, you don't want to load a (probably downloaded) shared library from this directory if a script try to load a system lib with the same name or so. I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the Debian version) put "./?.lua" at the end, but in any case, trying to load a module that doesn't exist nicely lists all package paths in order, and confirms it tries to load files from the working directory first (anyone can try this). Even if it didn't, this would be problematic at best. Note that scripts are _not_ sandboxed. They're allowed to load system libraries, which is also why we want to keep the non-idiotic parts of the package paths. Attempt to fix this by filtering out relative paths. This is a bit fragile and not very great for something security related, but probably the best we can do without having to make assumptions about the target system file system layout. Also, someone else can fix this for Windows. Also replace ":" with ";" (for the extra path). On a side note, this extra path addition is just in this function out of laziness, since I'd rather not have 2 functions with edit the package path. mpv in default configuration (i.e. no external scripts) is probably not affected. All builtin scripts only "require" preloaded modules, which, in a stroke of genius by the Lua developers, are highest priority in the load order. Otherwise, enjoy your semi-remote code execution bug. Completely unrelated this, I'm open for scripting languages and especially implementations which are all around better than Lua, and are suited for low footprint embedding.
* lua: add mp.get_script_directory() functionwm42020-02-041-0/+11
| | | | And add some clarifications/suggestions to the manpage.
* player: partially fix backward playback display of cached text subtitleswm42020-02-042-5/+4
| | | | | | | | | | | | | | This simply didn't set the direction flag in most situations, which meant the timestamps used in the subtitle renderer were nonsense, leading to invisible subtitles. This works only for text subtitles that are cached in the ASS_Track state. Reading new subtitles is broken because the demuxer layer has trouble returning subtitle packets backwards, and I think for rendering bitmap subtitles, the pruning direction would have to be adjusted. (Not sure if reversing the timestamps before the subtitle renderer backend is even the right thing to do. At least for sd_ass.c, it seems to make sense, because it caches subtitles with "normal" timestamps.)
* lua: set package path if loaded from a script directorywm42020-02-011-0/+29
| | | | | | And document the shit. This uses code from commit bc1c024ae032e5b5c.
* scripting: load scripts from directorieswm42020-02-016-52/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | The intention is to provide a slightly nicer way to distribute scripts. For example, you could put multiple source files into the directory, and then import them from the actual script file (this is still unimplemented). At first I wanted to require a config file (because you need to know at least which scripting backend it should use). This wouldn't have been too hard (could have reused/abused the mpv config file parsing mechanism, and I already had working code that was just 2 function calls). But probably better to do this without new config files, because it might become a pain in the distant future. So this just probes for "main.lua", "main.js", etc., until an existing file is found. Another important change is that this skips all directory entries whose name starts with ".". This automatically excludes the "." and ".." special directories, and is probably useful to exclude random crap that might be lying around in the directory (such as editor temporary files, or OSX, in its usual hrmful, annoying, and idiotic modus operandi, sharting all over any directories opened by "Finder"). Although the changelog mentions the docs, they're added only in a later commit.
* lua: stop setting bogus package pathwm42020-01-261-25/+0
| | | | | Scripts are not supposed to be able to "import" anything from mpv's scripts directory, because all these files are loaded by mpv itself.
* player: fix minor coding style issuewm42020-01-261-1/+2
|
* player: check if file is URL before attempting to get mtimeChris Down2020-01-261-2/+5
| | | | | | I noticed an oversight when using ytdl-hook -- if the path is a URL, we try to `stat()` it, which obviously doesn't work. To mitigate that, don't check or update mtimes for URLs.
* cocoa-cb: add support for forcing the dedicated GPU for renderingder richter2020-01-261-1/+1
| | | | | | | | this deprecates the old cocoa backend only option and moves it to the general macos ones. add support for the new option in the cocoa-cb layer creation and use the new option in the olde cocoa backend. Fixes #7272
* player: make failure to load scripts non-fatal againwm42020-01-201-2/+1
| | | | | Restore the behavior from a few commits ago. I decided that it's strange that this is fatal, since e.g. config file errors are also non-fatal.
* scripting: make player error when attempting to load unknown scriptswm42020-01-193-7/+15
| | | | | | It's ridiculous that --script=something.dumb does not cause an error. Make it error, and extend this behavior to the scripts/ sub-dir in the mpv config dir.
* player: write watch-later config even for unseekable streamswm42020-01-171-5/+7
| | | | | | | | | | | | I think there was a user complaint that this does not restore the playlist position. There's no reason not to save the "state" for unseekable streams; what we probably don't want is to make restoring trying to issue a seek. So just don't save the position. (Although we probably could anyway, since seek requests on unseekable streams are ignored now.) Fixes: issue number forgotten, if it even exists.
* osc: more frequent cache updates: from 10% diff to 5% or 5sAvi Halachmi (:avih)2020-01-141-2/+2
| | | | | | | | Cache display updates, especially when it's bigger than few minute, could have been be very infrequent to the point that one is not sure if it updates at all. Reduce the 10% change-threshold to 5% and add another threshold of 5s.
* osc: usability improvements for pseudo-csd title barPhilip Langdale2020-01-131-4/+21
| | | | | | | | | | | | | | | | | | | There are two improvements here: 1) Correct the right-side padding on the title box. This was messed up previously because I was passing the title box width when I should be passing the x coordinate. I've also increased the spacing to separate the title from the window controls more clearly. 2) I'ved added a mouse tracking area over the title bar so that the osc doesn't disappear if you hover over the title box. This didn't work previously because the input are