summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* some shitytdl_sub_delayloadwm42020-02-157-35/+194
|
* msg: slightly improve --msg-time outputwm42020-02-142-2/+5
| | | | Cut the arbitrary offset, and document what unit/timesource it uses.
* stream: early-out in stream_seek_skip() if nothing is skippedwm42020-02-141-2/+7
| | | | | | | stream_seek() might somewhat show up in the profiler, even if it's a no-OP, because of the MP_TRACE() call. I find this annoying. Otherwise, this should be of no consequence, and should not break or improve anything.
* stream_file: cache file sizewm42020-02-141-4/+11
| | | | | | | | | | | | | | | | | | | | | Some cache logic in demux.c queries the raw byte stream size on every packet read. This is because it reports the value to the user. (It has to be polled like this because there is no change notification in most underlying I/O APIs, and also the user can't just block on the demuxer thread to update it explicitly.) This causes a very high number of get_size calls with low packet sizes, so cache the size, and update it on every read. Reads only happen approximately all 64KB read with default settings, which is way less frequent than every packet in such extreme cases. In theory, this could in theory cause problems in some cases. Actually this is whole commit complete non-sense, because why micro-optimize for broken cases like patent troll codecs. I don't need to justify it anyway. As a minor detail, off_t is actually specified as signed, so the off_t cast is never needed.
* manpage: clarify --player-operation-modewm42020-02-142-6/+13
| | | | | | | options.rst to clarify the option, some more text in mpv.rst to separate out the compatibility stuff a little. Fixes: #7461 (options.rst change only)
* wayland: make resizing betterDudemanguy2020-02-132-6/+32
| | | | | | | | | Resizing the window while preserving the aspect ratio actually kind of sucked. The window size could make big dramatic changes which was pretty unintuitive with respect to where the mouse was actually located. Instead, let's just do some math to ensure that the window size is always contained inside the width/height reported by handle_toplevel_config while preserving the aspect ratio. Fixes #7426.
* audio: slightly simplify pull underrun message printingwm42020-02-133-20/+11
| | | | | | | | | | | | | | | 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.
* wayland: fix autofit and rotating issuesDudemanguy2020-02-131-5/+7
| | | | | | Fixes #7441. Just set screenrc to be equal to current_output's geometry. Also remove some pointless/extra variables and print a warning/fallback to screen 0 if a bad id is passed to --fs-screen.
* player: consider audio buffer if AO driver does not report underrunswm42020-02-138-23/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ao: avoid unnecessary wakeupswm42020-02-133-9/+14
| | | | | | | | | | | | | If ao_add_events() is used, but all events flags are already set, then we don't need to wakeup the core again. Also, make the underrun message "exact" by avoiding the race condition mentioned in the comment. Avoiding redundant wakeups is not really worth the trouble, and it's actually just a bonus in the change making the ao_underrun_event() function return whether a new underrun was set, which is needed by the following commit.
* zimg: fix previous odd sizes commitwm42020-02-131-4/+2
| | | | | | | | | Obviously, we don't want to lose fractions, and the zimg active_region fields in fact have the type double. The integer division was wrong. Also, always set active_region.width/height. It appears zimg behavior does not change if they're set to the normal integer values, so the extra check to not set them in this case was worthless.
* manpage: fix typo on sub-endwm42020-02-121-1/+1
| | | | Fixes: #7455
* sws_utils: use zimg by default if availablewm42020-02-123-7/+6
| | | | | This seems stable enough to use. Change the default, and remove it from the sw-fast profile.
* zimg: correct output to odd (chroma un-aligned) sizeswm42020-02-121-10/+18
| | | | | | | | | | As suggested by the zimg author: active_region is not supported on outputs (and the API returns an error), so instead scale to the "full" surface, but adjust the source rectangle such that the cropped output image happens to cover the correct region. Does this even work? Since Balmer Peak doesn't work, I can't really say, but it seems to look correct.
* zimg: fix typos in a commentwm42020-02-121-3/+2
| | | | | | Also remove the "o" case, which was never implemented (probably was an idea to output alpha formats, now obsoleted by zimg's full alpha support).
* vo_drm, wo_wlshm: mention that it's software scalingwm42020-02-112-2/+2
| | | | (But does anyone even read --vo=help output?)
* vo_x11: don't call X11 "crap"wm42020-02-111-1/+1
| | | | | | X11 is in fact beautiful and superior to Wayland. Instead, just state what the problem is in most cases: software scaling. (We have accelerated X11 rendering in vo_gpu and others.)
* zimg: add pal8 unpackerwm42020-02-101-0/+39
| | | | Some pngs are paletted, so this is vaguely interesting.
* img_format: add alias for ffmpeg pal8 formatwm42020-02-102-0/+4
| | | | For the next commit.
* manpage: add some blabla about zimg speed vs. libswscalewm42020-02-101-1/+10
| | | | | Of course nobody will read this. I'm just putting it there so I can blame users, who run into problems, for not having read it.
* zimg: rename zplanes fieldwm42020-02-101-4/+4
| | | | | | | | | This was a confusing name, because 1. there's also a z_planes[] field, and 2. it was not specific to zimg indexes. Possibly there used to be an idea involved about supporting alpha to non-alpha formats by discarding the alpha plane, but zimg does this now (and zimg will correctly blend the alpha component too).
* zimg: support gray/alpha conversionwm42020-02-101-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | The special thing about this format is 1. mpv assigns the component ID 4 to alpha, and component IDs 2 and 3 are not present, which causes some messy details. 2. zimg always wants the alpha plane as plane 3, and plane 1 and 2 are not present, while FFmpeg/mpv put the alpha plane as plane 1. In theory, 2. could be avoided, since FFmpeg actually doesn't have a any 2 plane formats (alpha is either packed, or plane 3). But having to skip "empty" planes would break expectations. zplanes is not equivalent to the mpv plane count (actually it was always used this way), while zimg does not really have a plane count, but does, in this case, only use plane 0 and 3, while 2 and 3 are unused and unset. z_planes[] (not zplanes) is now always valid for all 4 array entries (because it uses zimg indexes), but a -1 entry means it's an unused plane. I wonder if these conventions taken by mpv/zimg are not just causing extra work. Maybe component IDs should just be indexes by the "natural" order (e.g. R-G-B-A, Y-U-V-A, Y-A), and alpha should be represented as a field that specifies the component ID for it, or just strictly assume that 2/4 component formats always use the last component for alpha.
* zimg: fix some confusion about plane permutationwm42020-02-101-4/+9
| | | | | | | | | | | | | We reorder the planes between mpv and zimg conventions. It turns out the code still confused when which convention was used. So the way it actually works is that the _only_ place where zimg order is used is the zimg_image_buffer.plane[] array. plane_aligned[] and zmask[] were accessed incorrectly, although I guess it rarely had a reason to fail (plane reordering is mostly for RGB, which has planes of all the same size). Adjust some comments accordingly too.
* img_format: add gray/alpha planar formatswm42020-02-103-2/+88
| | | | | | | | | | | | The zimg wrapper "needs" these formats as intermediary when repacking the normal gray/alpha packed format. The packed format is used by the png decoder and encoder, and is thus interesting. Unfortunately, mpv-only formats are a mess right now, because all the existing code is focused around using the FFmpeg metadata for pixel formats. This should be improved, but not now, so make the mess worse. This commit doesn't add support for it to the zimg wrapper yet.
* zimg: add alpha supportwm42020-02-092-18/+69
| | | | | | | | | | | libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
* vo: fix typo in commentwm42020-02-091-1/+1
|
* vf_format: add w, h parameterswm42020-02-092-3/+15
| | | | Yes, this thing became vf_scale through the back door.
* sub: enhance SDH filteringDan Oscarsson2020-02-091-0/+8
| | | | | It is not uncommon with a speaker label with [xxxx] inside. They should also be filtered out.
* github: fix a typo in the contact links infoder richter2020-02-091-2/+2
|
* github: ask users to first reproduce the issue with --no-configder richter2020-02-094-0/+12
|
* mac: always include the macOS config when cocoa is availableder richter2020-02-091-1/+1
| | | | | | | | | | the macOS config was only used in cocoa-cb before and only included when it was available. since this config is meant for general macOS options and backend independent options we include it when cocoa is available. one of the options is already used in the old cocoa backend, which broke using it when build without swift or cocoa-cb support. Fixes #7449
* bash completion: complete ao/af/vo/vf optionsPhilip Langdale2020-02-081-1/+1
| | | | | I didn't handle these originally, but it turns out that they can be handled with the samel logic as Choice options.
* bash completion: Cache the options listPhilip Langdale2020-02-081-8/+11
| | | | | | The bash completion seems to be working decently at this point, so I feel comfortable caching the options output to improve the performance of the completion.
* sub: fix SDH filtering after changeDan Oscarsson2020-02-081-1/+1
| | | | | | | | The change, in an earlier commit, in format for ass to handle results in a different number of fields to skip. Correct that so SDH filtering works. Should fix issue #7188
* player: add ab-loop-count option/propertywm42020-02-086-1/+21
| | | | | | | | | | | | 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
* DOCS/interface-changes.rst: mention it's for incompatible changeswm42020-02-081-1/+3
| | | | | | This is not really a changelog, but rather a list of potentially breaking changes API- and normal users should be aware of, and to help with migration from older mpv releases.
* DOCS/interface-changes.rst: mention OSX bundle loggingwm42020-02-081-0/+1
|
* cocoa-cb: fix auto-selection of title bar style with older SDKsder richter2020-02-081-0/+4
| | | | | returning a nil value only works when build with a +10.14 SDK otherwise we need to fallback to the old mechanism.
* cocoa-cb: simplify cursor hiding and make it less greedyder richter2020-02-083-12/+7
| | | | | | | | | | | | | | | | | | for reasons unknown to me the NSCursor (un)hide functions can be completely unreliable and the cursor can have an unknown state. this only happens on some system and wasn't able to reproduce this. it's probably some dumb race condition that might be possible to work around, though because of the lack of reproducibility on my end it's hard to test. i decided to rework the cursor hiding code yet again and make it a lot less greedy. the cursor will now always unhide when moved and there will never be a situation again the cursor can't be unhidden again. on the other hand there might be edge cases now where the cursor won't hide immediately and you have to move it slightly to make it disappear again. this should be an acceptable tradeoff. Fixes #6886
* mac: activate logging when started from the bundleder richter2020-02-084-7/+50
| | | | | | | | | | this creates a default log for the last mpv run when started from the bundle. that way one can get a log of what happened even after an issue occurred. also add a menu entry under Help to show the current log, but only when the bundle is used. Fixes #7396 Fixes #2547
* mac: remove stdout and stderr redirect for loggingder richter2020-02-081-11/+0
| | | | | | | this was kinda useless anyway since the bundle was started with terminal=no and no logging was done anyway. Fixes #1590
* wayland: adjust vo_wayland_wait_frame logicDudemanguy2020-02-071-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Wayland uses vo_wayland_wait_frame plus some polling with a timeout for blocking on vsync. Here are a couple of changes that seem to be improvements. First, the poll time is always rounded up instead of truncated. When rendering frames longer than the standard 16.666 ms timeout, it seems that truncating the poll time slightly early may cause some vsync jitter spikes. Waiting longer, even if it's too long, appears to behave better. The second change is to use wl_display_roundtrip instead of wl_display_dispatch_pending. wl_display_dispatch_pending dispatches all events immediately. This is good to avoid blocking, but it's not guaranteed to wait long enough for all events to be processed on the display fd. The preceding wl_display_read_events routine ensures that all events on the display fd are queued. We just need a semi-blocking routine to dispatch them for the most reliable vsync. wl_display_roundtrip will dispatch any events for us, but also wait for a reply from the display server. This makes it ideal for this role. If the compositor doesn't reply to the client something else is probably horribly broken and wrong anyway. It's also not a permanently blocking call like wl_display_dispatch. If there's no frame callback (i.e. the window is hidden), then it does not dispatch any events and returns immediately.
* DOCS: js: minor update for requireAvi Halachmi (:avih)2020-02-071-5/+5
|
* js: require: directory-scripts: first look at <dir>/modules/Avi Halachmi (:avih)2020-02-074-1/+16
| | | | | 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-072-12/+26
| | | | | | | | | 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-072-0/+6
| | | | Convenience; see following commit.
* demux: add option to disable "sharing" between back and forward bufferswm42020-02-072-2/+18
| | | | | | | As requested. I guess option name and manpage text could be better and clearer. Closes: #7442
* 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
* options: disable vsfilter blur compat by defaultwm42020-02-072-2/+2
| | | | | | | | | | | | | | | | | | | See #7435 and related for context. Basically, it seems that while the original vsfilter processed subtitles like with this option set to "yes", many current players (mpc-hc default, vlc, probably most libass users) treat them like with "no". In the linked issue, this makes rendering severely slower, and can consume a lot of memory (or just overflow libass memory calculations). It seems that changing this to "no" will lead to more good than bad, especially because newer subtitles may be authored for the "no" behavior. Most libass users seem to use "no" exactly because they do not call ass_set_storage_size() at all. This API was needed because the scaling of the subtitles depends on the video size (vsfilter bugs, or something). In addition, it's my personal opinion that rendering should not depend on the video at all, so I like setting the default of this to "no".
* 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/