summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* f_decoder_wrapper, sd_add: accept "null" codecwm42020-02-152-2/+12
| | | | | | | | | | | | | This is for easier use with the "delay_open" feature added in the previous commit. The "null" codec is reported if the codec is unknown (because the stream was not opened yet at time the tracks were added). The rest of the timeline mechanism will set the correct codec at runtime. But this means every time a delay-loaded track is selected, it wants to initialize a decoder for the "null" codec. Accept a "null" decoder. But since FFmpeg has no such codec, and out of my own laziness, just let it fall back to "common" codecs that need no other initialization data.
* edl: add mechanism for delay loading streamswm42020-02-155-33/+219
| | | | | | | | | | | | | Add something that will access an URL embedded in EDL only when the track it corresponds to is actually selected. This is meant to help with ytdl_hook.lua and to improve loading speeds. In theory, all this stuff is available to any mpv user, but discourage using it, as it's so specialized towards ytdl_hook.lua, that there's danger we'll just break this once ytdl_hook.lua stops using it, or similar. Mostly untested.
* demux_edl: warn if no_clip is used with multiple partswm42020-02-152-1/+5
| | | | Well whatever.
* demux_edl: allow a redundant new_stream at the beginningwm42020-02-152-1/+16
| | | | | | | Normally, the first sub-stream is implicitly created. This change lets the user use more orthogonal syntax, and use a new_stream header for every sub-stream, instead of having to skip the header for the first one.
* demux_edl: accept protocol entries in EDL entries againwm42020-02-151-1/+4
| | | | | | Accidentally broken by commit 99700bc52c1317. mp_path_join() does not check for this, because it's supposed to work on filesystem strings (and e.g. "http://fubar" is a valid relative path in UNIX).
* demux_edl: improve parsing slightlywm42020-02-152-46/+101
| | | | | | | | | | | Add a mp_log context to the parse_edl() function, and report some errors. Previously, this just told you that something was wrong. Add some error reporting to make it slightly less evil. Put all parameters in a list before processing them. This makes adding parameters for special headers easier, and we can report parameters that were not understood. (For "compatibility", which probably doesn't matter at all, still don't count them as errors; as before.)
* demux_timeline: fix another cursed memory management issuewm42020-02-151-3/+7
| | | | | | | | | | | | | The timeline stuff has messed up memory management because there are no clear ownership rules between a some demuxer instances (master or demux_timeline) and the timeline object itself. This is another subtle problem that happened: apparently, demux_timeline.open is supposed to take over ownership of timeline, but only on success. If it fails, it's not supposed to free it. It didn't follow this, which lead to a double-free if demux_timeline.open failed. The failure path in demux.c calls both timeline_destroy() and demux_timeline.close on failure.
* demux_timeline: fix a commentwm42020-02-151-2/+2
|
* demux_timeline: reorder some functionswm42020-02-151-157/+153
| | | | | | Move them around in the source code to get rid of the forward declarations. Other than rearranging the lines and removing the 2 forward declarations, there are no other changes at all.
* 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 commentwm4