summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* player: reorder list of external cover files for optimal resultsHEADmastersfan521 hours1-7/+9
|
* build: disable wayland if linux/input-event-codes.h isn’t availableEmmanuel Gil Peyrot29 hours1-1/+5
| | | | | | | | | | | | | The wl_pointer interface defines button argument as “a button code as defined in the Linux kernel's linux/input-event-codes.h header file, e.g. BTN_LEFT.” We could #define these few buttons ourselves, but there is no system to test it on, so for now let’s disable Wayland support on them. This is a call to non-Linux system maintainers, please help test this backend on your system and report issues you find, or even working state.
* wayland: use more specific input codes headerEmmanuel Gil Peyrot29 hours1-1/+1
| | | | | | Wayland’s wl_pointer interface describes the button event’s argument as being taken from linux/input-event-codes.h, so there is no need to include the more generic linux/input.h.
* demux_lavf: initialize ReplayGain dataMia Herkt3 days1-0/+2
| | | | | | | This was causing undefined behavior when playing streams without RG tags but with RG enabled. Broken in 585f9ff42f3195c. Thanks to uau for bisecting.
* command: add delete-watch-later-configVladimir Panteleev4 days5-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the delete-watch-later-config command, to complement write-watch-later-config. This is an alternative to #8141. The general problem that this change is attempting to help solve has been described in #336, #3169 and #6574. Though persistent playback position of a single file is generally a solved problem, this is not the case for playlists, as described in #8138. The motivation is facilitating intermittent playback of very large playlists, consisting of hundreds of entries each many hours long. Though the current "watch later" mechanism works well - provided that the files each occur only once in that playlist, and are played only via that playlist - the biggest issue is that the position is lost completely should mpv exit uncleanly (e.g. due to a power failure). Existing workarounds (in the form of Lua scripts which call write-watch-later-config periodically) fail in the playlist case, due to the mechanism used by mpv to determine where within a playlist to resume playback from. The missing puzzle piece needed to allow scripts to implement a complete solution to this problem is simply a way to clean up the watch-later configuration that the script asked mpv to write using write-watch-later-config. With that in place, scripts can then register an end-file event listener, check the stop playback reason, and in the "eof" and "stop" case, invoke delete-watch-later-config to delete any saved positions written by write-watch-later-config. The script can then proceed to immediately write a new one when the next file is loaded, which altogether allows mpv to resume from the correct playlist and file position upon next startup. Because events are delivered and executed asynchronously, delete-watch-later-config takes an optional filename argument, to allow scripts to clear watch-later configuration for files after mpv had already moved on from playing them and proceeded to another file. A Lua script which makes use of this change can be found here: https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef (A modification of the one written by @Hakkin, in that this one takes advantage of the new command, and also saves the state immediately when a new file is loaded.)
* vo_gpu: improve gamut warning bounds checksNiklas Haas5 days1-2/+2
| | | | | | | Test for signals exceeding 0.5% of the permitted gamut, in either direction. (Before, it was 1% above and 0% below) Should fix https://github.com/mpv-player/mpv/issues/8161
* wayland: don't use presentation time if ust is 0Dudemanguy7 days1-3/+4
| | | | | | | | Testing kwinft out (kwin fork), it was discovered that sometimes it would return a ust value of 0 which subsequently resulted in incorrect presentation statistics (i.e. large negative numbers which are obviously impossible). Arguably, it shouldn't return 0s, but a workaround for mpv in this case is harmless.
* stats: display hw pixel format toosfan510 days1-0/+4
|
* command: expose underlying pixfmt for hwdecsfan510 days2-0/+7
|
* ci/appveyor: attempt to work around outdated msys2Jan Ekström10 days1-0/+8
| | | | | | | | Based on the workarounds utilized in the MAME project: 1. mamedev/mame@4b4016110a71a5b84b9d19faf20238d20926088d 2. mamedev/mame@2d1bf3ed5cb1f4cdcc40b286a78c24f398217535 Co-authored-by: James Ross-Gowan <rossy@jrg.systems>
* ci/travis: stop installing mingw-w64 packages manuallyJan Ekström11 days1-4/+0
| | | | | | As we are now on 20.04, these packages are now available in the repositories. Additionally, they don't need to be separately pulled in, as gcc-mingw-w64 already does that.
* ci/travis: move to a yaml list for required packages for mingw-w64Jan Ekström11 days1-2/+8
|
* ci/travis: bump Ubuntu distro version to focal (20.04)Jan Ekström11 days1-1/+1
|
* manpage: Document behaviour of *nix configuration directoriesPhilip Langdale11 days1-6/+22
| | | | | | | The original documentation here is unclear, so let's describe the behaviour we actually have. Inspired by wm4's updated docs but obviously not identical because we're not changing any of the behaviours.
* Revert "path: switch back to using non-XDG config dir by default"Philip Langdale11 days2-48/+30
| | | | This reverts commit 269f0e743e5634691f0c9d5b1b8a4bb68eedbbd0.
* Revert "path: do not use old_home for win32 exe dir"Philip Langdale11 days3-4/+1
| | | | This reverts commit c3694f0acb7f71daac7606fafbadcb7b500ca35e.
* Revert "manpage: reference standard for configuration file location"Philip Langdale11 days1-5/+0
| | | | This reverts commit 67b4a96e4592a6bf95a86ebcc8f6c5e951fe327d.
* build: bump waf to 2.0.20Jan Ekström11 days1-2/+2
| | | | | | There have been mentions that there are apparently some bugs with regards to possible random build failures, so bumping after a few years sounds like an OK thing to test/do.
* stream_lavf: enable SRT protocol support through FFmpegAlexandre Iooss11 days3-2/+3
| | | | | Additionally, announce support for the protocol in Mac and Linux application metadata.
* vo_gpu: fix segfault when updating render optsDudemanguy11 days1-1/+2
| | | | | | VOCTRL_UPDATE_RENDER_OPTS is supposed to be optional so check if it actually exists before executing the function. Fixes a segfault when changing the alpha value at runtime on non-wayland platforms.
* vo_gpu: EGL: hack for alpha on different platformsDudemanguy11 days2-1/+4
| | | | | | | | | | | 7fb972f fixed transparency on x11/EGL/Mesa but happened to also break it for wayland and nvidia. Ideally on wayland, you should just be able to pick the right EGLConfig that has alpha but this doesn't seem to work because reasons. So just go back to setting the EGL_ALPHA_SIZE bit if the user asks for alpha. Apparently this worked before for nvidia as well. The hack is to just run an eglQueryString in the x11egl context. If it picks up Mesa as the EGL_VENDOR, then force ctx->opts.want_alpha to 0 and let pick_xrgba_config take care of the rest.
* wayland: update opaque region on runtimeDudemanguy11 days5-39/+54
| | | | | | | | | | Made possible with 00b9c81. 34b8adc let the wayland surface set an opaque region depending on if alpha was set by the user or not. However, there was no attempted detection for runtime changes and it is possible (at least in wayland vulkan) to toggle the alpha on and off. So this meant, we could be incorrectly signalling an opaque region if the user happened to change the alpha. Additionally, add a helper function for this and use it everywhere we want to set the opaque region.
* vo_gpu: update render options on runtimeDudemanguy11 days2-4/+14
| | | | | | | | | | | | vo_gpu has a small set of options for ra_ctx that can be set. In practice, runtime toggling doesn't matter for most of these as they have no effect while a video is playing. However, changing the alpha option during runtime can actually work depending on the backend used. mpv already detected when one of these options changed, but it made no attempt to update the options in the ra_ctx accordingly (likely because nothing made any use of this information). Another related change is to add an update_render_opts to the fns and allow invidiual backends to (optionally) use it.
* wayland: be less strict about when to renderDudemanguy11 days5-3/+16
| | | | | | | | | | | | | | | | | | | | | efb0c5c changed the rendering logic of mpv on wayland and made it skip rendering when it did not receive frame callback in time. The idea was to skip rendering when the surface was hidden and be less wasteful. This unfortunately had issues in certain instances where a frame callback could be missed (but the window was still in view) due to imprecise rendering (like the default audio video-sync mode). This would lead to the video appearing to stutter since mpv would skip rendering in those cases. To account for this case, simply re-add an old heuristic for detecting if a window is hidden or not since the goal is to simply not render when a window is hidden. If the wait on the frame callback times out enough times in a row, then we consider the window hidden and thus begin to skip rendering then. The actual threshold to consider a surface as hidden is completely arbitrary (greater than your monitor's refresh rate), but it's safe enough since realistically you're not going to miss 60+ frame callbacks in a row unless the surface actually is hidden. Fixes #8169.
* wscript_build.py: use -Wl,--subsystem,console insteadChristopher Degawa12 days1-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes an issue with clang not using the -mconsole option if mwindows is present resulting in mpv.com being a gui program instead of a console program. Does not interfere with gcc compilation. result without this patch ``` file .\mpv.com .\mpv.exe .\mpv.com: PE32+ executable (GUI) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` both executables open the mpv gui with out console output. result with this patch ``` file .\mpv.com .\mpv.exe .\mpv.com: PE32+ executable (console) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` mpv.com properly outputs text to console instead of instantly opening a gui `, for MS Windows` removed from the end of file outputs to reduce col count https://github.com/m-ab-s/media-autobuild_suite/issues/1794 Signed-off-by: Christopher Degawa <ccom@randomderp.com>
* docs: fix simple typo, unminimze -> unminimizeTim Gates12 days1-1/+1
| | | | | | There is a small typo in DOCS/man/options.rst. Closes #8165
* DOCS: fix typo on sub-filter-regex-enableChris Varenhorst2020-10-121-1/+1
|
* manpage: reference standard for configuration file locationwm42020-10-091-0/+5
|
* Revert "demux: add a POS"wm42020-10-084-190/+0
| | | | | | This reverts commit 4f18e7927bacd2e887f8cca48a967804ce7adf86. It was a mistake, and barely anyone needs this.
* player: fix another nightmarish corner casewm42020-10-081-3/+14
| | | | Pretty much fuck this shit.
* demux: add a POSwm42020-10-084-0/+190
| | | | | | I regret doing this so much, it's fucking garbage. Fixes: #5100
* Revert "wayland: add wayland-display-socket option"Dudemanguy2020-10-073-17/+3
| | | | | | | Pointless feature that can be done with environment variables. It was also implemented incorrectly and broke autoprobing. This reverts commit 015b6768759c8bd8cc815be01123ef95c192f3c5.
* wayland: add wayland-display-socket optionDudemanguy2020-10-063-3/+17
| | | | | | | | | | As per the client API, a client can connect to any arbitrary wayland socket. mpv has always just passed NULL which connected to the compositor currently in use, but one could just as easily pass the name of a different socket (i.e. the value of WAYLAND_DISPLAY). Here, we just expose this argument as a user configurable option. If the user passes a socket name that does not exist, then print a warning and fall back to NULL.
* screenshot: add --screenshot-sw optionwm42020-10-054-1/+19
| | | | | Probably worthless. As usual, the manpage dumps all the subtle differences due to implementation details on the user.
* wayland: set an opaque regionDudemanguy2020-10-013-0/+19
| | | | | | | | | Apparently a part of the wayland spec. A compositor may use a surface that has set part of itself as opaque for various optimizations. For mpv, we simply set the entire surface as opaque as long as the user has not set alpha=yes (note: alpha is technically broken in the wayland EGL backend at the time of this commit but oh well). wlshm is always opaque. Fixes #8125.
* options: fix --cover-art-file typoGuido Cella2020-09-301-1/+1
| | | | ...which makes it not work.
* player: cosmetically change around some codewm42020-09-281-9/+9
| | | | Is this better?
* player: add automatic loading of external cover art fileswm42020-09-286-8/+95
| | | | | | | | | | | | | | | | | | | | | | | Picks up files like "cover.jpg". It's made part of normal external file loading, so I'm adding 3 new options that are direct equivalents for the options that control loading of external subtitle and audio files. Even though I bet nobody wants them and they just increase confusion... I guess the world is actually hell, so this outcome should be fine. It prefers non-specific external files like "cover.jpg" over embedded cover art. Not sure if that's wanted or unwanted. There's some pain over explicitly marking such files as external pictures. This is basically an optimization: in most cases, a heuristic would treat an image file loaded with --external-file the same (it's a heuristic because ffmpeg can't tell us whether something is an image or a video). However, even with this heuristic, it would decode the cover art picture again on each seek, which would essentially slow down seeking in audio files. This bothered me greatly, which is why I'm adding these additional options at all, and bothered with the previous commit. Fixes: #3056
* player: let frontend decide whether to use cover-art modewm42020-09-283-7/+23
| | | | | | | | | | | | | Essentially, this lets video.c decide whether to consider a video track cover art, instead of having the decoder wrapper use the lower level sh_stream flag. Some pain because of the dumb threading shit. Moving the code further down to make some of it part of the lock should not change behavior, although it could (framedrop nonsense). This commit should not change actual behavior, and is only preparation for the following commit.
* ci: fix spirv-cross build in mingw scriptssfan52020-09-251-3/+8
|
* mac: add support for the focused propertyder richter2020-09-251-0/+4
|
* mac: add an option to prevent focusing of the window on opender richter2020-09-255-3/+22
| | | | | | | | | on macOS 10.15 setting the activation policy behaves quite weirdly. the call changes the current active App to a nameless process, which probably also the reason that prevents the not focusing to work. a workaround for that, is to refocus the previous active app. Fixes #7725
* travis: fix macOS 10.12 legacy buildder richter2020-09-221-0/+3
| | | | | | | | brew update tries to update the java cask, which it tries to build from source. this takes too long and leads to a timeout of the job. we can't manually remove the java cask because of a bug in the too old brew cask version and the old formula. we just remove the whole cask tap and call it a day, since we don't need it anyway.
* wayland: only render if we have frame callbackDudemanguy2020-09-217-37/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in the olden days, mpv's wayland backend was driven by the frame callback. This had several issues and was removed in favor of the current approach which allowed some advanced features (like display-resample and presentation time) to actually work properly. However as a consequence, it meant that mpv always rendered, even if the surface was hidden. Wayland people consider this "wasteful" (and well they aren't wrong). This commit aims to avoid wasteful rendering by doing some additional checks in the swapchain. There's three main parts to this. 1. Wayland EGL now uses an external swapchain (like the drm context). Before we start a new frame, we check to see if we are waiting on a callback from the compositor. If there is no wait, then go ahead and proceed to render the frame, swap buffers, and then initiate vo_wayland_wait_frame to poll (with a timeout) for the next potential callback. If we are still waiting on callback from the compositor when starting a new frame, then we simple skip rendering it entirely until the surface comes back into view. 2. Wayland on vulkan has essentially the same approach although the details are a little different. The ra_vk_ctx does not have support for an external swapchain and although such a mechanism could theoretically be added, it doesn't make much sense with libplacebo. Instead, start_frame was added as a param and used to check for callback. 3. For wlshm, it's simply a matter of adding frame callback to it, leveraging vo_wayland_wait_frame, and using the frame callback value to whether or not to draw the image.
* player: add pause state to playback start messagewm42020-09-211-2/+3
| | | | | Now the player tells you that audio or video are playing while paused, or something.
* terminal: fix segfault when backgroundingwm42020-09-211-2/+4
| | | | | | | | | In the recent terminal commit, I "compressed" the read() error handling, and messed it up. The return value could be -1 for other non-fatal errors (such as EIO when trying to read while backgrounded), which resulted in buf.len getting messed up. Fixes: 602384348e718c77
* f_decoder_wrapper: make log prefix less verbosewm42020-09-201-2/+2
|
* audio: take paused state into account in ao_start()sfan52020-09-201-1/+1
| | | | | It makes no sense to instruct the AO to start the pull callbacks when we know there's nothing to play (only affects pull AOs).
* audio: move start() calls outside of locksfan52020-09-201-3/+10
| | | | | Pull based AOs might want to call ao_read_data() inside start(). This fixes ao_opensles deadlocking.
* mac: add an option to change the App activation policyder richter2020-09-204-1/+28
| | | | useful to hide the app icon in the Dock if necessary.
* mac: add ontop window level for desktopder richter2020-09-203-4/+9
| | | | | | this puts the window ontop of the desktop but behind the desktop icons. Fixes #7791
* options: simplify --android-surface-size handlingsfan52020-09-205-27/+8
|
* build: disable GLXwm42020-09-181-2/+3
| | | | | | Nobody needs this anymore. If not too many people complain, we'll remove this completely. Many already consider X11 and OpenGL legacy, so we don't need TWO X11/OpenGL backends.
* manpage: fix console keybindings punctuationGuido Cella2020-09-181-3/+3
|
* msg: make --msg-time show time in secondswm42020-09-182-2/+2
| | | | | More readable, similar to what --log-file will use (although the terminal code shows microseconds and uses less left padding).
* build: sort dependencies (to make build deterministic)Philip Sequeira2020-09-181-1/+1
| | | | Fixes #7855.
* command, demux: make drop-buffers reset state even harderwm42020-09-172-4/+10
| | | | Leave nothing left when it's executed.
* terminal: attempt to handle the ESC keywm42020-09-171-24/+22
| | | | | | | | | | | | | | | | | | Due to Unix being legacy garbage, it's not possible to safely detect the ESC key on terminal. The key sequences are ambiguous. The code for the ESC key also starts the sequences for other special keys. Until now, you needed to hit ESC twice for it to be recognized. Attempt to handle this better by using a timeout to detect the key. If ESC is in the input buffer, but nothing else arrived after a timeout, assume it's the ESC key. I think this is the method vim uses. Currently, the timeout is set at 100ms. This is hardcoded and cannot be changed. It's possible that this causes problems on slow ssh connections or so. I'm not sure what exactly happens if you manage to get ESC + another normal key into the input buffer. If it's a known sequence, it will be matched and interpreted as such. If not, it'll probably be discarded.
* client API: update alignment requirements for software renderingwm42020-09-171-9/+12
| | | | | | | Previous commit fixes it for libswscale. The libzimg path has extra code to copy by slice, but it still may access pixel groups using normal memory accesses (for example, reading rgba pixel data via uint32_t), so document a minimum alignment requirement per pixel format.
* sws_utils: work around libswscale corrupting memory yet againwm42020-09-172-2/+57
| | | | | | | | | | | | | | | | | | | | If the alignment is less than 16, certain libswscale code paths will silently corrupt memory outside of the target buffer. This actually affected the libmpv software rendering API (that was fun to debug). Rather than passing this problem to the next API user, try to avoid it within libmpv. It's unclear which alignment libswscale requires for safe operation. I'm picking 32 (one more than the observed safe value in the case I experienced), because libavfilter mostly uses this value. The way to work this around is slow: just make a full copy of the entire input or output image. Possibly this could be optimized by using the slice API, but that would be more effort, and would likely expose further libswscale bugs. Hope that this is a rarely needed path. The next commit will update the alignment requirement documentation bits.
* manpage: refer to --sub-color for colorsGuido Cella2020-09-171-4/+4
| | | | | Don't make the user search for --osd-color only to make him search again for --sub-color.
* manpage: mark file-local-options as writableGuido Cella2020-09-171-1/+1
|
* stream_slice: interpret `end` as offset if it starts with '+'Mohammad AlSaleh2020-09-172-0/+11
| | | | | | | | Example: slice://1g-2g@file.ts (1 to 2) slice://1g-+2g@file.ts (1 to 3) Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* command: add property track-list/N/main-selectionwnoun2020-09-122-0/+18
|
* player: fix inconsistent AO pause state in certain situationswm42020-09-122-8/+3
| | | | | | | | | | | | | | | | | | Pause can be changed during a file change, such as with for example --reset-on-next-file=pause, or in hooks, or by being quick, and in this case the AO's pause state was not updated correctly. mpctx->ao_chain is only set if playback is fully initialized, while the AO itself in mpctx->ao can be reused across files. Fix this by always running set_pause_state() if the pause option is changed. Could cause new bugs since running this used to be explicitly avoided outside of the loaded state. The handling of time_frame is potentially worrisome. Regression due to recent audio refactor; before that, the AO didn't have a separate/persistent pause state. Fixes: #8079
* player: some minor code golfwm42020-09-101-11/+6
|
* vo_vdpau: remove an unused variablewm42020-09-101-2/+0
|
* player: clamp relative seek base time to nominal durationwm42020-09-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b74c09efbf7, audio-only files let you seek to arbitrary points beyond the end of the file (but still displayed the time clamped to the nominal file duration). This was confusing and just not wanted. The reason is probably that the commit removed setting the audio PTS for data before the seek target, so if you seek past the end of the file, the audio PTS is never set. This in turn means the logic to determine the current playback time has no PTS at all, and thus falls back to the seek PTS. This happened in the past for other reasons (like efe43d768f). I have enough of this, so I'm just changing the code to clamp the seek timestamp to a "known" range. Do this when seeking ends, because in the fallback case, the playback time shouldn't be stuck at e.g. "end + seek_argument". Also do it when initiating a new seek (mp_seek), because if the previous seek hasn't finished yet, it shouldn't add them up and allow it to go "out of range" either. The latter is especially relevant for hr-seeks. Doing this clamping is problematic because the duration is a possibly invalid value from the demuxer, or just missing. Especially with timestamp resets, fun sometimes happens, and in these situations it might be better not to clamp. One could argue you should just use the last audio timestamp returned by the decoder or demuxer (even if that directly conflicts with --end), but that sounds even more hairy. In summary: what a dumb waste of time, what the fuck.
* manpage: "fix" some formattingwm42020-09-101-4/+8
| | | | Yeah, fuck this retarded garbage.
* terminal-unix: attempt to support more CTRLwm42020-09-101-6/+14
| | | | | | | Hysterically stupid inconsistent legacy garbage from the 70ies or maybe even 60ies. What the fuck. I fucking hate computers so much. Fixes: #8072
* vo_vdpau: remove deprecated/inactive --vo-vdpau-deint optionwm42020-09-094-30/+1
| | | | | I think this has been dead code for quite a while. It was deprecated anyway.
* command: add read-only focused propertyGuido Cella2020-09-088-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
* manpage: fix typoGuido Cella2020-09-061-4/+4
| | | | | Change 'already by defined' to 'already defined' and reformat the paragaph.
* options: fix a flags fieldwm42020-09-041-2/+2
|
* ao_alsa: make partial writes an error messagewm42020-09-031-2/+2
| | | | And I think "partial write" is easier to understand than "short write".
* audio: fix stream-silence with push AOs (somewhat)wm42020-09-032-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | --audio-stream-silence is a shitty feature compensating for awful consumer garbage, that mutes PCM at first to check whether it's compressed audio, using formats advocated and owned by malicious patent troll companies (who spend more money on their lawyers than paying any technicians), wrapped in a wasteful way to make it constant bitrate using a standard whose text is not freely available, and only rude users want it. This feature has been carelessly broken, because it's complicated and stupid. What would Jesus do? If not getting an aneurysm, or pushing over tables with expensive A/V receivers on top of them, he'd probably fix the feature. So let's take inspiration from Jesus Christ himself, and do something as dumb as wasting some of our limited lifetime on this incredibly stupid fucking shit. This is tricky, because state changes like end-of-audio are supposed to be driven by the AO driver, while playing silence precludes this. But it seems code paths for "untimed" AOs can be reused. But there are still problems. For example, underruns will just happen normally (and stop audio streaming), because we don't have a separate heuristic to check whether the buffer is "low enough" (as a consequence of a network stall, but before the audio output itself underruns).
* encode: propagate errors to exit status properlywm42020-09-032-1/+7
| | | | | Don't just let mpv CLI return 0 (success) as exit status if encoding failed somehow.
* ao_lavc: slightly simplify filter usewm42020-09-031-12/+12
| | | | | | Create a central function which pumps data through the filter. This also might fix bogus use of the filter API on flushing. (The filter is just used for convenience, but I guess the overall result is still simpler.)
* client API: inactivate the opengl_cb APIwm42020-09-032-88/+13
| | | | | | | | | | The render API replaced the opengl_cb API over 2 years ago. Since then, the opengl_cb API was emulated on top of the render API. While it would probably be reasonable to emulate these APIs until they're removed in an eventual libmpv 2.0 bump, I have some non-technical reasons to disable the API now. The API stubs remain; they're needed for formal ABI compatibility.
* encode: disable unsupported media types automaticallywm42020-09-033-19/+57
| | | | | | | If you encode to e.g. an audio-only format, then video is disabled automatically. This also takes care of the very cryptic error message. It says "[vo/lavc] codec for video not found". Sort of true, but obscures the real problem if it's e.g. an audio-only format.
* encode: remove early EOF failure handlingwm42020-09-034-29/+0
| | | | | | | I don't see the point of this. Not doing it may defer an error to later. That's OK? For now, it seems better to reduce the encoding internal API. If someone can demonstrate that this is needed, I might reimplement it in a different way.
* audio: slightly simplify audio_start_ao()wm42020-09-031-10/+4
| | | | Get rid of an indirection; no behavior change.
* audio: reduce excessive logging of delayed audio startwm42020-09-032-2/+9
| | | | | | | Since this is a messy and fragile mechanism, I want it logged (even if it's somewhat in conflict with the verbose logging policy). On the other hand, it's unconditionally logged on every playloop iteration. So add some nonsense to log it only on progress.
* ao_alsa: log more information on short writeswm42020-09-021-2/+4
|
* audio: do not show audio draining message when it does not make sensewm42020-09-011-1/+3
| | | | | | Just for the redundant message. The function which is called here, ao_drain(), does not care in which state it is called, and already handled this gracefully.
* audio: do not wake up player when waiting for audio state and pausedwm42020-09-011-1/+2
| | | | Bullshit.
* audio: fix AVFrame allocation (crash with opus encoding)wm42020-09-011-0/+2
| | | | | | | | | | | | AVFrame doesn't have public code for pool allocation, so mpv does it manually. AVFrame allocation is very tricky, so we added a bug. This crashed with libopus encoding, but not some other audio codecs, because the libopus libavcodec wrapper accesses AVFrame.data. Most code tries to avoid accessing AVFrame.data and uses AVFrame.extended_data, because using the former would subtly corrupt memory on more than 8 channels. The fact that this problem manifested only now shows that most AVFrame consuming FFmpeg code indeed uses extended_data for audio.
* DOCS/interface-changes: remove encoding mode deprecation entrywm42020-09-011-1/+0
| | | | It was undeprecated.
* player/playloop.c: reorder included headers per contribute.mdLeo Izen2020-08-311-17/+14
| | | | | This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
* ao_openal: restore working condition with new push APILAGonauta2020-08-311-8/+10
|
* ao: remove unused fieldwm42020-08-311-1/+0
|
* audio: fix inefficient behavior with ao_alsa, remove period_size fieldwm42020-08-297-24/+13
| | | | | | | | | | | | | | | | | | | | It is now the AO's responsibility to handle period size alignment. The ao->period_size alignment field is unused as of the recent audio refactor commit. Remove it. It turns out that ao_alsa shows extremely inefficient behavior as a consequence of the removal of period size aligned writes in the mentioned refactor commit. This is because it could get into a state where it repeatedly wrote single samples (as small as 1 sample), and starved the rest of the player as a consequence. Too bad. Explicitly align the size in ao_alsa. Other AOs, which need this, should do the same. One reason why it broke so badly with ao_alsa was that it retried the write() even if all reported space could be written. So stop doing that too. Retry the write only if we somehow wrote less. I'm not sure about ao_pulse.
* encode: undeprecatewm42020-08-291-2/+1
| | | | I guess the audio timestamp corruption problem is probably solved now.
* ring: remove thiswm42020-08-293-240/+0
| | | | | The code is OK, and it could be restored if it's needed again. But it is unused now, so remove it.
* audio_buffer: remove thiswm42020-08-293-200/+0
| | | | | | Unused, was terrible garbage. It was (or at least its implementation was) always a make-shift solution, and just gross bullshit. It is unused now, so delete it.
* audio: refactor how data is passed to AOwm42020-08-2912-768/+638
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
* DOCS: fix minor issue on the --video-latency-hacks explanationChris Varenhorst2020-08-281-2/+2
|
* Update compile-windows.mdcrackself2020-08-281-1/+1
| | | fix lua5.1-5.2 support with luajit (mxe default upstream lua5.3 )
* manpage: reorder sentenceGuido Cella2020-08-281-3/+3
|
* f_async_queue: add various helper functionswm42020-08-282-2/+105
| | | | | Shouldn't change the behavior if not used. Will probably be used in a later commit.
* f_async_queue: don't count EOF frames as sampleswm42020-08-282-1/+4
| | | | That's dumb.
* f_async_queue: change reset behaviorwm42020-08-282-3/+15
| | | | | | | | | | | | | | | | Do not make resetting the "access" filters reset the queue itself. This is more flexible, and will be used in a later commit. Also, if the queue is not in the reset state while the input access filter is reset, make it immediately request data again. This is more consistent, because it'll enter the state it "should" be, rather when the filter's process function is called at an (essentially) random point in the future. This means the filter graph will resume work on its own if the queue was not reset before filter reset. This could affect the only current user of f_async_queue, the code for the --vd-queue-enable/--ad-queue-enable feature in f_decoder_wrapper. But it looks like this already uses it in a compatible way.
* filter: add filter priority thingwm42020-08-282-6/+31
| | | | | | | This is a kind of bad hack (with bad implementation) to paint over other problems of the filter system. The main problem is that some filters might be left with pending frames if the filter runner is "paused", which we don't want. To be used in a later commit.
* manpage: slightly improve property list notewm42020-08-281-3/+4
|
* sd_ass: replace deprecated ASS_OVERRIDE_BIT_FONT_SIZEOneric2020-08-282-5/+3
| | | | This requires a slightly more recent libass than before
* osd_libass: don't use deprecated ass_set_aspect_ratioOneric2020-08-281-2/+2
|
* f_demux_in: log EOF "recovery"wm42020-08-271-0/+2
| | | | For debugging.
* f_decoder_wrapper: pass through EOF after EOFwm42020-08-272-0/+8
| | | | | | | | | It's relevant in some obscure corner cases (EDL file that has a segment without audio). Didn't test what's actually going on (is ad_lavc.c behaving wrong? is libavcodec behaving wrong or in an unexpected way? is lavc_process wrong?) and just patched it over with some bullshit, so the fix might be too complicated, and could be reworked at some later point. This sure is a real data flow fuckmess.
* player: fix video paused condition on VO creationwm42020-08-273-2/+8
| | | | | Doesn't take paused_for_cache into account. For consistency; unlikely to matter at all in practice.
* filter: add a helperwm42020-08-272-0/+8
| | | | | Not used yet; probably will, just dumping this to get it out of my sight.
* audio: clarify set_pause() documentationwm42020-08-271-0/+1
|
* audio: adjust frame clipping for spdif formatswm42020-08-271-2/+4
| | | | | | Allow mp_aframe_clip_timestamps() to discard a spdif frame if it's entirely out of the timestamp range. Just a minor thing that might make handling these dumb formats easier.
* audio: remove unused ring.h includeswm42020-08-272-2/+0
| | | | | From what I can tell, this has been copy-pasted from times when ao_coreaudio still used its own ringbuffer, instead of the common code.
* player: fix swapped debug outputwm42020-08-271-2/+2
| | | | Such failure.
* vo_gpu: EGL: fix transparency on X11/EGL/Mesawm42020-08-272-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Transparent windows on X11/EGL/native Mesa GL didn't work for various reasons. From what I remember, the current code did work with nvidia at least. Mesa has made attempts to fix this, but they never really made it in. But it turns out you can make EGL/Mesa list the EGLConfigs that use X11 RGBA visuals, and context_x11egl.c contains code that explicitly selects them if alpha is requested (see pick_xrgba_config()). The reason EGL/Mesa did not list them (and thus breaking transparency) is because we requested a EGL_ALPHA_SIZE != 0 if alpha is requested. But the transparent EGLConfigs use EGL_ALPHA_SIZE == 0. That's because EGL doesn't actually support the concept of transparent windows; the alpha size parameter is something else (memory rendering without FBOs or something, I don't care enough to look up the real reasons). This still won't work on Wayland. Every EGL backend needs platform specific code. (Good job, EGL, such an awesome platform independent standard.) Fixes: #6590
* vo_gpu: EGL: slightly better debug logging of EGL configswm42020-08-271-1/+2
|
* ao/pulse: create the stream corkedsfan52020-08-261-1/+1
| | | | | | | | | Previously get_state() would keep setting the cork status while paused, but it only does for that after underflows now. Correct this oversight by creating the stream corked for start() to uncork it at a later time. fixes #8026
* wayland: always update sbc for presentation timeDudemanguy2020-08-241-0/+1
| | | | | | | | | | | | | Oversight in b0f0be7. The user_sbc value would update but not last_sbc if no presentation events were received. This would result in an incorrect sbc_passed value (in practice, this should always be 1 since, as far I know, all wayland compositors are currently only capable of double buffering). When bring the window back into view, it would result in a single frame of very high vsync jitter. Although in most cases it was imperceptible, rarely I was able to completely break playback (i.e. constant mistimed/dropped frames). Fix this by simply incrementing last_sbc by 1 if the window is hidden. The buffer swap call did still occur. The user just didn't see it.
* Revert "demux_lavf: always give libavformat the filename when probing"wm42020-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 41243e7c4f98b410195397b6758f9796acd9de57. This fixes image format detection. FFmpeg has an utter called "image2", which is designed to read patterns in filenames (so you can play something like "%*.jpg" for all jpg files in the current directory). "image2" is not what we want; it's just broken with custom I/O like mpv uses it, and we don't want to "accidentally" interpret filenames as pattern. That's why mpv blacklists it. Unfortunately, "image2" is sometimes the format that FFmpeg's probe API returns as best match. Thus demux_lavf fails to detect the file type, and after some more futile attempts, we end up at demux_mf, which uses detection by file extension. (Not sure why. I guess MPlayer did that, and foudn that sufficient.) If the file extension is wrong (which happens a lot because apparently the world is full of idiots who don't manage to get the most simple things right), the image "loads", but decoding obviously fails. There's no easy way around this. The FFmpeg API has no mechanism to exclude a specific format from probing (like image2, which breaks stuff for us). Out of the 5 probe functions the API provides, none can probe a specific format or include or exclude specific formats. The main problem is that AVInputFormat.read_probe is a private symbol. FFmpeg itself has no problem opening such files. It turns out that it works, because even though image2 by itself uses detection by file extension, it uses private API to further probe the exact format. It explicitly excludes itself to prevent recursion. But fortunately, that also means that it's impossible to get the image2 format if no filename is passed to the prober. (No filename, no file extension.) Apparently we pass it in because it helps in corner cases. Until almost 3 years ago, we passed the filename only when normal probing already failed. Restore this by this revert. It makes incorrectly named files work. The revert also makes the (apparently forgotten) comment above the touched line of code true again. Yes, quite possible that this breaks some mp3s again. You can't win with FFmpeg. Thanks FFmpeg for making us fail at opening simple image files and/or the most widely used file format for audio.
* audio: remove delay debug loggingwm42020-08-232-28/+0
| | | | Some absurd useless stuff.
* wayland: simplify presentation timeDudemanguy2020-08-222-12/+10
| | | | | | | | | | | Why on earth did I ever bother with this dumb crap? If we do not have any presentation statistics, just set the relevant vo_sync_info values to -1 to disable it. It's much simpler than using mp deltas and trying to keep up with mpv's clock. This also appears to fix audio/video desynchronization if you start a video with the pause flag, move it out of view, and then unpause it. Technically harmless since the video wasn't even in view and putting back in view recovered it, but a quieter terminal is better.
* demux_mf: actually report errorswm42020-08-221-0/+6
| | | | | | Well, whatever. Only results in an error message being printed, because there is no other error reporting mechanism, and the general policy is to keep trying with the rest of the data (i.e. not report EOF).
* player: do not loop if there's nothing to loopwm42020-08-221-0/+5
| | | | | | | | | | | | | | | | | This can happen if a file contains headers only, or if decoding of all data failed, and such. Interestingly, it also happened when doing "mpv --loop emptyfile.png", because demux_mf still detects file formats by file extension. In this situation, the player burned a lot of CPU by restarting playback after doing nothing. Although such "degenerate" behavior can't be avoided in all situations (what if you loop a file with 1 audio sample?), detecting this seems to make sense. For now, this actually decrements the loop count by 1, and then errors out with a warning. Works for --loop and --ab-loop, while --loop-playlist already avoids this situation with an existing mechanism.
* options: do not accept ":" as separator anymore in key/value listswm42020-08-223-1/+10
| | | | | | | | | | | | | | | | | | Accepting ":" in addition to "," seems confusing and dumb. It only causing problems when you want to pass a value that contains ":". Remove support for ":", it is now treated like any other normal character. This affects all options that are listed as "Key/value list" in the option list. It's possible that this breaks for someone who happened to use ":" as separator. But this was undocumented, and never recommended. Originally, the option treated many other characters in a special way, but this was changed in commit a3d561f950e74fe. I'm, not sure why ":" was explicitly included. Maybe because -the absurd -vf/--af syntax uses ":" as list separator. But "," was always recommended and used in examples for key/value options. Fixes: #8021 (if you consider it a bug)
* cocoa-cb: force layer update on resizeder richter2020-08-221-1/+1
| | | | | | | | this fixes some race condition where the content of the layer wasn't updated because the size didn't changed and the layer was already marked as updated. just force an update on reconfig. Fixes #7989
* mac: add icc profile and ambient light sensor supportder richter2020-08-221-6/+30
| | | | | | this is preparation for new backends. currently this is done via the libmpv API but for future new new VOs not based on libmpv we need these VOCTRL events.
* mac: use config cache und wakeup for mac option runtime changesder richter2020-08-225-60/+72
| | | | | | | | remove the libmpv observer for the macOS specific options and use a config cache + change callback for runtime changes. this is also a preparation for new backends and generalises even more, since libmpv functions can't and shouldn't be used in usual vo backends. for feature parity the config cache is used.
* mac: make ontop level runtime changeableder richter2020-08-221-1/+2
| | | | | | this was requested on an old issue, but the comment has since been deleted. i though it was useful enough to add it. it's also just a one line change.
* mac: properly guard and unwrap an optional valueder richter2020-08-221-8/+12
| | | | | i don't know what i was thinking there, but force unwrapping is a very bad idea.
* cocoa-cb: generalisation of backend independent partsder richter2020-08-2211-566/+741
| | | | | | | | | | | | | move all backend independent code parts in their own folder and files, to simplify adding new backends. the goal is to only extend one class and add the backend dependent parts there. usually only the (un)init, config and related parts need to be implemented per backend. furthermore all needed windowing and related events are propagated and can be overwritten. the other backend dependent part is usually the surface for rendering, for example the opengl oder metal layer. in the best case a new backend can be added with only a few hundred lines.
* client API: note about libswscale corrupting memorywm42020-08-201-1/+10
| | | | | | The software rendering API makes libswscale directly write into supplied user memory. As such, weird memory corruption bugs on non-optimal buffer configurations are exposed to the user.
* wayland: conditionally commit surface on resizeDudemanguy2020-08-203-2/+10
| | | | | | | | | | | | | | | | | | | | | It was possible for sway to get incorrectly sized borders if you resized the mpv window in a creative manner (e.g. open a video in a non-floating mode, set window scale to 2, then float it and witness wrong border sizes). This is possibly a sway bug (Plasma doesn't have these border issues at least), but there's a reasonable workaround for this. The reason for the incorrect border size is because it is possible for mpv to ignore the width/height from the toplevel listener and set its own size. This new size can differ from what sway/wlroots believes the size is which is what causes the sever side decorations to be drawn on incorrect dimensions. A simple trick is to just explicitly commit the surface after a resize is performed. This is only done if mpv is not fullscreened or maximized since we always obey the compositor widths/heights in those cases. Sending the commit signals the compositor of the new change in the surface and thus sway/wlroots updates its internal coordinates appropriately and borders are no longer broken.
* player: add --subs-with-matching-audio optionrcombs2020-08-196-9/+40
| | | | | | | | | This allows users to control whether full dialogue subtitles are displayed with an audio track already in their preferred subtitle language. Additionally, this improves handling for the forced flag, automatically selecting between forced and unforced subtitle streams based on the user's settings and the selected audio.
* wayland: refactor geometry/window handlingDudemanguy2020-08-202-104/+112
| | | | | | | | | | | | | | | | | | | | | | | | | The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
* stream: Implement slice:// for reading slices of streamsMohammad AlSaleh2020-08-194-0/+200
| | | | | | | | | | | | | | | | Add support for reading a byte range from a stream via the `slice://` protocol. Syntax is `slice://start[-end]@URL` where end is a maximum (read until end or eof). Size suffixes support in `m_option` is reused so they can be used with start/end. This can be very useful with e.g. large MPEGTS streams with corruption or time-stamp jumps or other issues in them. Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* wayland: reset geometry on reconfig if fullscreenDudemanguy2020-08-181-4/+10
| | | | Fixes #8014.
* wayland: soften GNOME warningDudemanguy2020-08-172-8/+1
| | | | | | | | | | | | | | | | | | | We've had some serious issues with GNOME in the past, but since then their compositor has undergone some major internal improvements. The most severe one [1], random vsync spikes and mistimed frames, can no longer be reproduced by the original author of the issue. There are some minor UI-related things (lack of window decorations for instance since there is no xdg-decoration support), but users don't seem to complain about that too much and they aren't revelant to playback. 3.38 isn't out quite yet, but that should also fix playback issues when on a multimonitor setup (the fix is in the master branch at the moment). In terms of playback, the only real concerning issue is the lack of idle inhibit so a warning is still displayed. But GNOME has their own workaround that users can use for that so if anyone happens to complain, we can just point them to that. [1] https://gitlab.gnome.org/GNOME/mutter/-/issues/957
* wayland: don't rely on presentation discardedDudemanguy2020-08-164-10/+4
| | | | | | | | | | | | | When using presentation time, we have to be sure to update the ust when no presentation events are received to make sure playback is still smooth and in sync. Part of the recent presentation time refactor was to use the presentation discarded event to signal that the window is hidden. Evidently, this doesn't work the same everywhere for whatever reason (drivers?? hardware??) and at least one user experienced issues with playback getting out of sync since (presumably) the discarded event didn't occur when hiding the window. Instead, let's just go back to the old way of checking if the last_ust is equal to the ust value of the last member in the wayland sync queue. Fixes #8010.
* wayland: refactor presentation timeDudemanguy2020-08-164-61/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation for this change was a segfault caused by e107342 which has complicated reasons for occuring (i.e. I'm not 100% sure but I think it is a really weird race). The major part of this commit is moving the initialization of presentation listener to the frame_callback function. Calling it in swap_buffers worked fine but in practice it meant a lot of meaningless function calls if a window was hidden (the presentation would just be immediately discarded). By calling it in frame_callback, we ensure the listener is only created when it is possible to receive a presentation event. Of course calling the presentation listener in feedback_presented or feedback_discarded was considered, but ultimately these events are too slow. Receiving the ust/msc/sbc triplet here and then passing it to mpv results in higher vsync judder since there is (likely) not enough time before the next pageflip. By design, the frame callback is meant to give us as much time as possible before the next repaint so calling it here is probably optimal. Additionally, we can make better use of the feedback_discarded event. The wp_presentation_feedback should not be destroyed here. It will be taken care of either when we get feedback again or when the player quits. Instead what we can do is set a bool that tells wayland_sync_swap to update itself based on mp_time delta. In practice, the result is not any different than before, but it should be more understandable what is going on now. Of course, the segfault mentioned at the beginning is fixed with this as well.
* DOCS/vo.rst: TCT: add note on interleaved outputAvi Halachmi (:avih)2020-08-161-2/+7
|
* win32: scripting utils.get_env_list(): use UTF-8Avi Halachmi (:avih)2020-08-164-4/+15
| | | | | | | | | | | | | | | | lua/js utils.get_env_list() uses `environ' which was ANSI, thus it broke any unicode names/values. mpv already has an internal utf8_environ for win32, but it's used only at the getenv(..) wrapper and not exposed in itself, and also it has lazy initialization - on first getenv() call. Now `environ' maps to a function which ensures initialization while keeping it an l-value (like posix expects). The cost of this fuglyness is that files should include osdep/io.h (which now declares environ as extern) rather than declaring it themselves, or else the build will break on mingw.
* lua: pass strings with embedded zeros as byte arrayswm42020-08-161-3/+14
| | | | | | | | | | This was a vague idea how to handle passing byte arrays from Lua to the mpv command interface in a somewhat reasonable way. The idea was cancelled, but leave the Lua part of it, since it might get useful later, and prevents passing (and silently cutting off) such byte strings. Barely tested, let's say not tested at all.
* command: extend subprocess command stdin, change behaviorwm42020-08-167-6/+110
| | | | | | | | | | | | | | | Make it possible to feed a string to stdin of a subprocess. Out of laziness, it can't be an arbitrary byte string. (Would require adding an option type that takes in a Lua byte string.) Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore, because it makes things more consistent. Enabling stdin didn't make too much sense in the first place, so this behavior change seems justifiable. win32 support missing. Fixes: #8003
* demux_mkv: warn against some other aspects of mismatching codec datawm42020-08-161-0/+5
| | | | | | Such files violate the specification. Unfortunately, I could not test whether it really works correctly, since I don't have a sample at hand that is not broken in this regard.
* command: export alpha type in format propertieswm42020-08-152-0/+18
|
* wayland: destroy presentation feedback on uninitDudemanguy2020-08-141-0/+3
| | | | | | | Nothing major but it's technically possible for the wp_presentation_feedback struct to still be allocated when quitting the player. Just destroy it if it exists like all of the other wayland objects.
* wayland: actually resize videos in a playlistDudemanguy2020-08-141-1/+1
| | | | | | | In a playlist of videos with different sizes, going to the next video would not properly resize the window. This actually broke way back in 7170910 (oops), but somehow nobody ever complained. The fix is simple. If a window isn't maximized, be sure to set the window geometry again.
* sd_ass: remove debug printwm42020-08-141-1/+0
| | | | It's not even spelled correctly.
* wayland: expose wayland-app-id as a user optionDudemanguy2020-08-144-0/+20
| | | | | This is extremely similar to x11's WM_CLASS. This commit allows users to set mpv's app-id at runtime for any of the wayland backends.
* wayland: tweak xdg_surface creationDudemanguy2020-08-141-5/+4
| | | | | | | | | | | | Just some small changes when creating the xdg_surface. Don't set the toplevel title (or app id) in create_xdg_surface anymore because it's entirely pointless. Also make it possible for create_xdg_surface to return something other than 0 so the error checking is somewhat meaningful. It's not really clear if these xdg functions can even fail in the first place (perhaps some weird proxy marshalling crap could possibly go wrong somehow), but it can't hurt. Note that all app id stuff has been removed (temporarily) in this commit. See the next commit which adds it back in.
* command: fix current-tracks property notificationwm42020-08-131-0/+1
| | | | Also for track-list, because it contains the "selected" flag.
* sub: add application/font-sfnt to the list of font mime typesWessel Dankers2020-08-131-0/+1
| | | | | | | According to both file(1) and https://www.iana.org/assignments/media-types/application/font-sfnt application/font-sfnt is also a valid mime type for (at least some) .ttf files.
* client API: fix misleading remarkAlcaro2020-08-131-2/+1
|
* manpage: document a couple of wayland optionsDudemanguy2020-08-121-0/+9
| | | | | --wayland-edge-pixels-pointer and --wayland-edge-pixels-touch were both left out of the manual.
* ytdl_hook: sort subtitle list by languagewm42020-08-121-1/+7
| | | | | | The subtitle list is returned in randomized order, because a table (i.e. JSON object) is used. To make the order stable across repeated invocations, sort it by language.
* client API: fix incorrect documentation in sw rendererwm42020-08-121-4/+4
| | | | | | This was incorrect, and grossly misleading. It created the impression that the buffer is passed to mpv_render_context_create(), instead of mpv_render_context__render().
* sd_ass: fix converted subtitles pathwm42020-08-121-7/+7
| | | | Commit cda8f1613ff3 broke this.
* DOCS/contribute.md: add a CCoCwm42020-08-121-1/+4
| | | | | | | (The recommendation is to add the document to the project git root, but I'm against dumping such things into git. I'd rather replace the Copyright full text files with links and move contribute.md to the wiki than add the CCoC text as a file.)
* sub: extend range of --sub-pos optionwm42020-08-123-5/+14
| | | | | | | | | | | | Seems like this is requested all the time. It seems libass allows out of range values, but does allows the subtitle to go out of the screen at the bottom (only when moving it to the top it's "clamped"). Too bad, don't do that then. The bitmap sub rendering code on the other hand is under our control, and will not move a subtitle out of the screen. Fixes: #7986
* sd_ass: force full reinit if certain options change at runtimewm42020-08-125-34/+60
| | | | | | | | | | Options like --sub-ass-force-style and others could not be changed at runtime (the changes didn't take any effect). Fix this by using the brutal approach, and completely reinit the subtitle state when this happens. Maybe a bit clunky, but for now I'd rather not put more effort into this. Fixes: #7689
* command: add a way to access properties of a current trackwm42020-08-122-1/+69
| | | | | | Requested. Should be good for simple use cases. "sub2" is technically inconsistent (since the option is called --secondary-sid), but fuck the consistent name.
* TOOLS/file2string: change to python3wm42020-08-121-1/+1
| | | | | | The same was done to matroska.py before, so at least it's consistent. Doesn't matter for waf, because it imports this script (rather than executing it).
* win32: request the UTF-8 code page for Windows APIsJames Ross-Gowan2020-08-081-0/+1
| | | | | | | | | | | | | | This sets the activeCodePage property in the manifest, which forces the ANSI code page to be UTF-8 in Windows 10 1903 and up. It shouldn't make a difference for mpv itself, since mpv already uses the wide-char APIs for most functions, however some of mpv's dependencies, such as Lua, rely on the ANSI codepage. Hence this change enables support for Unicode file names in Lua's I/O library. Thanks @avih for finding this property. See: https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
* ao/lavc: add channels and channel_layout to AVFrameekisu2020-08-071-0/+2
| | | | | | FFmpeg expects those fields to be set on the AVFrame when encoding audio, not doing so will cause the avcodec_send_frame call to return EINVAL (at least in recent builds).
* auto_profiles: unapply conditional profiles if declaredwm42020-08-072-19/+37
| | | | | | Uses the mechanism introduced in the previous commit. The hope was to make auto-profiles easier to use, and to get rid of the need for manually created inverse profiles. Not sure if the end result is useful.
* options: add some way to more or less "unapply" profileswm42020-08-076-61/+212
| | | | | | | | | | | | | | | | | | | | | | | | Make it possible to restore from profiles by backing up the option values before profile application. This is sort of like unapplying a profile. Since there might be multiple ways to do this, a profile needs to explicitly provide the "profile-restore" option, which specifies how exactly this should be done. This is a big mess. There is not natural way to do this. Profile application is "destructive" and simply changes the values of the options. Maybe one could argue that the option system should have hierarchical "overlays" of profiles instead, where unset options will use the value of the lower profiles. Options set interactively by the user would be the top profile. Default values would be in the lowest profile. You could unapply a profile by simply removing it from this overlay stack. But uh, let's not, so here's something stupid. It reuses some code used for file local options to reduce code size. At least the overlay idea would still be possible in theory, and could be added as another profile-restore mode. This is used by the following commit.
* js: hooks: allow deferred continuation (match d0ab562b)Avi Halachmi (:avih)2020-08-072-3/+10
| | | | | | | | | | The callback now gets an object argument with defer/cont functions. Like the lua code, the behavior is that each hook event allows at most one continue, but nothing enforces the order of continuations if more hook events arrive before prior ones were continued - which is possible now with the defer option, but wasn't possible before (continuation was synchronous from the hook event handler).
* auto_profiles: register hooks for more synchronous profile applicationwm42020-08-051-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | The property observation mechanism is fairly asynchronous to the player core, and Lua scripts also are (they run in a separate thread). This may sometimes lead to profiles being applied when it's too load. For example, you may want to change network options depending on the input URL - but most of these options would have to be set before the HTTP access is made. But it could happen that the profile, and thus the option, was applied at an slightly but arbitrary later time. This is generally not fixable. But for the most important use-cases, such as applying changes before media opening or playback initialization, we can use some of the defined hooks. Hooks make it synchronous again, by allowing API users (such as scripts) to block the core because it continues with loading. For this we simply don't continue a given hook, until we receive an idle event, and have applied all changes. The idle event is in general used to wait for property change notifications to settle down. Some of this relies on the subtle ways guarantees are (maybe) given. See commit ba70b150fbe for the messy details. I'm not quite sure whether it actually works, because I can't be bothered to read and understand my bullshit from half a year ago. Should provide at least some improvement, though.
* lua: make hook processing more flexiblewm42020-08-052-4/+41
| | | | | | | This can now opt to not continue a hook after the hook callback returns. This makes it easier for scripts, and may make it unnecessary to run reentrant event loops etc. for scripts that want to wait before continuing while still running the event loop.
* auto_profiles: add this scriptwm42020-08-0513-7/+326
| | | | | | | | | | | | | | | | | | | | | This is taken from a somewhat older proof-of-concept script. The basic idea, and most of the implementation, is still the same. The way the profiles are actually defined changed. I still feel bad about this being a Lua script, and running user expressions as Lua code in a vaguely defined environment, but I guess as far as balance of effort/maintenance/results goes, this is fine. It's a bit bloated (the Lua scripting state is at least 150KB or so in total), so in order to enable this by default, I decided it should unload itself by default if no auto-profiles are used. (And currently, it does not actually rescan the profile list if a new config file is loaded some time later, so the script would do nothing anyway if no auto profiles were defined.) This still requires defining inverse profiles for "unapplying" a profile. Also this is still somewhat racy. Both will probably be alleviated to some degree in the future.
* manpage: clarify requirements for boxvideoDudemanguy2020-08-041-1/+2
| | | | The osc must not auto-hide for this option to do anything.
* wayland: don't set mouse pos on state changeDudemanguy2020-08-022-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sway 1.5 started sending more pointer motion events to mpv which broke the autohiding behavior. The cursor would appear again if you fullscreened. Sway had a good reason to do this because certain applications had inconsistencies between hardware cursor and software cursor without rebasing on state changes[1]. So mpv needs to take this special case into consideration. Initially, simply checking mouse coordinates for changes was considered, but this doesn't work. All coordinates are surface-local in wayland so something can appear to move in the local coordinate space but not globally. You're not allowed to know global mouse coordinates in wayland, and we don't care about local coordinate changes in mpv so this approach isn't viable. Instead, let's just keep track of a local state change. If the toplevel surface changes in some way (fullscreen, maximized, etc.), then just set a bool that lets us ignore the mp_input_set_mouse_pos function. This keeps the cursor from appearing simply because the state was changed (i.e. fullscreening). For compositors that don't send pointer motion events on a state change, this does technically mean that the initial mp_input_set_mouse_pos is never set. In practice, this isn't a noticeable difference though because moving a mouse generates a ton of motion events so you'll immediately see it on the second motion event. [1] https://github.com/swaywm/sway/issues/5594
* stats: fix crash when aspect ratio is unavailableEva2020-08-031-1/+3
| | | When switching between files it's possible that r["aspect"] returns nil, resulting in a crash.
* ytdl_hook: fix typo in unexpected error messageDerek Guenther2020-08-011-1/+1
|
* wayland: avoid potential deadlocksDudemanguy2020-07-311-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wl_display_dispatch is dangerous because it will block forever if the event queue is empty. Any direct calls to this function should just be replaced with wl_display_dispatch_pending which accomplishes the same thing for mpv's purposes without any chance of blocking. The other potential trap is wl_display_roundtrip. It can internally call wl_display_dispatch which in certain circumstances could potentially block. There are cases where we need the server to finish processing client requests before doing anything else so this can not be cleanly avoided. The dangerous call is the usage of wl_display_roundtrip in vo_wayland_wait_frame. In the majority of cases, this shouldn't be a problem because the previous wl_display_read_events should always queue up some events on the fd for wl_display_roundtrip to send. However, the compositor could potentially send us an error in the display queue that could lead to bad behavior when wl_display_roundtrip is called. The wl_display_roundtrip can't be removed because we are relying on its semi-blocking capabilities, but the logic can be slightly adjusted to be safer. The obvious thing to do is to make sure we check the pollfd for any errors. If one is returned, then we call wl_display_cancel_read and try again. The less obvious trick is to call wl_display_dispatch_pending and move wl_display_roundtrip outside of the blocking + timeout loop. This change has some subtle but important differences. Previously, vo_wayland_wait_frame would read an event and wait on the server to process it one-by-one. With this change, the events are dispatched as soon as possible to the server and then we wait on all of those (potentially multiple) events to be processed after we have either received frame callback or the loop times out. After that is done, we can then check for if there are any errors on the display. If it's all clear, we can run wl_display_roundtrip without any worries. If some error happens, then don't execute the function at all.
* travis: update macOS image from 10.14 to 10.15der richter2020-07-311-1/+1
|
* travis: make macOS builds fasterder richter2020-07-311-28/+18
| | | | | | | | | | | | | | the problem here is that with time, and because the macOS VMs don't get updated, the homebrew update is getting longer since more and more changes have to be pulled. to prevent that, we cache the homebrew installation folder after the update. that way we don't have to update several months worth of updates every build. for the legacy build we have to check put master again to actually cache the newest homebrew version. additionally to that, we also do the same as on the legacy build, with the addition of not removing all installed formulas but only the ones we don't need. so we don't need to reinstall those.
* travis: fix macOS 10.12 legacy buildder richter2020-07-311-0/+1
| | | | | | | | | just remove all pre installed formulas, since we don't need the majority of it. after that install what we need. this also fixes the brew update of those formulas where the source links were broken like popt. this also helps when the build times out due to building some formulas from source that are not dependencies we need.
* wayland: correctly signal the end of drag-and-dropDudemanguy2020-07-291-1/+1
| | | | | | | | | | | | Previously, the compositor was signaled that a drag-and-drop ended with wl_data_offer_finish in check_dnd_fd. This is, however, erroneous because it is outside of the data_device_listener and in some cases caused errors with certain compositors. check_dnd_fd itself does not need to know or care about anything that happens in wayland. It just needs to read data from an fd. The simple fix is to just always signal the end of a drag-and-drop in data_device_handle_drop. check_dnd_fd can free memory and close the fd later, but it should not talk to the compositor. Fixes #7954.
* wayland: fix a potential race in wait_eventsDudemanguy2020-07-291-4/+7
| | | | | | | The read of the wayland display fd in vo_wayland_wait_events was incorrect and technically vulnerable to race conditions. The correct usage as per the client api is to use wl_display_prepare_read as well as wl_display_read_events.
* af_scaletempo2: fix bug where speed was not setDorian Rudolph2020-07-271-1/+0
| | | | | | the --speed parameter did not work with mpv --no-config whatever.mp3 --video=no --speed=2 --af=scaletempo2 (https://github.com/mpv-player/mpv/pull/7865#issuecomment-664243401)
* af_scaletempo2: M_PI is always definedwm42020-07-271-4/+0
| | | | I forgot why/how (C99?), but other code also uses it.
* audio: add scaletempo2 filter based on chromiumDorian Rudolph2020-07-277-0/+1121
| | | | | | | | scaletempo2 is a new audio filter for playing back audio at modified speed and is based on chromium commit 51ed77e3f37a9a9b80d6d0a8259e84a8ca635259. It sounds subjectively better than the existing implementions scaletempo and rubberband.
* js: add mp.utils.get_env_list() (match 0e7f53a5, 9301cb78)Avi Halachmi (:avih)2020-07-262-0/+15
|
* lua: change mp.get_env_list() to utils.get_env_list()Avi Halachmi (:avih)2020-07-261-1/+1
| | | | | It's documented (twice) at utils, and logically it's the correct place for it.
* stats: fix single invocation keybindingssfan52020-07-211-2/+5
|
* manpage: drop --sdl-bufcnt after 346c687d5ab2Jan Beich2020-07-211-4/+0
|
* external_files: add .pgs subtitle extensionEva2020-07-211-1/+1
|
* subprocess-win: update to mp_subprocess2James Ross-Gowan2020-07-205-141/+399
| | | | | | | | | | | | | | | | | | | This fixes the "run" and "subprocess" commands on Windows, including youtube-dl support. Unix-like FD inheritance is emulated on Windows by using an undocumented data structure[1] that gets passed to the newly created process in STARTUPINFO.lpReserved2. It consists of two sparse arrays listing the HANDLE and internal CRT flags corresponding to each FD. This structure is used and understood primarily by MSVCRT, but there are other runtimes and frameworks that can write it, like libuv. The code for creating asynchronous "anonymous" pipes in Windows has been enhanced and moved into windows_utils.c. This is mainly an artifact of an unfinished future change to support anonymous IPC clients in Windows. Right now, it's still only used in subprocess-win.c [1]: https://www.catch22.net/tuts/undocumented-createprocess
* manpage: add named arguments "subprocess" examplewm42020-07-201-5/+21
| | | | At the same time, this is an example for a command with named arguments.
* client API: comment about signal handlerswm42020-07-201-0/+2
| | | | | | | | | | | | Sharing a process sure is hard in POSIX. The rationale is that you'd have to handle EINTR on every single blocking syscall. stream_file.c does not seem to handle it on read() calls. It appears that on most modern systems, this can happen only if you call sigaction(), and incompetently forget to add SA_RESTART. signal() usually adds it.
* command: add another variant of revert-seekwm42020-07-202-4/+16
| | | | | | | Requested. See manpage additions. Not sure if it actually deserves to be a first class feature, rather than an external script or so. Fixes: #7913
* lua: add mp.get_env_list() functionwm42020-07-203-0/+20
| | | | | Because Lua is too stupid to provide this directly, and I sort of need it.
* command: extend subprocess commandwm42020-07-207-160/+115
| | | | | | | | | | | | | | | | | | | | Add env and detach arguments. This means the command.c code must use the "new" mp_subprocess2(). So also take this as an opportunity to clean up. win32 support gets broken by it, because it never made the switch to the newer function. The new detach parameter makes the "run" command fully redundant, but I guess we'll keep it for simplicity. But change its implementation to use mp_subprocess2() (couldn't do this earlier, because win32). Privately, I'm going to use the "env" argument to add a key binding that starts a shell with a FILE environment variable set to the currently playing file, so this is very useful to me. Note: breaks windows, so for example youtube-dl on windows will not work anymore. mp_subprocess2() has to be implemented. The old functions are gone, and subprocess-win.c is not built anymore. It will probably work on Cygwin.
* wayland: remove unused declarationDudemanguy2020-07-191-1/+0
| | | | Should have been removed in 055a490 but was forgetten.
* build: actually install the 128x128 iconsDudemanguy2020-07-191-1/+1
| | | | | mpv has generated this icon size for a while now, so go ahead and install it in the usual place like the other icon sizes.
* vo_gpu: clip highlights before tone-mappingNiklas Haas2020-07-191-4/+5
| | | | | | | | | | | | Rather than after tone-mapping. This prevents overflow when the pre-tonemapped signal contains inputs exceeding sig_peak. I also realized that with this clipping in place, post-clipping no longer needs to be done, so this isn't even particularly slower. The only two exceptions to the rule are "clip" and "linear", which relied on the post-clipping to do their tone mapping properly. Fixes #7929
* vo_gpu: vulkan: print libplacebo API verNiklas Haas2020-07-161-0/+1
| | | | | | | | This normally gets printed by libplacebo itself when initializing the context, but due to the way our code is structured (for convenience) we don't have the log hook enabled by the time this function call is relevant. So instead just print it manually as an easier work-around than restructuring the code.
* zimg: add slice threading and use it by defaultwm42020-07-154-20/+123
| | | | | | | | | | | | | | | | | | | | | | | This probably makes it much faster (I wouldn't know, I didn't run any benchmarks ). Seems to work as well (although I'm not sure, it's not like I'd perform rigorous tests). The scale_zimg test seems to mysteriously treat color in fully transparent alpha differently, which makes no sense, and isn't visible (but makes the test fail). I can't be bothered with investigating this more. What do you do with failing tests? Correct, you disable them. Or rather, you disable whatever appears to cause them to fail, which is the threading in this case. This change follows mostly the tile_example.cpp. The slice size uses a minimum of 64, which was suggested by the zimg author. Some of this commit is a bit inelegant and weird, such as recomputing the scale factor for every slice, or the way slice_h is managed. Too lazy to make this more elegant. zimg git had a regressio around active_region (which is needed by the slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the bug was never released, so just add a warning to the manpage.
* zimg: refactor (move around fields)wm42020-07-152-78/+106
| | | | | | | | The intention is to add slice-threading to the wrapper. For that purpose, move all zimg related state to a new struct mp_zimg_state. There is now an array of instances of this struct. The intention is to have one instance for each thread. As of this commit, this is hardcoded to 1 thread; the following commit extends this.
* osd_libass: set ScaledBorderAndShadowOleg Oshmyan2020-07-151-0/+1
| | | | | | | | | | | libass recently switched the default from 1 to 0 for compatibility with ASS scripts that rely on the historical/VSFilter default of 0. libass does attempt to detect and avoid breaking scripts that rely on the historic libass-only default of 1, but it doesn't cover tracks created directly through the API, so set the header explicitly. Fixes https://github.com/mpv-player/mpv/issues/7900.
* vo_gpu: hwdec_vaapi: handle lack of object size with AMD driversPhilip Langdale2020-07-141-0/+26
| | | | | | | | | | | | | It turns out that the AMD driver doesn't bother to set the size field in the descriptor for an exported VA surface. I guess they assume the caller can always use lseek() and don't bother. So, we need to use lseek() in these situations. Modified-by: Niklas Haas <git@haasn.xyz> Guarded this behind PL_API_VER >= 88 to prevent it from exploding on older libplacebo versions, where vaapi support does not yet work properly on AMD due to lack of DRM modifiers.
* vo_gpu: hwdec_vaapi: add support for DRM format modifiersNiklas Haas2020-07-141-2/+5
| | | | | This is required to get non-corrupted textures when importing vaapi planes on AMD drivers.
* ao/pulse: fix reporting of playing statesfan52020-07-121-2/+7
| | | | | | | When get_state() corks the stream after an underrun happens priv->playing is incorrectly reset to true, which can cause the player to miss the underrun entirely. Stop resetting priv->playing during corking (but not uncorking) to fix this.
* ao/pulse: flush stream on underrunsfan52020-07-121-1/+1
| | | | | | | | | | The underflow callback introduced in d27ad96 can be called when the buffer is still full, causing playback to never resume afterwards since get_state() reports free_samples == 0. Fix this by fully resetting on underrun, which flushes the stream and ensures free buffer space. fixes #7874
* cocoa-cb: fix unfs window size when toggling out of fullscreender richter2020-07-121-1/+3
| | | | | | | | | | we properly set the unfs window size on live resize end. due to a race condition in the fullscreen events, which is also a live resize, the unfs window size is incorrectly set to a fullscreen size. this happens when the end fs screen event triggers before the end of live resize one. this just adds a second condition to not be un fullscreen when updating the unfs window size.
* x11: add option to make window appear on a specific workspacewm42020-07-124-8/+24
| | | | | | | | | Mess this into the --geometry option, because I like to be irresponsible. I considered adding a separate option, but at least this allows me to defer the question how the hell this should work as property (geometry simply and inherently does not). Tested on IceWM only. Option equality test and string output not tested.
* demux_lavf: workaround reading gif from unseekable streamswm42020-07-093-1/+29
| | | | | | | FFmpeg, being the pile of trash as usual, recently broke this. Add our own trash hack to trashily workaround this shit. Fixes: #7893
* player: fix outdated commentwm42020-07-091-3/+1
|
* sws_utils: do not mutate src/dst parameterswm42020-07-081-24/+20
| | | | | | Probably did not cause any practical problems, but it sure seems unclean. sws_utils users might also rely on these fields being exactly the same as the actual input/output. It's better to avoid this.
* x11: remove terrible xdg-screensaver hackwm42020-07-084-48/+47
| | | | | | | | | | | | | | I'm tired of dealing with this frequent spawning of xdg-screensaver when debugging and what not. xdg-screensaver was never a serious tool anyway, it's more like some self-deprecating joke by FDO folks. This will affect X11 on GNOME and other DEs. I'm singling out GNOME though, because they are the ones actively sabotaging any sane technical solutions and community cooperation. I have been accused of taking it out on innocent GNOME users, while none of this will reach GNOME developers. Of course that is not the intention.
* client API: add software rendering APIwm42020-07-088-2/+315
| | | | | | | | | | | | | | | | | This can be used to make vo_libmpv render video to a memory buffer. It only adds a new backend API that takes memory surfaces. All the render API (such as frame rendering control and so on) is reused. I'm not quite convinced of the usefulness of this, and until now I always resisted providing something like this. It only seems to facilitate inefficient implementation. But whatever. Unfortunately, this duplicates the software rendering glue code yet again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more). But in theory, these could reuse this backend in the future, just like vo_gpu could reuse the render_gl API. Fixes: #7852
* path: fix broken exe-dir[/mpv] config locationsAvi Halachmi (:avih)2020-07-081-1/+1
| | | | | | | This is a regression since c3694f0, at least on Windows. Fixes #7889 Fixes #7881
* Warn if on GNOMEwm42020-07-071-0/+7
| | | | GNOME actively fights the standard we try to rely on.
* ci: add d3d11 to mingw buildsfan52020-07-012-19/+44
|
* vo_gpu: vulkan: add ability to disable eventsNiklas Haas2020-06-302-0/+10
| | | | | | | | | | | libplacebo exposes this feature already, because this particular type of bug is unusually common in practice. Simply make use of it, by exposing it as an option. Could probably also bump the libplacebo minimum version to get rid of the #if, but that would break debian oldoldstable or something. Fixes #7867.
* player: warn if both proper and compat. config directories existwm42020-06-251-2/+11
| | | | | No idea why there's logic to add them all to the search path, so "both" are used. In any case, this isn't something anyone should use.
* path: do not use old_home for win32 exe dirwm42020-06-253-1/+4
| | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works.
* path: switch back to using non-XDG config dir by defaultwm42020-06-252-30/+48
| | | | | | | | | | | | | | | | | | | | | XDG is stupid, so change back to the standard behavior. Unfortunately, most users will now have the XDG one, so we will still need to load this. (This is exactly the same problem as when XDG support was introduced, just the other way around). This should not affect any normal users. Hopefully I tested this well enough; my intention is not to torment miserable XDG fans; they can keep using their config dir if they want it. This changes behavior in two cases: - new users (now creates ~/.mpv/ instead of ~/.config/mpv/) - users which have both directories The latter case will behave subtly or obviously different, not sure. Just fix your shit. Extend the manpage with all the messy details, as far as I could reverse engineer them from the code.
* vo_gpu: fix typo in struct namesfan52020-06-241-1/+1
|
* manpage: --demuxer-seekable-cache is uselesswm42020-06-231-19/+18
| | | | | | | | | De-emphasize it, since a user should usually not use it. This _could_ be used to make the cache seekable with --cache=no, but it's better and more intuitive to use --cache=yes. As such, the only use of this is for debugging. I'm not quite sure if this should be removed entirely, but I still see some value in it (for example if you want the cache lookahead, but you're using a stream where cache seeking is somehow broken).
* ci: replace mingw build scriptssfan52020-06-222-28/+139
|
* vo_gpu: use highp float if available for GLESStephen Salerno2020-06-211-0/+5
| | | | | | Using mediump float on GLES causes problems with kernel resampling, PQ HDR, and possibly others. The issues are fixed by using highp, which is available when GL_FRAGMENT_PRECISION_HIGH is defined.
* vo_gpu: add better gamut clipping optionNiklas Haas2020-06-194-0/+21
| | | | | | See https://code.videolan.org/videolan/libplacebo/-/commit/d63eeb1ecc204 Enabled by default because I think it looks better. YMMV.
* vo_gpu: fix scaler/window validation to allow unsettingNiklas Haas2020-06-181-0/+4
| | | | | | | | | | --dscale= and --*scale-window= (i.e. an empty string) are respectively valid settings for their options (and, in fact, the defaults). This fixes the bug that it was impossible to reset e.g. tscale-window back to the default "unset" setting after setting it once. Credit goes to @CounterPillow for locating the cause of this bug.
* vo_x11: partially restore operation on bad endian systemswm42020-06-171-6/+22
| | | | | | | | | | | | | For testing in VMs I guess? This features a very broken hack that probably works. Though I didn't test the packed format case. Again, the mismatch is essentially due to big endian byte addresses decreasing as bit addresses increase, so you can't represent a bit position in a byte stream with a single address, which the mpv metadata does. OSD is broken because repack.c doesn't support big endian. You'll have to live with it.
* video: some concessions to big endian hostswm42020-06-171-8/+11
| | | | | | | | | | | | | | | | | | | | | | The recent changes to the image format metadata broke big endian, and that was intentional. Some things are inherent to little endian (like the idea to coalesce bit and byte offsets into a single bit offset), and they don't be fixed. But some obvious things can be fixed, such as marking LE vs. BE formats the right way around on BE hosts. The metadata is formally still in LE, except that if the LE/BE flag matches the host endian, the host endian can be used when accessing packed formats with bit shifts, or when computing byte aligned component byte offsets. The former may work because formats with LE/BE variants use the same bit offsets after byte swapping, the latter may work because little endian is the natural concept for addressing memory. But it will "subtly" fail to do the right thing in some cases, and code using this can't know, so have fun. Many things are broken, but this makes e.g. vo_gpu mostly work. My general opinion about BE computers is that you should get a better computer, you can get one for free from any garbage dump.
* test: update to new ffmpeg pixfmtswm42020-06-175-5/+25
| | | | | Mainly, X2RGB10BE is added. Add our own unpack test for this format. Also, swscale seems to have added support for GBRPF conversion.
* video: alias IMGFMT_RGB30 to AV_PIX_FMT_X2RGB10wm42020-06-171-0/+4
| | | | | | | IMGFMT_RGB30 was added first; FFmpeg added AV_PIX_FMT_X2RGB10 later. This is exactly the same, so treat them as such. For some reason, libswscale still seems to output incompatible data - not sure what this is about, but I'm not going to debug it.
* repack: handle endian in a more general waywm42020-06-171-6/+7
| | | | | | | | Instead of applying this only to "regular" formats, do it with all formats. For some reason, some repackers still have their own endian code. These could probably be removed, but whatever.
* img_format: fight ffmpeg pixdesc some morewm42020-06-171-28/+49
| | | | | | | | | | | | | | | | | | | | | This change attempts to fix detection of how endian swapping is to be performed. Details can be found in the code comments. It should not change anything, other than fixing handling of the X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and the component location metadata was discarded due to an internal consistency check. With this commit, it is handled correctly. At first I thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears to be correct. The problem with this format is that it's the first packed RGB format that requires bit shift to access, and where the endian word size is larger than the (rounded up) component size, all while pixdesc would "require" you to perform 3 memory accesses (instead of 1), and the code tries to reverse this. It appears that trying to use the pixdesc metadata is much, much more work than just duplicating it in a saner form. To be fair, most problems are with big endian, and the mpv internal format does not care much about endian _hosts_.
* audio: don't lock ao_control for pull mode driversKevin Mitchell2020-06-171-2/+7
| | | | | | | | | | | | | The pull mode APIs were previously required to have thread-safe ao_controls. However, locks were added in b83bdd1 for parity with push mode. This introduced deadlocks in ao_wasapi. Instead, only lock ao_control for the push mode APIs. fixes #7787 See also #7832, #7811. We'll wait for feedback to see if those should also be closed.
* vo_gpu: placebo: add fallback code for stride mismatchNiklas Haas2020-06-161-12/+52
| | | | | | | | | | | | | | | For cases in which the requirements of the GPU API prevent directly uploading a texture with a given stride, we need to fix the stride manually in host memory. This incurs an extra memcpy, but there's not much we can do about it. (Even in `ra_gl` land, the driver will just hide this memcpy from the user) Note: This code could be done better. It could only copy as many texels as needed, and it could pick a stride that's a multiple of `gpu->limits.align_tex_xfer_stride` for better performance. Patches welcome (tm) Fixes #7759
* vo_gpu: add BT.2390 tone-mappingref_whiteNiklas Haas2020-06-154-7/+61
| | | | | | | | | | | | Implementation copy/pasted from: https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f This brings mpv's tone mapping more in line with industry standard practices, for a hopefully more consistent result across the board. Note that we ignore the black point adjustment of the tone mapping entirely. In theory we could revisit this, if we ever make black point compensation part of the mpv rendering pipeline.
* vo_gpu: reinterpret SDR white levels based on ITU-R BT.2408Niklas Haas2020-06-154-9/+13
| | | | | | | | | | | | This standard says we should use a value of 203 nits instead of 100 for mapping between SDR and HDR. Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773 In particular, that commit also includes a test case to make sure the implementation doesn't break roundtrips. Relevant to #4248 and #7357.
* vo_gpu: move coherent specifier to the correct locationNiklas Haas2020-06-102-2/+2
| | | | | | | | | | glslang accepted this, perhaps erronneously, but mesa does not. It seems to be incorrect. A caveat is that this means *all* SSBOs are now coherent, but since we only use SSBOs for peak detection, that's a non-issue. (And besides, marking something as coherent when we don't perform any synchronization commands on it should be a no-op anyway) Fixes #7823
* player: make unpausing directly after seek work with --keep-open (again)wm42020-06-101-0/+3
| | | | | | | | | | | | Commit fcf0b80dc9dd3 fixed this the first time. Commit 85576f31a9cc2 "accidentally" removed this code again. The commit message justifying the removal is correct, except it doesn't take other side-effects of the state machine into account. I obviously didn't remember what exactly this was about. So add a comment explaining it this time. Just apply it again; the thing the latter commit fixed still works. Fixes: #7819
* audio: require certain AOs to set device_bufferwm42020-06-092-3/+3
| | | | | | | | | | AOs which use the "push" API must set this field now. Actually, this was sort of always required, but happened to work anyway. The future intention is to use device_buffer as the pre-buffer amount, which has to be available right before audio playback is started. "Pull" AOs really need this too conceptually, just that the API is underspecified. From what I can see, only ao_null did not do this yet.
* ao/pulse: properly set device_bufferNicolas F2020-06-071-0/+8
| | | | | | | | | Previously, device_buffer defaulted to 0 on pulse. This meant that commit baa7b5c would always wait with a timeout of 0, leading to high CPU usage for PulseAudio users. By setting device_buffer to the number of samples per channel that PulseAudio sets as its target, this commit fixes this behaviour.
* cocoa-cb: properly reset window isMoving state on title bar clicksder richter2020-06-061-0/+2
| | | | | | | | | since the title bar catches the mouse up and down events, the underlying events view doesn't reset the isMoving state and no mouse movements are signalled to the core. now we also reset the state in mouse up events on the title bar. Fixes #7807
* vo_gpu: fix display corruption with window screenshotswm42020-06-061-0/+1
| | | | | | | | | The "screenshot window" command (ctrl+s by default) somehow broke video colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused. I don't know the cause, but the rest of the code seems to imply gl_video_reset_surfaces() needs to be called manually to flush some caches, and it fixes the issue, so I assume there's no great mystery here.
* vo_gpu: mark peak detection buffer coherentNiklas Haas2020-06-061-1/+1
| | | | This is required for buffer memory barriers to actually work
* vo_gpu: make storage images/buffers as restrictNiklas Haas2020-06-061-2/+2
| | | | | This informs the GPU that we don't alias it with any other descriptors (which we don't).
* vulkan/wayland: fix another build breakageDaniel Bermond2020-06-051-1/+1
| | | | | | | | | | | | | | | Commit 07b0c18 introduced some build breakages. Some breakages were fixed on c1fc535 and a1adafe. This one is still remaining. This commit fixes the following build error: [153/521] Compiling video/out/vulkan/context_wayland.c ../video/out/vulkan/context_wayland.c:26:10: fatal error: video/out/wayland/presentation-time.h: No such file or directory 26 | #include "video/out/wayland/presentation-time.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Relevant to: #7802
* build: fix another breakagewm42020-06-041-1/+1
| | | | | | | The build was still broken. Feel free to look for a better maintainer if you don't like it. Fixes: #7802 (maybe now?)
* wayland: fix buildwm42020-06-042-3/+3
| | | | | | Broken by previous commit. I've split a commit incorrectly. Fixes: #7802
* build: change filenames of generated fileswm42020-06-0415-69/+54
| | | | Force them into a more consistent naming schema.
* audio: fix deadlock on drainingwm42020-06-041-1/+1
| | | | | | | | | | | The playback thread may obviously still fill the AO'S entire audio buffer, which means it unset p->draining, which makes no sense and broke ao_drain(). So just don't unset it here. Not sure if this really fixes this, it was hard to reproduce. Regression due to the recent changes. There are probably many more bugs like this. Stupid asynchronous nightmare state machine. Give me a language that supports formal verification (in presence of concurrency) or something.
* options: add --video-scale-x/ywm42020-06-034-4/+18
| | | | | | Requested. Fixes: #6303
* audio: adjust wait durationwm42020-06-031-6/+4
| | | | | | | | | | | | | | | I feel like this makes slightly more sense. At least it doesn't include the potentially arbitrary constant latency that is generally included in the delay value. Also, the buffer status doesn't matter - either we've filled the entire buffer (then we can wait this long), or there's not enough data anyway (then the core will wake up the thread if new data is available). But ultimately, we have to guess, unless the AO does notify us with ao_wakeup_playthread(). Draining may now wait for no reason up to 1/4th of the total buffer time. Shouldn't be a disimprovement in practice.
* vaapi: correct broken NULL checkwm42020-06-031-1/+1
| | | | | | | Clearly, we want to check whether vaGetDisplayDRM() returned NULL. out_display itself is already implied non-NULL. Fixes: #7739
* audio: avoid possible deadlock regression for some AOswm42020-06-021-2/+17
| | | | | | | | | | | | | | | It's conceivable that ao->driver->reset() will make the audio API wait for ao_read_data() (i.e. its audio callback) to return. Since we recently moved the reset() call inside the same lock that ao_read_data() acquires, this could deadlock. Whether this really happens depends on how exactly the AO behaves. For example, ao_wasapi does not have this problem. "Push" AOs are not affected either. Fix by moving it outside of the lock. Assume ao->driver->start() will not have this problem. Could affect ao_sdl, ao_coreaudio (and similar rotten fruit AOs). I'm unsure whether anyone experienced the problem in practice.
* audio: further simplify internal audio API somewhatwm42020-06-025-47/+41
| | | | | | | | | | | | Instead of the relatively subtle underflow handling, simply signal whether the stream is in a playing state. Should make it more robust. Should affect ao_alsa and ao_pulse only (and ao_openal, but it's broken). For ao_pulse, I'm just guessing. How the hell do you query whether a stream is playing? Who knows. Seems to work, judging from very superficial testing.
* audio: slightly better condition for still_playingwm42020-06-021-1/+1
| | | | | | Just a detail. If wrong (not unlikely because I'm just guessing my own messy state machine), this will make the player freeze due to waiting for something that never happens. Enjoy.
* af_scaletempo: handle obscure integer overflowwm42020-06-021-4/+4
| | | | | Saw it once, not really reproducible. This should fix it, and in any case it's harmless.
* TOOLS/autocrop.lua: automatically crop at startupヒカリ2020-06-011-84/+292
|
* audio: reduce extra wakeups caused by recent changeswm42020-06-011-5/+4
| | | | | | | | | | | | | | | | The feeder thread basically woke up the core and itself too often, and caused some CPU overhead. This was caused by the recent buffer.c changes. For one, do not let ao_read_data() wake up the core, and instead rely on the feeder thread's own buffer management. This is a bit strange, since the change intended to unify the buffer management, but being more consequent about it is better deferred to later, when the buffer management changes again anyway. And also, the "more" condition in the feeder thread seems outdated, or at least what made it make sense has been destroyed, so do something that may or may not be better. In any case, I'm still not getting underruns with ao_alsa, but the wakeup hammering is gone.
* vo: refine wakeup condition, and wake up more in audio sync modewm42020-06-011-3/+3
| | | | | | | | | | | Commit 6a13954d67143fb lowered the frequency of wakeups with this condition. But it seems it sometimes the audio sync mode really should get the wakeup before the frame is rendered. Normally, vo_thread is supposed to perform this wakeup. Now the wakeup frequency is twice of what should be needed - whatever, maybe it can be fixed properly once or if timing is moved to the VO entirely in the future. Fixes: #7777 (probably, untested)
* audio: redo internal AO APIwm42020-06-0120-823/+635
| | | | | | | | | | | | | | | | | | | | | | | | | This affects "pull" AOs only: ao_alsa, ao_pulse, ao_openal, ao_pcm, ao_lavc. There are changes to the other AOs too, but that's only about renaming ao_driver.resume to ao_driver.start. ao_openal is broken because I didn't manage to fix it, so it exits with an error message. If you want it, why don't _you_ put effort into it? I see no reason to waste my own precious lifetime over this (I realize the irony). ao_alsa loses the poll() mechanism, but it was mostly broken and didn't really do what it was supposed to. There doesn't seem to be anything in the ALSA API to watch the playback status without polling (unless you want to use raw UNIX signals). No idea if ao_pulse is correct, or whether it's subtly broken now. There is no documentation, so I can't tell what is correct, without reverse engineering the whole project. I recommend using ALSA. This was supposed to be just a simple fix, but somehow it expanded scope like a train wreck. Very high chance of regressions, but probably only for the AOs listed above. The rest you can figure out from reading the diff.
* audio: fix unpausing with some AOswm42020-05-311-1/+1
| | | | | | | | | wasapi/coreaudio/sdl were affected, alsa/pusle were not. The confusion here was that resume() has different meaning with pull and push AOs. Fixes: #7772
* terminal-win: handle 'Change Window Title' OSC sequenceJames Ross-Gowan2020-05-291-99/+131
| | | | | | | | | | | | | | | | | This should make --term-title work in Windows 8.1 and below. OSC sequences are defined in ECMA-48. The 'Change Window Title' command, as far as I can tell, is a de-facto standard defined by xterm[1]. In either case, this code is probably still not standards-compliant. This also changes mp_write_console_ansi to convert to UTF-16 before parsing control sequences, because that made it easier to pass the OSC param to SetConsoleTitleW. I think it's also more correct to do it this way, even though it doesn't really matter much for our limited terminal parsing. As a side-effect of this, mp_write_console_ansi no longer mutates its argument. [1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands
* ao_null: remove unreferenced functionwm42020-05-271-8/+0
| | | | Forgot in the previous commit to this file.
* audio: stop applying volume twice for some AOswm42020-05-271-1/+0
| | | | | | | Regression since the recent refactor. How did nobody notice? This happened because the push code now calls the function for the pull code. Both the former and latter apply the volume, so oops.
* audio: remove ao_driver.drainwm42020-05-277-48/+12
| | | | | | | | | | The recent change to the common code removed all calls to ->drain. It's currently emulated via a timed sleep and polling ao_eof_reached(). That is actually fallback code for AOs which lacked draining. I could just readd the drain call, but it was a bad idea anyway. My plan to handle this better is to require the AO to signal a underrun, even if AOPLAY_FINAL_CHUNK is not set. Also reinstate not possibly waiting for ao_lavc.c. ao_pcm.c did not have anything to handle this; whatever.
* lua: windows got what users cravewm42020-05-271-0/+3
| | | | | | It's got '\r's. Fixes: #7733
* player: add --term-title optionwm42020-05-257-0/+39
| | | | | | | | | | | | | | This simply printf()s a concatenation of the provided string and the relevant escape sequences. No idea what exactly defines this escape sequence (is it just a xterm thing that is now supported relatively widely?), and this simply uses information provided on the linked github issue. Not much of an advantage over --term-status-msg, though at least this can have a lower update frequency. Also I may consider setting a default value, and then it shouldn't conflict with the status message. Fixes: #1725
* audio: merge pull/push ring buffer glue codewm42020-05-256-1006/+762
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is preparation to further cleanups (and eventually actual improvements) of the audio output code. AOs are split into two classes: pull and push. Pull AOs let an audio callback of the native audio API read from a ring buffer. Push AOs expose a function that works similar to write(), and for which we start a "feeder" thread. It seems making this split was beneficial, because of the different data flow, and emulating the one or other in the AOs directly would have created code duplication (all the "pull" AOs had their own ring buffer implementation before it was cleaned up). Unfortunately, both types had completely separate implementations (in pull.c and push.c). The idea was that little can be shared anyway. But that's very annoying now, because I want to change the API between AO and player. This commit attempts to merge them. I've moved everything from push.c to pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to reconcile the differences. It's a mess, but at least there's only one ring buffer within the AO code now. Everything should work mostly the same. Pull AOs now always copy the audio data under a lock; before this commit, all ring buffer access was lock-free (except for the decoder wakeup callback, which acquired a mutex). In theory, this is "bad", and people obsessed with lock-free stuff will hate me, but in practice probably won't matter. The planned change will probably remove this copying-under-lock again, but who knows when this will happen. One change for the push AOs now makes it drop audio, where before only a warning was logged. This is only in case of AOs or drivers which exhibit unexpected (and now unsupported) behavior. This is a risky change. Although it's completely trivial conceptually, there are too many special cases. In addition, I barely tested it, and I've messed with it in a half-motivated state over a longer time, barely making any progress, and finishing it under a rush when I already should have been asleep. Most things seem to work, and I made superficial tests with alsa, sdl, and encode mode. This should cover most things, but there are a lot of tricky things that received no coverage. All this text means you should be prepared to roll back to an older commit and report your problem.
* audio: add frame alloc functionwm42020-05-252-0/+14
| | | | Meh, why is this so roundabout?
* CI: add FreeBSD jobJan Beich2020-05-252-0/+63
|
* osdep: remove confstr() fallback for subprocess spawningsfan52020-05-251-7/+2
| | | | | It doesn't exist on bionic (Android) and accurately emulating execvpe's behaviour isn't all that important.
* x11_common: added ICCCM WM_HINTSArthur Williams2020-05-241-0/+11
| | | | | | | | | | | | | | | | | | When the window is mapped, some ICCCM WM_HINTS are set. The input field is set to true and state is set to NormalState. To quote the spec, "The input field is used to communicate to the window manager the input focus model used by the client" and "[c]lients with the Passive and Locally Active models should set the input flag to True". mpv falls under the Passive Input model, since it expects keyboard input, but only listens for key events on its single, top-level window instead of subordinate windows (Locally Active) or the root window (Globally Active). From the end users prospective, all EWMH/ICCCM compliant WMs (especially the minimalistic ones) will allow the user to focus mpv, which will allow mpv to receive key events. If the input field is not set, WMs are allowed to assume that mpv doesn't require focus.
* manpage: document "vf remove"wm42020-05-231-1/+4
| | | | And mention it on "vf del" as non-deprecated alternative.
* player: remove some display-adrop leftoverswm42020-05-237-24/+3
| | | | | Forgotten in one of the previous commits. Also undeprecates display-adrop since it's out of sight now.
* command: fix dump-cache parameter parsingwm42020-05-231-2/+4
| | | | | | Commit 9d32d62b615 broke this when it changed OPT_TIME. I simply forgot to adjust the command definition. The effect was that "no" was not accepted as value.
* README: remove trollingwm42020-05-231-4/+0
| | | | | | | | | | | | | | | | | | I guess this qualifies as trolling. It's becoming increasingly clear that Microsoft will not be able to deliver on this promise, at least not in the way they made it seem at first. I'm not sure if Microsoft was the one who did the trolling, or me. I actually expected that we'd get full GUI integration of Linux applications including accelerated graphics, but it was always clear that it wasn't going to work as well as natively. In any case, there is no need to frighten any users. The time when you can run only "Windows Store Apps" on Windows (== the end for mpv and many other applications on Windows) will come soon enough. The "faster than native" statement is based on other people's real experience of software running faster in Linux VMs than native windows ports, by the way.
* audio: redo video-sync=display-adropwm42020-05-2312-56/+192
| | | | | | | | | | | | | | | | | This mode drops or repeats audio data to adapt to video speed, instead of resampling it or such. It was added to deal with SPDIF. The implementation was part of fill_audio_out_buffers() - the entire function is something whose complexity exploded in my face, and which I want to clean up, and this is hopefully a first step. Put it in a filter, and mess with the shitty glue code. It's all sort of roundabout and illogical, but that can be rectified later. The important part is that it works much like the resample or scaletempo filters. For PCM audio, this does not work on samples anymore. This makes it much worse. But for PCM you can use saner mechanisms that sound better. Also, something about PTS tracking is wrong. But not wasting more time on this.
* af_scaletempo: fix theoretical UBwm42020-05-231-1/+2
| | | | | Passing NULL to memset() is undefined behavior, even if the size argument is 0. Could happen on init errors and such.
* options: add option to control display-sync factorwm42020-05-234-3/+18
| | | | | | | | Can be useful to force it to adapt to extreme speed changes, while a higher limit would just use a fraction closer to the original video speed. Probably useful for testing only.
* vo_x11: allow OSD rendering outside of video regionwm42020-05-221-65/+52
| | | | | | | | | | | | | | | | | | | | | | | | I'm not sure why it only rendered OSD inside the video. Since OSD rendering was always done on the X image (after software scaling and color conversion), there was no technical reason for this. Maybe it was because the code started out this way, and it was annoying to change it. Possibly, one reason was that it didn't normally have to clear the black bars in every frame (if video didn't cover the entire window). Anyway, simply render OSD to the full window. This gets rid of some rather weird stuff. It seems to look mostly like vo_wlshm now. The uncovered regions are cleared every frame, which could probably be avoided by being clever with the OSD renderer code, but this is where I'm decidedly losing interest. There was some mysterious code for aligning the image width to 8 pixels. Replace that by attempting to align it to SIMD alignment (might matter for libswscale, or if repack.c gets SIMD). Why are there apparently 4 different ways representing a pixel format (depth, VisualID, Visual, XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel value (the actual size of a pixel, including padding)? Even after 33 years, X11 still seems overengineered, confusing, and inconvenient. So just call X11 a heap of shit, and assume the worst case for alignment.
* mp_image: add helper for clearing regions outside of a rectanglewm42020-05-222-0/+16
| | | | Not sure if generally useful; the following commit uses it.
* common: add helper for subtracting rectangleswm42020-05-222-0/+24
| | | | Not sure if generally useful; the following commit uses it.
* video: add AV_PIX_FMT_UYYVYY411 conversion supportwm42020-05-224-34/+60
| | | | | | | | | | It may be completely useless, and I can't verify it as no known samples or other known/accessible software using it, but why not? Putting this together with he 422 code requires making it slightly more generic. I'm still staying with a "huge" if tree instead of a table to select the scanline worker callback, because it's actually small and not huge (although it not being generic still feels slightly painful).
* repack: use new imgfmt metadata in more caseswm42020-05-211-74/+59
| | | | | | Now everything is super generic and super undebuggable. Some awkwardness because the new metadata is basically a transposed version of the mp_regular_imgfmt metadata, which was used for component info before.
* img_format: expose another helperwm42020-05-212-2/+6
|
* mp_image: reimplement mp_image_clear()wm42020-05-211-25/+104
| | | | | | | | | | | | The old code ignored many corner cases, and even wrote "blacker than black" to YUV images. Use the new pixel format metadata and other recently added gimmicky crap, which should make this more correct. Even the almighty fuckup of a format AV_PIX_FMT_UYYVYY411 should work, although that couldn't be tested for obvious reasons. This doesn't work for "monow", but this is so extremely fringe while at the same time painful that I just won't care. In theory, it could be modeled as some sort of inverted gray colorspace or something.
* video: remove useless mp_imgfmt_desc.avformat fieldwm42020-05-203-5/+2
| | | | Had 1 user; easily replaced.
* vo_x11: minor improvement in format matchingwm42020-05-201-5/+5
| | | | | | | | | Make sure to accept only native endian mpv formats. Previously, it didn't check, and simply matched LE, because these are usually defined before the BE formats. red_mask etc. are defined as unsigned long, so use that instead of hardcoding a 32 bit limit.
* video: clean up pixel metadata stuff some morewm42020-05-204-509/+545
| | | | | | | | | | | | | | | A repeat of the previous useless commits. Pondered whether to use separate fields or just a flags integer for color and component types; the latter won for now. Functions like mp_imgfmt_get_component_type() are now discouraged, and mp_imgfmt_desc.flags is back for defining all information. Some days ago I felt like the opposite would be the better design. Fortunately, it doesn't matter. With this, I think all image format properties that mpv needs are exhaustively defined all in one place.
* command: save state on stop when user requested save-position-on-quitMikhail Rudenko2020-05-201-0/+7
| | | | | | | | Execution of "stop" command in the case when idle mode was not enabled resulted in player termination scenario not honoring user setting "save-position-on-quit" from config file. This patch addresses the issue by checking for "save-position-on-quit" in cmd_stop and saving state when idle mode is not enabled.
* vo_x11: use imgfmt metadata instead of hardcoded format tablewm42020-05-201-32/+21
| | | | | | Useless, but super generic! Actually may add support for other fringe formats, however vo_x11 in itself is useless, so nothing won here. Also I didn't bother with big endian support.
* video: shuffle imgfmt metadata code aroundwm42020-05-205-278/+265
| | | | | | | | | | | | | | | | | I guess I decided to stuff it all into mp_imgfmt_desc (the "old" struct). This is probably a mistake. At first I was afraid that this struct would get too fat (probably justified, and hereby happened), but on the other hand mp_imgfmt_get_desc() (which builds the struct) calls the former mp_imgfmt_get_layout(), and the separation doesn't make too much sense anyway. Just merge them. Still, try to keep out the extra info for packed YUV bullshit. I think the result is OK, and there's as much information as there was before. The test output changes a little. There's no independent bits[] array anymore, so formats which did not previously have set this now show it. (These formats are mpv-only and are still missing the metadata. To be added later). Also, the output for the cursed packed formats changes.
* README: looks like we won't need win32 support anymorewm42020-05-191-0/+3
|
* repack: make generic weird pixfmt shit even more generic and obfuscatedwm42020-05-181-54/+20
| | | | | | | | | | | | | | Use the new pixfmt metadata to replace the format tables with weird generic code. As you can see, this removes the tables that essentially duplicate information (which is baaaaaaaaaad), in exchange for code which is probably more fragile and has less of a chance of being understood by someone new to the code (which is probably even worse from a maintenance and robustness point of view, but LALALA I CAN'T HEAR YOU). There are some more formats which can be handled like this (RGB30 and packed YUV I guess), maybe later.
* video: fix AV_PIX_FMT_UYYVYY411 allocationwm42020-05-182-3/+2
| | | | | | | My previous commit added support for this format, but it was still broken, and prevented the allocation code from working. It's unknown whether it's correct now (because this pixfmt is so obscure and useless, there are no known samples around), but who cares.
* wayland: only use presentation on CLOCK_MONOTONICDudemanguy2020-05-181-2/+2
| | | | | | | Trying to use anything other than CLOCK_MONOTONIC here would be a disaster. No idea if it's even possible for the clockid here to be something other than CLOCK_MONOTONIC in this function but it's better safe than sorry. Closes #7740.
* build: allow wlshm on more Wayland platforms after a6000d311421Jan Beich2020-05-181-6/+6
|
* video: add pixel component location metadatawm42020-05-184-130/+875
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought I'd probably want something like this, so the hardcoded stuff in repack.c can be removed eventually. Of course this has no purpose at all, and will not have any. (For now, this provides only metadata, and nothing uses it, apart from the "test" that dumps it as text.) This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite, because the format is 100% useless). Support for some mpv-only formats is missing, ironically. The code goes through _lengths_ to try to make sense out of the FFmpeg AVPixFmtDescriptor data. Which is even more amazing that the new metadata basically mirrors pixdesc, and just adds to it. Considering code complexity and speed issues (it takes time to crunch through all this shit all the time), and especially the fact that pixdesc is very _incomplete_, it would probably better to have our own table to all formats. But then we'd not scramble every time FFmpeg adds a new format, which would be annoying. On the other hand, by using pixdesc, we get the excitement to see whether this code will work, or break everything in catastrophic ways. The data structure still sucks a lot. Maybe I'll redo it again. The text dump is weirdly differently formatted than the C struct - because I'm not happy with the representation. Maybe I'll redo it all over again. In summary: this commit does nothing.
* video: clean up some imgfmt related stuffwm42020-05-1815-756/+747
| | | | | | | | | | | | | | | | Remove the vaguely defined plane_bits and component_bits fields from struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove the bytes[] field, replace uses with bpp[]. Fix some potential alignment issues in existing code. As a compromise, split mp_image_pixel_ptr() into 2 functions, because I think it's a bad idea to implicitly round, but for some callers being slightly less strict is convenient. This shouldn't really change anything. In fact, it's a 100% useless change. I'm just cleaning up what I started almost 8 years ago (see commit 00653a3eb052). With this I've decided to keep mp_imgfmt_desc, just removing the weird parts, and keeping the saner parts.
* test: explicitly test repacking for all packed RGB variantswm42020-05-182-36/+117
| | | | This stuff is very annoying, so it's good to have full coverage.
* stats: UP/DOWN scrolling on page 2 (frame stats)Julian2020-05-172-3/+25
| | | | | | Code contributed by @avih with only minor modifications to comments by me. Fixes #7727.
* vo_wlshm, vo_drm: set image size with mp_image_set_sizeMichael Forney2020-05-172-4/+2
| | | | | | | | | | The image w and h members must match params.w and params.h, so should not be changed directly. The helper function mp_image_set_size is designed for this purpose, so just use that instead. This prevents an assertion error with the rewritten draw_bmp. Fixes #7721.
* zsh completion: helper functions in private namespaceEd Santiago2020-05-171-6/+6
| | | | | | | | | | | The generate_xxx() helpers, once defined, would appear as user-visible functions; this would lead to unexpected and confusing completion suggestions for gene<tab> after having once run mpv in that shell. This PR adds the prefix '_mpv_' to all completion functions as a convention to make them less user-visible and less likely to collide with other packages.
* osc: fix hovering timestamp sticking around when moving mouse awaywm42020-05-161-3/+11
| | | | | | | | | | | | | | The OSC calls this "tooltip" (and although a general mechanism, there's only one instance using it). One particular problem was that with the default OSC layout, moving the mouse down and out of the window, the tooltip stuck around, because the returned mouse position was the last pixel row in the window, which still overlaps with the seek bar. Instead of introducing mouse_in_window, you could check last_mouse_X for nil, but I think this is clearer. This returns (-1, -1) to the caller if the mouse is outside. Kind of random, but works.
* vo_gpu: ra_pl: add timers supportNiklas Haas2020-05-161-0/+95
| | | | | | | | | | | | | | | Added in libplacebo v60, unfortunately with some changes in design that make it a bit of an awkward fit for the way timers are used in mpv. Timer queries in libplacebo don't support "start" and "stop"-style operations, and instead are attached directly to operations. The only sane way of implementing this in the ra API is to have a single 'active timer' that gets attached to every pass, taking care to sort distinct operations into distinct pl_timer queries within that ra_timer. This design unfortunately doesn't let us have multiple 'active timers' concurrently, similar to the current such limitation in ra_gl. But it's also not a big deal.
* scripting: make socket FD number for subprocesses dynamicwm42020-05-152-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | Before this, we pretty much guaranteed that --mpv-ipc-fd=3 would be passed. The FD was hardcoded, so scripts started by this mechanism didn't need to actually parse the argument. Change this to using a mostly random FD number instead. I decided to do this because posix_spawnp() and the current replacement cannot "guarantee" a FD layout. posix_spawn_file_actions_adddup2() just runs dup2() calls, so it may be hard to set FD 3/4 if they are already used by something else. For example imagine trying to map: {.fd = 3, .src_fd = 4}, {.fd = 4, .src_fd = 3}, Then it'd do dup2(4, 3), dup2(3, 4) (reminder: dup2(src, dst)), and the end result is that FD 4 really maps to the original FD 4. While this was not a problem in the present code, it's too messy that I don't want to pretend it can always done this way without an unholy mess. So my assumption is that FDs 0-2 can be freely assigned because they're never closed (probably...), while for all other FDs only pass-through is reasonable.
* sub: fix incorrect commitwm42020-05-151-3/+1
| | | | Commit c6369933f1d9cd accidentally added an old version of this comment.
* ipc: mark client sockets as CLOEXECwm42020-05-151-0/+2
| | | | | I suppose it would have left the socket open if the client closed its FD.
* scripting: correct passing FDswm42020-05-151-1/+1
| | | | | For external scripts/processes which use IPC. The mistake didn't really matter.
* osdep: remove posix_spawn() helpers and wrapperswm42020-05-156-163/+2
| | | | See previous commit. Farewell, useless shitty POSIX function.
* subprocess: replace posix_spawnp() with fork()wm42020-05-151-17/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code runs posix_spawnp() within a fork() in some cases, in order to "disown" processes which are meant as being started detached. But posix_spawnp() is not marked as async-signal-safe, so what we do is not allowed. It could for example cause deadlocks, depending on implementation and luck at runtime. Turns out posix_spawnp() is useless crap. Replace it with "classic" fork() to ensure correctness. We could probably use another mechanism to start a process "disowned" than doing a double-fork(). The only problem with "disowning" a process is calling setsid() (which posix_spawnp() didn't support, but maybe will in newer revisions), and removing as as parent from the child process (the double-fork() will make PID 1 the parent). But there is no good way to either remove us as parent, or to "reap" the PID in a way that is safe and less of a mess than the current code. This is because POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives" like win32, no doubt.) Because POSIX/UNIX is a miserable heap of shit, execvp() is also not specified as async-signal-safe. It's funny how you can run a full fledged HTTP server in an async-signal-safe context, but not start a shitty damn process. Unix is really, really, really extremely bad at this process management stuff. So we reimplement execvp() in an async-signal-safe way. The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at different times, but both must be present. io.h defines them to 0 if they don't exist, and in this case the code will error out at runtime. Surely we could do without CLOEXEC via fallback, but I'll do that only if at least 1 bug is reported wrt. this issue. The idea how to report exec() failure or success is from musl. The way as_execvpe() is also inspired by musl (for example, the list of error codes that should make it fail is the same as in musl's code).
* command: add input-key-list propertywm42020-05-144-0/+29
| | | | Fixes: #7698
* command: add property to return text subtitles in ASSwm42020-05-147-18/+62
| | | | | | | | | See manpage additions. This was requested, sort of. Although what has been requested might be something completely different. So this is speculative. This also changes sub_get_text() to return an allocated copy, because the buffer shit was too damn messy.
* ipc: exit client if the FD is invalidwm42020-05-141-1/+1
| | | | | | | This does not normally happen. But since the --input-ipc-client option can pass in raw FDs, it's probably a good thing in the interest of making mistakes obvious. Without this, it just burned a core on invalid FDs (poll() always returned immediately).
* ipc: make --input-ipc-client terminate player on connection closewm42020-05-142-1/+11
| | | | | | | | As discussed in the referenced issue. This is quite a behavior change, bit since this option is new, and not included in any releases yet, I think it's OK. Fixes: #7648
* vo_x11: add 10 bit supportwm42020-05-141-0/+3
| | | | Requires zimg.
* build: link against single EGL providerJan Palus2020-05-142-11/+37
| | | | | when building with rpi EGL is provided by librcmegl library and libEGL should not be linked then
* build: fallback to default pc file locations on rpiJan Palus2020-05-142-3/+10
|
* drm: add typedef for PFNEGLGETPLATFORMDISPLAYEXTPROC (#7314)Jan Palus2020-05-141-0/+5
| | | | extension is not mandatory and is not provided on ie Raspberry Pi
* vo_direct3d: dumb down OSD renderingwm42020-05-131-164/+92
| | | | | | | | | | | | | | Render most of the OSD on the CPU, then draw it using a relatively simple method. Do this for minimum code maintenance overhead. (While it doesn't matter for vo_direct3d, and the effort spent here is probably more than this would ever hope, I do hope to simplify the internal OSD API for all these fringe VOs. Only vo_gpu should be allowed to do more sophisticated things.) If your GPU is shit (which it will be if you "want" to use vo_direct3d), this might actually improve performance... is what I'd say, but out of laziness a full screen sized texture gets uploaded on every OSD/subtitle change, so maybe not.
* draw_bmp: make another small guarantee to userswm42020-05-131-0/+2
| | | | Mostly self-evident.
* vo_direct3d: rip out texture video rendering pathwm42020-05-135-660/+67
| | | | | | | | | | | | | This isn't useful anymore. We have a much better d3d11 renderer in vo_gpu. D3D11 is available in all supported Windows versions. The StretchRect path might still be useful for someone (???), and leaving it at least evades conflict about users who want to keep using this VO for inexplicable reasons. (Low power usage might be a justified reason, but still, no.) Also fuck the win32 platform, it's a heap of stinky shit. Microsoft is some sort of psycho clown software company. Granted, maybe still better than much of the rest of Silly Con Valley.
* draw_bmp: use command line options for any used scalerswm42020-05-135-16/+36
|
* vo_gpu: un-fix storable fbo format checkNiklas Haas2020-05-131-2/+1
| | | | | | | | | The original solution for #7017 was sort of a hack, but this hack is no longer needed because c05e5d9d fixed the underlying issue causing this error to be spammed in the first place. So just remove the "fix" that apparently introduced about as many issueas it fixed. Fixes #7719, hopefully.
* draw_bmp: add integer blending for 8 bit formatswm42020-05-122-41/+79
| | | | | | | | Whatever it's worth. Instead of doing a pretty stupid conversion to float, just blend it directly. This works for most RGB formats that are 8 bits per component or below (the latter because we expand packed fringe RGB formats for simplicity). For higher bit depth RGB this would need extra code.
* repack: fix incorrect assert()wm42020-05-121-1/+1
| | | | | Used the output of the first step instead of the input when checking the real input.
* draw_bmp: don't make strange decisions on broken iknput csp paramswm42020-05-123-64/+66
| | | | | | | | | | | | This checked params->color.space for being RGB. If the colorspace is unset, this did dumb things because even if the imgfmt was a RGB one, the colorspace was not set to RGB. This actually also happened to the tests. (Short-cutting RGB like this is actually wrong, since RGB could still have strange gamma or primaries, which would warrant a full conversion. So you'd need to check for these other parameters as well. To be fixed later.)
* vo_vaapi: use new overlay APIwm42020-05-111-123/+85
| | | | | | | | | | | | | This will probably make it slower. But since I don't care about vo_vaapi, that's perfectly OK. It serves mostly as a test for the previous commit. In addition, this code was pretty bad (custom broken scaling and not-blending that probably broke in some situation). If that wasn't enough, some vaapi drivers also provide only a single overlay at a time, while this code required a bunch. There also seems to be a Mesa bug: the overlay gets stretched when src_x/y was not 0. Or maybe I misunderstood how this is supposed to work. A bug is probably more likely? Nobody cares about this API.
* draw_bmp: add a function to return a single-texture OSD overlaywm42020-05-114-50/+265
| | | | | | | | | | | | | | Maybe this is useful for some of the lesser VOs. It's preferable over bad ad-hoc solutions based on the more complex sub_bitmap data structures (as observed e.g. in vo_vaapi.c), and does not use that much more code since draw_bmp already created such an overlay internally. But I still wanted something that avoids having to upload/render a full screen-sized overlay if for example there's only a tiny subtitle line on the bottom of the screen. So the new API can return a list of modified pixels (for upload) and non-transparent pixels (for display). The way these pixel rectangles are computed is a bit dumb and returns dumb results, but it should be usable, and the implementation can change.
* video: remove RGB32/BGR32 aliaseswm42020-05-115-18/+9
| | | | | | | They are sort of confusing, and they hide the fact that they have an alpha component. Using the actual formats directly is no problem, sicne these were useful only for big endian systems, something we can't test anyway.
* js: mp.set_osd_ass: ignore identical inputs (match ccbb8b1c)Avi Halachmi (:avih)2020-05-101-0/+5
|
* vo: fix forgotten debug codewm42020-05-101-1/+1
| | | | | | | This was not intended to be committed in 0e3f8936062967a9db. It disables the extra wakeup if working==true. I've convinced myself that the wakeup was really needed at the time, so no idea how I didn't notice this until someone pointed it out on the commit diff on github (lol).
* lua: do not use Lua filesystem functions for loading scriptswm42020-05-101-3/+6
| | | | | | | | | | | Bill Gates did not only create COVID, he's also responsible for the world's worst OS, where you have to literally jump through hoops of fire to open files with Unicode file names. Lua did not care to implement any jumping, so it's our turn to jump. Untested (on win32). Fixes: #7701
* stream: make stream_read_file() more robustwm42020-05-103-23/+41
| | | | | | | | | Change it to strictly accept local paths only. No more http://, no more $HOME expansion with "~/" or mpv config path expansion with "~~/". This should behave as if passing a path directly to open(). Reduce annoying log noise to further facilitate it using as open() replacement.
* msg: add function to reduce log levelwm42020-05-102-2/+19
| | | | | | | | | | Sometimes it's helpful to override this for specific mp_log instances, because in some specific circumstances you just want to suppress log file noise you never want to see. -1 is an allowed value (for suppressing MSGL_FATAL==0). It looks like the libplacebo wrapper still does this wrong, so it will probably trigger UB in some cases. I guess I don't care, though.
* vo_gpu: manually resolve user shader prefixeswm42020-05-101-1/+4
| | | | | | | | This resolves prefixes such as "~/" and "~~/" at the caller, instead of relying on stream_read_file() to do it. One of the following commits will remove this from stream_read_file() itself. Untested.
* player: make external subtitle auto-loading stricterwm42020-05-092-25/+41
| | | | | | | | | | | | | | | | | | | | | | | | | By default --sub-auto uses "exact". This was far from an "exact" match, because it added anything that started with the video filename (without extension), and seemed to end in something that looked like a language code. Make this stricter. "exact" still tolerate a language code, but the video's filename must come before it without any unknown extra characters. This may not load subtitles in some situations where it previously did, and where the user might think that the naming convention is such that it should be considered an exact match. The subtitle priority sorting seems a bit worthless. I suppose it may have some value in higher "fuzz" modes (like --sub-auto=fuzzy). Also remove the mysterious "prio += prio;" line. I probably shouldn't have checked, but it goes back to commit f16fa9d31 (2003), where someone wanted to "refine" the priority without changing the rest of the code or something. Mostly untested, so have fun. Fixes: #7702
* options: update OSD when writing some OSD-related optionswm42020-05-091-9/+9
| | | | | | Just the usual change notification mess. Fixes: #7697
* vo: another minor wakeup reductionwm42020-05-091-5/+10
| | | | | | The caller of render_frame() re-iterates without waiting if this function returns true. That's normally meant for DS, where we draw frames as fast as possible to let the driver perform waiting.
* vo: always reset redraw flag to avoid immediate wakeups wasting CPU timewm42020-05-091-1/+2
| | | | | | | This could temporarily hog the core or something because it's a stupid fragile state machine that should best be wiped out. Fixes: #7699
* draw_bmp: rewritewm42020-05-096-411/+938
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This changes the algorithm from upsampling the video to 4:4:4 and then blending to downsampling the OSD and then blending directly to video. This has far-reaching consequences for its internals, and results in an effective rewrite. Since I wanted to avoid un-premultiplying, all blending is done with premultiplied alpha. That's actually the sane thing to do. The old code just didn't do it, because it's very weird in YUV fixed point. Essentially, you'd have to compensate for the chroma centering constant by subtracting src_alpha/255*128. This seemed so hairy (especially with correct rounding and high bit depths involved) that I went for using float. I think it turned out mostly OK, although it's more complex and less maintainable than before. reinit() is certainly a bit too long. While it should be possible to optimize the RGB path more (for example by blending directly instead of doing the stupid float conversion), this is probably slower. vo_xv users probably lose in this, because it takes the slowest path (due to subsampling requirements and using YUV). Why this rewrite? Nobody knows. I simply forgot the reason. But you'll have it anyway. Whether or not this would have required a full rewrite, at least it supports target alpha now (you can for example hard sub transparent PNGs, if you ever wanted to use mpv for this). Remove the check in vf_sub. The new draw_bmp.c is not as reliant on libswscale anymore (mostly uses repack.c now), and osd.c shows an error message on missing support instead now. Formats with chroma subsampling of 4 are not supported, because FFmpeg doesn't provide pixfmt definitions for alpha variants. We could provide those ourselves (relatively trivial), but why bother.
* repack: add support for converting from/to float formatswm42020-05-094-3/+402
| | | | | Will be needed by draw_bmp.c. The tests cross-check this with zimg to control whether we're getting it right.
* csputils: add function for getting uint/float transformationwm42020-05-092-1/+44
| | | | | | | | | | | | | | This provides a way to convert YUV in fixed point (or pseudo-fixed point; probably best to say "uint") to float, or rather coefficients to perform such a conversion. Things like colorspace conversion is out of scope, so this is simple and strictly per-component. This is somewhat similar to mp_get_csp_mul(), but includes proper color range expansion and correct chroma centering. The old function even seems to have a bug, and assumes something about shifted range for full range YCbCr, which is wrong. vo_gpu should probably use the new function eventually.
* video: add yuv float formatswm42020-05-095-11/+181
| | | | | | | | | | | Adding all these so I can use them for obscure processing purposes (see later draw_bmp commit). There isn't really a reason why they should exist. On the other hand, they're just labels for formats that can be handled in a generic way, and this commit adds support for them in the zimg wrapper and vo_gpu just by making the formats exist. (Well, vo_gpu had to be fixed in the previous commit.)
* vo_gpu: fix green shit with float yuv inputwm42020-05-095-12/+28
| | | | | | | | | | | | This was incorrect at least because the colorspace matrix attempted to center chroma at (conceptually) 0.5, instead of 0. Also, it tried to apply the fixed point shift logic for component sizes > 8 bit. There is no float yuv format in mpv/ffmpeg yet, but see next commit, which enables zimg to output it. I'm assuming zimg defines this format such that luma is in range [0,1] and chroma in range [-0.5,0.5], with the levels flag being ignored. This is consistent with H264/5 Annex E (I think...), and it sort of seems to look right, so that's it.
* video: fix rgb30 component orderwm42020-05-095-5/+8
| | | | | | | | | Was broken with a zimg wrapper refucktor before the previous commit. In addition, it seems this didn't match the vo_drm format, or the format naming convention. So the order actually changes, and the format is redefined. (The img_format.h comment was probably wrong.) Change vo_gpu to the new format as well, so we can still test it.
* video: separate repacking code from zimg and make it independentwm42020-05-099-895/+1688
| | | | | | | | | | | | | For whatever purpose. If anything, this makes the zimg wrapper cleaner. The added tests are not particular exhaustive, but nice to have. This also makes the scale_zimg.c test pretty useless, because it only tests repacking (going through the zimg wrapper). In theory, the repack_tests things could also be used on scalers, but I guess it doesn't matter. Some things are added over the previous zimg wrapper code. For example, some fringe formats can now be expanded to 8 bit per component for convenience.
* sws_utils: allow setting zimg options directlywm42020-05-094-8/+18
| | | | One could wonder, why not just use the zimg wrapper directly?
* img_format: make component order in comment more logicalwm42020-05-091-1/+1
|
* sd_lavc: fix occasional problems with certain VOs when changing scalingwm42020-05-091-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | The OSD is passed to VOs via struct sub_bitmaps, which has a change_id field. This field is incremented whenever there is a (potential) change to the other struct contents. If not, the VO can rely on it not having changed. This must include for example sub_bitmap.x and sub_bitmap.dw. If these two fields (and y equivalents) change, change_id must change, even if the subtitle bitmap data might still be the same. sd_lavc.c stopped respecting this at some unknown point. It could sometimes cause problems, though usually only with bad and old VOs which somehow relied on this more than vo_gpu. (I've actually encountered this before with sd_lavc subtitle scaling, as indicated by a nasty comment, though probably didn't track this down, since said old VOs can die in a fire.) Fix this by maintaining the change_id explicitly. Unfortunately adds even more code. Instead of comparing the result we could track property changes, but I think this is better. The number of parts is always very low with this subtitle decoder, so there's no actual performance issue to worry about. This could be triggered by scaling changes (video-zoom etc.), but probably also changing bitmap subtitle position or scaling.
* osd: add change timestamp and screen size to struct sub_bitmap_listwm42020-05-093-1/+23
| | | | | | | | Should be somewhat helpful. (All VOs are full of code trying to compensate for this, more or less, and this will allow simplifying some code later. Maybe.) The screen size is mostly for robustness checks.
* osd: add subtitle software blending to statswm42020-05-091-0/+4
|
* build: add -fno-math-errnowm42020-05-091-0/+1
| | | | | | | | | | | glibc/gcc make certain math functions set errno by default. This is not required by the standard, and makes everything complexer and slower (well done glibc). It typically prevents inlining certain math functions too, where the compiler can turn a function call to a single instruction, such as observed with lrint(). So this has possibly some minor performance advantages, and no disadvantages.
* drm_prime: fallback to drmModeAddFB2Anton Kindestam2020-05-081-3/+9
| | | | | | | | | | Fallback to drmModeAddFB2 if drmModeAddFB2WithModifiers fails. I've observed it failing on a pinebook pro running manjaro. We also got "0" as modifiers from FFmpeg anyway, which might or might not have something to do with this. Instead of trying to find the source of the problem, just add this fallback.
* drm_prime: get the modifier for all planesAnton Kindestam2020-05-081-6/+5
| | | | | | Untested (I don't have a platform that requires modifiers to work here). Might break something, or might fix something. At least this looks more intuitive to me.
* drm_prime: print out errno in error messageAnton Kindestam2020-05-081-1/+4
| | | | It is interesting to know why drmModeAddFB2WithModifiers failed.
* w32_common: Scale window when moving to display with different DPIPiotr Gasior2020-05-081-0/+5
| | | | | For applications that are DPI aware WM_DPICHANGED message contains suggested size and position of window
* w32_common: Support HiDPI on WindowsRealDolos2020-05-083-12/+29
|
* vo_gpu: d3d11: only use presentation feedback with flip modelJames Ross-Gowan2020-05-071-4/+12
| | | | | | | | | | | The current implementation of presentation feedback was designed to be used with flip model presentation. With the bitblt model, GetFrameStatistics returns totally different values and it's not clear if we can use them at all. Previously, this wasn't a problem because with the bitblt model, GetFrameStatistics only worked in exclusive fullscreen. Now that mpv supports exclusive fullscreen, we should explicitly check for a flip model swapchain before using presentation feedback.
* client API: correct an outdated commentwm42020-05-061-2/+1
|
* options: don't trigger bool "compact" path for --loop-filewm42020-05-062-2/+4
| | | | | | | In theory an incompatible change, but I think it's for the better. Impact should be relatively low. I hope. Fixes: #7676
* vf:format: don't error when using convert=yes and not specifying fmtwm42020-05-061-1/+1
|
* test: fix some idiotic UBwm42020-05-061-3/+3
|
* mp_image: add some helperswm42020-05-062-0/+23
| | | | | | | | | | This is really basic for planar image data access; not sure why there weren't such helpers before. They also handle trickier formats that use bit-packing, or they would be mich simpler. (This affects only BGR4/BGR4/MONOW/MONOH, I hope whoever invented them is proud of triggering so many special cases for so little gain.)
* vo_gpu: suppress PL_FATAL logs during probingNiklas Haas2020-05-031-2/+0
| | | | | | | | | These were still mapped to MP errors during probing, but they also get triggered when instance creation fails due to lack of support for e.g. wayland. Since waylandvk is probed above x11vk, we should probably suppress these by default. Closes #7626
* documentation: fix some ReST syntax mistakes in lua.rstEmanuele Torre2020-05-011-1/+1
|
* player: round position percentage to the nearest integerRicardo Garcia2020-05-011-1/+1
| | | | | | This brings the displayed percentage closer to the exact number and allows mpv to more frequently display 100% when it finishes playing a typical video or audio file.
* DOCS/contribute.md: add some blabla about fixup commits in pull requestswm42020-05-011-0/+16
| | | | | | | I have to say this in PR reviews all the time, so maybe I should make i explicit. In too many words of course, many, many, too many words which nobody will read, I get it, now shut up. Sneak in some subtle or not so subtle comments about how I think that github is ruining code quality.
* lua: restore change detection with legacy OSD functionwm42020-05-011-4/+9
| | | | | | | | | | mp.set_osd_ass() (which was undocumented, or in other words, was not supposed to be used by external scripts) used to do change detection in the mpv C code. If the resolution or payload did not change, it was not re-rendered on the lower levels. Apparently this made some people sad, so fix it. (But only after I told them to fuck off.) (Well I didn't put it this way, but still.)
* zimg: remove C11 aligned_alloc() requirementwm42020-05-013-11/+10
| | | | | It's not available on Windows because MinGW is fucking horrible and Microsoft are fucking assholes.
* vo_gpu: enable frame caching for still framesNiklas Haas2020-04-301-3/+3
| | | | | | | | | | For some reason this was never done? Looking through the code, it was never the case that the frame cache was hit for still frames. I have no idea why not. It makes a lot of sense to do so. Notably, this massively improves the performance of updating the OSC when viewing e.g. large still images, or while paused. (Tested on a 4000x8000 image, the OSC now responds smoothly to user input)
* stream_libarchive: remember archive headers from initial openKevin Mitchell2020-04-283-18/+51
| | | | | | | | | | | | | | | | | | The header probing hacks were previously all broken. They only worked the first time the archive file was open. Since subsequent opens (on seek) occured in the middle of the source stream rather than at the beginning, the stream_read_peek calls meant to retrieve the headers were instead returning random bytes in the middle of the file. Perhaps the worst manifestation of this was when seeking within a multi-volume .rar archive with the "legacy" file naming pattern. If the seek required a reopen, the fact that the archive was multi-volume would be forgotten and the file would appear truncated terminating playback. To solve this, only perform the header probling the first time the archive is opened. Save the results and reuse them on subsequent reopens. Put this in a wrapper so this is transparent to demux_libarchive.
* stream_libarchive: simplify multi-volume rar hate messageKevin Mitchell2020-04-271-14/+8
| | | | | | | | I couldn't find any reason for this message to be so far dispalced from where it's necessity was determined. That necessity is not however in question. Also improve the wording and line breaking.
* stream_libarchive: put multi_rar check in a functionKevin Mitchell2020-04-271-10/+14
|
* ta: add ta_get_parent()wm42020-04-262-1/+12
| | | | Sometimes useful for debugging. Also fix a random typo elsewhere.
* ta: change debug ifdefferywm42020-04-261-4/+8
| | | | | TA_MEMORY_DEBUGGING always defined. But allow defining it from the compiler command line (-D), because maybe that's useful for someone?
* video: make OSD/subtitle bitmaps refcounted (sort of)wm42020-04-2613-110/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
* zimg: don't assume zimg reads are 64 byte alignedwm42020-04-251-4/+6
| | | | | | | | | Only _writes_ are aligned, so the assumption doesn't work for reads. But it's easy to fix by rounding down x0 to the next byte boundary. Writing pixels outside of the read area is allowed, and we don't go out of buffer bounds. Patch by anon32, permission to do anything with it.
* cocoa-cb: report actual unfs window size for current window scaleder richter2020-04-252-0/+15
|
* video: add alpha type metadatawm42020-04-248-4/+42
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* sws_utils: remove unused brightness etc. controlswm42020-04-242-7/+1
| | | | | | | Used to be used by vo_x11, and some other situations where software conversion was employed. Haven't seen anyone complain about how software brightness controls went away (originating from mplayer), so whatever, it won't be needed again.
* win32: SGR emulation: minor fixup on invalid sequenceAvi Halachmi (:avih)2020-04-241-2/+5
| | | | | | | | This fixes two issues with invalid value after 38/48: - It was not detected correctly and ended up skipping 4 instead of 0. - The intent was to skip 0, but it's better to skip the rest. Behavior with valid 2/5 after 38/48 was correct and is unaffected.
* video/out/vo_tct: query terminal size genericallyAvi Halachmi (:avih)2020-04-231-7/+3
| | | | | terminal_get_size also works on windows. This is useful because now tct also works on Windows with native VT console.
* osdep/terminal-win: native VT: report exact widthAvi Halachmi (:avih)2020-04-231-2/+3
| | | | | The narrower-by-1 width is not required with a native VT console because the wrapping behavior is the same as on *nix on such case.
* wayland: explictly send an UP event for left clickDudemanguy2020-04-231-0/+2
| | | | | | | | | | | | | | | In the wayland code, the left mouse click is treated a bit differently. Dragging the left click allows mpv to request a window move to the compositor. In some cases, this can also request a window resize if the osc-windowcontrols are enabled. These functions had the strange side effect of messing up mpv's deadzone (it seemed to disappear completely). A harmless enough workaround is to just explictly send an UP event for left click after the move/resize functions are finished executing. The xdg_toplevel move and resize functions both finish after the button press is let go, so we are guarenteed to have the left click in the UP state here. Sending this event probably unconfuses some calculation somewhere thus fixing the deadzone bug. It feels a little silly, but it's safe and works. Fixes #7651.
* win32: native VT: logic fixupAvi Halachmi (:avih)2020-04-231-2/+2
| | | | | We want basemode unmodified so that we can use it if setting VT mode fails.
* stats.lua: don't disable terminal escape sequences on windowsAvi Halachmi (:avih)2020-04-231-22/+4
| | | | | | | | | | | | | | | | | | | | | When stats.lua is used without a video window then it uses the terminal. On Windows, however, so far it disabled ansi escape sequences and used plaintext unless ANSICON env is set. It's unclear why it's disabled on windows, because at the time it was added it only used bold by default and mpv ansi emulation on windows already supported bold at that time. We can guess that it was disabled because if the same config is used on both linux and Windows, and it had complex escape sequences for stats.lue, then it would be emulated incorrectly on Windows. This shouldn't be an issue anymore, as the last two commits both enhance the emulation to be quite complete (and graceful where it's not), and also enable the much-more complete native VT terminal when possible (Windows 10). Just remove this windows exception at stats.lua.
* win32: use windows 10 native virtual-terminal if availableAvi Halachmi (:avih)2020-04-231-2/+34
| | | | | | | | This enables native and more complete escape-sequence handling instead of our emulation. E.g. it supports 256/true colors, and more. This should get enabled automatically on Windows 10 build 16257 (August 2017) or later.
* win32: improve console SGR escape sequence emulationAvi Halachmi (:avih)2020-04-231-11/+50
| | | | | | | | | | | | | | | Previously an SGR sequence was emulated correctly only if: - It had exactly 1 or 2 numeric values (not 0). - Only reset, bold, and foreground colors were supported. - 256/true colors were not skipped correctly with their sub-values. Now it supports the same as before, plus: - 0-16 (inclusive) numeric values, e.g. \e[m now resets correctly. - Supports also codes for background color, reverse, underline* . - Supports also codes for default intensity/fg/bg/reverse/underline. - 256/true colors are recognized and skipped gracefully. * Reverse/underline seem to work only on windows 10.
* rpi: use "brcm" variant of libGLESv2Jan Palus2020-04-231-1/+1
|
* egl_helpers: add typedef for EGLAttrib (#7314)Jan Palus2020-04-231-0/+1
| | | | part of EGL 1.5 which is not present ie on Raspberry Pi
* build: restore BSD thread names after 9f461b85bfa3Jan Beich2020-04-232-1/+5
| | | | | | | | | | | | | | On FreeBSD non-POSIX threading functions are in a separate header. DragonFly and OpenBSD adopted FreeBSD header and extensions. ../test.c:3:3: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration] { pthread_set_name_np(pthread_self(), "ducks"); return 0; } ^ ../osdep/threads.c:47:5: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pthread_set_name_np(pthread_self(), tname); ^ Signed-off-by: Jan Beich <jbeich@FreeBSD.org>
* zimg: get rid of special "override" fields for low depth RGB/graywm42020-04-231-34/+16
| | | | | This makes it use the previously added fringe image formats. What is the purpose of this change? Who knows.
* zimg: slightly cleanup some mpv format handling nonsensewm42020-04-231-34/+40
| | | | | | | | | | | | Move lookup GBRP or planar gray/alpha formats to separate functions in some cases. Make setup_regular_rgb_packer() not use a 4:4:4 YUV format to "pass" RGB. This was used as a "trick" to avoid the stupid GBRP plane permutation, but it confused severely, so get rid of it. Just do the reordering, even if the zimg wrapper itself will reorder it back (which is so stupid that I used the other approach at first). The comment saying IMGFMT_420P was bogus of course; typically it was IMGFMT_444P.
* f_swscale: let common code guess color levels when RGB->YUVwm42020-04-231-2/+2
| | | | Probably doesn't matter anywhere.
* img_format: treat both monow and monob as RGBwm42020-04-232-3/+5
| | | | | | | | | This was inconsistent for unknown reason. monob was the way we wanted it, and handling of monow was missing. See the previous "img_format: add some mpv-only helper formats" commit. Matters for the zimg wrapper.
* img_format: remove duplication in FFmpeg yuv vs. rgb pixfmt checkwm42020-04-231-7/+9
| | | | | | | | mp_imgfmt_get_forced_csp() should be consistent with the MP_CSP_RGB/YUV flags. At least the different handling of the XYZ exception was a mess, even if the result was the same.
* img_format: add some mpv-only helper formatswm42020-04-234-0/+95
| | | | | | | | | | | | | | | | | Utterly useless, but the intention is to make dealing with corner case pixel formats (forced upon us by FFmpeg, very rarely) less of a pain. The zimg wrapper will use them. (It already supports these formats automatically, but it will help with its internals.) Y1 is considered RGB, even though gray formats are generally treated as YUV for various reasons. mpv will default all YUV formats to limited range internally, which makes no sense for a 1 bit format, so this is a problem. I wanted to avoid that mp_image_params_guess_csp() (which applies the default) explicitly checks for an image format, so although a bit janky, this seems to be a good solution, especially because I really don't give a shit about these formats, other than having to handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray, just packed) already explicitly marked itself as RGB.
* filters: fix a typo in a commentwm42020-04-231-1/+1
|
* video: change chroma_w/chroma_h fields to use shift instead of sizewm42020-04-237-51/+41
| | | | | | | | | | When I added mp_regular_imgfmt, I made the chroma subsampling use the actual chroma division factor, instead of a shift (log2 of the actual value). I had some ideas about how this was (probably?) more intuitive and general. But nothing ever uses non-power of 2 subsampling (except jpeg in rare cases apparently, because the world is a bad place). Change the fields back to use shifts and rename them to avoid mistakes.
* img_format: add format description table for mpv-only formatswm42020-04-233-135/+150
| | | | | | | Make this slightly less ad-hoc. Also correct the missing alpha flag for yap8/yap16. Despite reduced redundancy, the LOC is going up anyway... whatever.
* drm_common: set frsig to a valid signalJan Beich2020-04-221-0/+3
| | | | | | | | | | | On FreeBSD and DragonFly kernel checks if `frsig` is valid and aborts with `EINVAL` if not. However, `frsig` was never implemented. $ build/mpv --gpu-context=drm /path/to/video.mkv [...] [vo/gpu] VT_SETMODE failed: Invalid argument [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [...]
* build: detect VT_GETMODE on FreeBSD and DragonFlyJan Beich2020-04-222-2/+15
| | | | | | | | | | | | | | | | $ ./waf configure Checking for vt.h : no Checking for DRM : vt.h not found [...] ../test.c:1:10: fatal error: 'sys/vt.h' file not found #include <sys/vt.h> ^~~~~~~~~~ $ build/mpv --gpu-context=drm /path/to/video.mkv Error parsing option gpu-context (option parameter could not be parsed) Setting commandline option --gpu-context=drm failed. Exiting... (Fatal error)
* wayland: use mp_time deltas for presentation timeDudemanguy2020-04-204-30/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One not-so-nice hack in the wayland code is the assumption of when a window is hidden (out of view from the compositor) and an arbitrary delay for enabling/disabling the usage of presentation time. Since you do not receive any presentation feedback when a window is hidden on wayland (a feature or misfeature depending on who you ask), the ust is updated based on the refresh_nsec statistic gathered from the previous feedback event. The flaw with this is that refresh_nsec basically just reports back the display's refresh rate (1 / refresh_rate * 10^9). It doesn't tell you how long the vsync interval really was. So as a video is left playing out of view, the wl->last_queue_display_time becomes increasingly inaccurate. This led to a vsync spike when bringing the mpv window back into sight after it was hidden for a period of time. The hack for working around this is to just wait a while before enabling presentation time again. The discrepancy between the "bogus" wl->last_queue_display_time and the actual value you get from the feedback only happens initially after a switch. If you just discard those values, you avoid the dramatic vsync spike. It turns out that there's a smarter way to do this. Just use mp_time_us deltas. The whole reason for these hacks is because wl->last_queue_display_time wasn't close enough to how long it would take for a frame to actually display if it wasn't hidden. Instead, mpv's internal timer can be used, and the difference between wayland_sync_swap calls is a close enough proxy for the vsync interval (certainly better than using the monitor's refresh rate). This avoids the entire conundrum of massive vsync spikes when bringing the player back into view, and it means we can get rid of extra crap like wl->hidden.
* draw_bmp: silence another ridiculous ubsan warningwm42020-04-181-4/+4
| | | | | | | | | | | | | | UB sanitizer complains that aval<<24 (if >=128) cannot be represented as int. Indeed, we would shift a bit into the sign of an int, which is probably UB or implementation defined (I can't even remember, but the stupidity of it burns). So technically, ubsan might be right. Change aval to uint32_t, which I don't think has a chance of getting promoted to int. Change the other *val to uint32_t too for cosmetic symmetry. So we have to obscure the intention of the code (*val can take only 8 bits) out of language stupidity. How nice. (What a shitty language.)
* sd_lavc: mitigate evil rounding issue that could lead to off-by-1 frameswm42020-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A mkv sample file was provided to me, which contained a moving PGS subtitle track, with the same track rendered into the video as reference. The subtitle track appeared to stutter (while the video one was smooth). It turns out this was a timestamp rounding issue in mpv. The subtitle timestamps in the file match the video ones exactly. They're the same within the mpv demuxer too. Unfortunately, the conversion from and to libavcodec timestamps is lossy, because mpv uses a non-integer timebase, while libavcodec supports integers only. See mp_pts_to_av() and mp_pts_from_av(). The recovered timestamp is almost the same, but is off by a very minor part. As a result, the timestamps won't compare equal, and if that happens, display of the subtitle frame is skipped. Subtitle timestamps don't go through this conversion because... libavcodec is special? The libavcodec subtitle API is special. Fix this by giving it a microsecond of slack. This is basically as if we used an internal microseconds integer timebase, but only for the purpose of image subtitle display. The same could happen to sd_ass, except in practice it doesn't. ASS subtitles (well, .ass files) inherently use a timebase incompatible to video, so to ensure frame exactness, ASS timestamps are usually set to slightly before the video frame's. Discussion of better solutions: One could rewrite mpv not to use float timestamps. You'd probably pick some integer timebase instead (like microseconds), which would avoid the libavcodec interop issue. At the very least this would be a lot of work. It would be interesting to know whether the rounding in ther mpv<->lavc timestamp conversion could be fixed to round-trip in this case. The conversion tries to avoid problems by using the source timebase (e.g. milliseconds with mkv). But in general some rounding is unavoidable, because something between decoder and lowest demuxer layer could transform the timestamps. One could extend libavcodec to attach arbitrary information to avpacket and return it in the resulting avframe. To some degree, such a mechanism already exists (side data). But there are certain problems that make this unfeasible and broken. One could pass through exact mpv float timestamps by reinterpret-casting them to int64_t, the FFmpeg timestamp type. Actually mpv used to do this. But there were problems, such as FFmpeg (or things used by FFmpeg) wanting to interpret the timestamps. Awful shit that make mpv change to the current approach. There's probably more but I'm getting bored. With some luck I wasted precious seconds of your life with my nonsense.
* stats: move chapter/edition info below titleLaserEyess2020-04-161-3/+3
| | | | | | | | It is more consistent for editions/chapters to go below either the title or filename. They are all descriptive strings about the media itself and not file metadata like filesize. Suggested by Argon-
* stats: add edition information to page 1LaserEyess2020-04-161-1/+13
| | | | | | Edition information is conditional based on there being more than one edition present. It is printed on the same line as Chapters to save vertical space.
* demux_mkv: add png intra supportwm42020-04-161-0/+1
| | | | | | | Evil, non-standard shit. Sample file and script: https://github.com/mpv-player/random-stuff/tree/master/matroska/png
* player: remove duplicated track option setter codewm42020-04-153-17/+11
| | | | Well whatever.
* player: slightly improve use of secondary track selection limitswm42020-04-156-20/+28
| | | | | | Apparently, this was a bit of a mess, which caused the bug fixed by commit ec7f2388af2df. Try to improve this, and only use track selection entries that exist.
* player: remove mysterious declarationwm42020-04-151-2/+0
| | | | ??????????
* terminal-unix: add key_entry defs for DECCKM modeMurray Campbell2020-04-151-0/+4
| | | | | | | | zsh often sets DECCKM (i.e. Cursor Key Mode) meaning the arrow keys send `SS3 A/B/C/D` instead of `CSI A/B/C/D`. Add `key_entry` definitions for this alongside the existing DECCKM Reset definitions.
* player: don't segfault when unloading tracksNiklas Haas2020-04-151-0/+2
| | | | | | | | | e1e714ccc introduced a regression here when unloading a track (e.g. on VO/AO initilization error), due to no corresponding option existing for video/audio tracks with orders above 0, but the loop in `mp_deselect_track` being hard-coded to clear tracks up to NUM_PTRACKS. Introduce the simplest possible hackaround.
* vo_gpu: opengl: make sure to always clean up debug callbacksNiklas Haas2020-04-151-0/+4
| | | | | | | | | In theory this mostly happens automatically, especially after the 5 vsync limit disables this already. But if we uninit before 5 vsyncs are rendered, this can get left in a dangling 'enabled' state, which leaks a debug report callback. Always explicitly disable it just to be on the safe side.
* manpage: fix wrong option name for --fbo-formatwm42020-04-141-1/+1
| | | | Fixes: #7609
* zimg: fix swapped chroma planes with packed YUV bullshitwm42020-04-141-4/+4
| | | | | | | | | I must have messed this up when I actually added the Y210 format (because that one is correct). So my comment in the commit adding this about the FFmpeg pixfmt doxygen being wrong was wrong. I'd like to use this opportunity to complain once more about the existence of these terrible pixel formats.
* zimg: fix build with older FFmpeg (troublesome Intel dude format)wm42020-04-141-0/+2
|
* zimg: add support for 1 bit per pixel formatswm42020-04-132-2/+54
| | | | | | | | | | | | | | Again worthless, slow, and only for libswscale parity. With this, we support all formats libswscale supports, except bayer input, and rgb4/bgr4 output. We even support some formats libswscale doesn't. It's possible that the zimg wrapper isn't always as fast as libswscale. But there is optimization potential: the inner repack loops are self-contained enough that they could be reasonably be implemented in assembler (probably), and doing everything slice-wise should reduce the overhead of the separate pack/unpack stages.
* zimg: add packed YUV bullshitwm42020-04-132-6/+116
| | | | | | | | | | | | | | | | | Just lazily tested. The comment on AV_PIX_FMT_Y210LE seems to be wrong. It claims it's "like YUYV422", bit it seems more like YVYU422, at last the way libswscale input treats it. Maybe Intel pays its developers too much? The repacker inner lop is probably rather inefficient. In theory we could optimize it by reading the packed pixels as words, doing the component reshuffling using compile time values etc., but I'd rather keep the code size small. It's already bad enough that we have to support 16 bit per component variants, just because this one Intel guy couldn't keep it in his pants. In general, I can't be bothered to spend time on optimizing it; I'm only doing this for fun (i.e. masochistic obligation).
* demux_mkv: concatenate multiple tagswm42020-04-131-2/+8
| | | | | | | | | | | Instead of just picking the last tag that was encountered. The order of the tags still depends on the file order. This is probably wrong, and we should respect TargetTypeValue. But despite staring at the spec, I have no idea what the hell this should do, so fuck that. Fixes: #7604
* test: add list of zimg/sws conversionswm42020-04-132-0/+217
| | | | | | | Generic statement about how this is not really appropriate, etc., and only useful for temporary debugging things, and how I commit it anyway despite violating my own principles (and how I'd reject this change if it came from you).
* player: do not fall back to a default track with explicit selectionswm42020-04-132-0/+20
| | | | | | | | | | | | | | | | | | Consider e.g. --aid=2 with a file that has only 1 track. Then it would fall back to selecting track 1. Stop doing this. If no matching track is found, this will not select any track now. Note that the fingerprint stuff (track_layout_hash in the source) prevents softens the impact of this change. Without the fingerprint, playing a dual-audio file with the second track selected, and then a single-audio file, would play the second file without audio. But the fingerprint resets it due to differences in the track list. Try to exhaustively document this and tricky interactions between the other features. What a damn mess, I think it's simply cursed. Of course it's still my fault. See: #7608
* player: mess with track selection details againwm42020-04-133-12/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some time ago, properties and options were mostly unified. However, the track selection properties/options semantics are incompatible to this change. I'm still trying to handle the fallout. There are two things that are in the way: 1. Track properties somehow return the runtime selection, not the option value (all while properties are supposed to be aliases to options with the same name). 2. The user's track options are not supposed to be changed without interaction. If a track is auto-selected, the property should return its ID, but the option value should remain at "auto". Only if the user actually writes to the property the option should change. E.g. playing e.g. an audio-only file and then a normal video file not play the video file with --vid=no just because the audio file had no video track. In addition to each of them being in conflict with the property/option unification, attempt to fix one of them breaks the other one. Today, we're trying to fix parts of this and avoiding an unfortunate case where you can get a conflicting option/property value, and where trying to select a track does nothing if the track to select has the same ID as the option value. This breaks 2. from above in certain situations. See manpage additions. See: #7608
* demux: don't let --sub-create-cc-track add a track for attached pictureswm42020-04-131-1/+1
| | | | | | | | Unfortunately, attached pictures (from tags etc.) are treated as video tracks. That meant --sub-create-cc-track added a CC track for them as well. Stop doing that. See: #7608
* zimg: add support for some RGB fringe formatswm42020-04-131-0/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers 8 and 16 bit packed RGB formats. It doesn't really help with any actual use-cases, other than giving the finger to libswscale. One problem is with different color depths. For example, rgb565 provides 1 bit more resolution to the green channel. zimg can only dither to a uniform depth. I tried dithering to the highest depth and shifting away 1 bit for the lower channels, but that looked ugly (or I messed up somewhere), so instead it dithers to the lowest depth, and adjusts the value range if needed. Testing with bgr4_byte (extreme case with 1/2/1 depths), it looks more "grainy" (ordered dithering artifacts) than libswscale, but it also looks cleaner and smoother. It doesn't have libswscale's weird red-shift. So I call it a success. Big endian formats need to be handled explicitly; the generic big endian swapper code assumes byte-aligned components. Unpacking is done with shifts and 3 LUTs. This is symmetric to the packer. Using a generated palette might be better, but I preferred to keep the symmetry, and not having to mess with a generated palette and the pal8 code. This uses FFmepg pixfmts constants directly. I would have preferred keeping zimg completely separate. But neither do I want to add an IMGFMT alias for every of these formats, nor do I want to extend our imgfmt code such that it can provide a complete description of each packed RGB format (similar to FFmpeg pixdesc). It also appears that FFmpeg pixdesc as well as the FFmpeg pixfmt doxygen have an error regarding RGB8: the R/B bit depths are swapped. libswscale appears to be handling them differently. Not completely sure, as this is the only packed format case with R/B havuing different depths (instead of G, the middle component, where things are symmetric).
* zimg: add support for big endian input and outputwm42020-04-134-50/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the extremely annoying dumb things in ffmpeg is that most pixel formats are available as little endian and big endian variants. (The sane way would be having native endian formats only.) Usually, most of the real codecs use native formats only, while non-native formats are used by fringe raw codecs only. But the PNG encoders and decoders unfortunately use big endian formats, and since PNG it such a popular format, this causes problems for us. In particular, the current zimg wrapper will refuse to work (and mpv will fall back to sws) when writing non-8 bit PNGs. So add non-native endian support to zimg. This is done in a fairly "generic" way (which means lots of potential for bugs). If input is a "regular" format (and just byte-swapped), the rest happens automatically, which happens to cover all interesting formats. Some things could be more efficient; for example, unpacking is done on the data before it's passed to the unpacker. You could make endian swapping part of the actual unpacking process, which might be slightly faster. You could avoid copying twice in some cases (such as when there's no actual repacker, or if alignment needs to be corrected). But I don't really care. It's reasonably fast for the normal case. Not entirely sure whether this is correct. Some (but not many) formats are covered by the tests, some I tested manually. Some I can't even test, because libswscale doesn't support them (like nv20*).
* vf_format: add gross mechanism for forcing scaler for testingwm42020-04-138-3/+53
| | | | | | | | | | | This sucks, but is helpful for testing. Obviously, it would be much nicer if there were a way to specify _all_ scaler options per filter (if the user wanted), instead of always using the global options. But this is "too hard" for now. For testing, it is extremely convenient to select the scaler backend, so add this option, but make clear that it could go away. We'd delete it once there is a better mechanism for this.
* ta: minor simplification for talloc_stealwm42020-04-133-11/+1
| | | | Since commit f6615f00eeb0, it can't fail anymore.
* ta: remove a macro indirectionwm42020-04-131-4/+2
| | | | No idea what purpose this was supposed to serve.
* player, ta: remove use of an old macrowm42020-04-132-4/+1
| | | | | I thought that would make a nice idiom, but it ended up being useless or clunky.
* command: print edition title to OSD when cyclingLaserEyess2020-04-131-5/+26
| | | | | | Edition title is already exposed in demux_edition, it was just never added to the display. If no edition title exists it will fall back to the edition number.
* DOCS/interface-changes: add d3d11-exclusive-fs to list of changesJan Ekström2020-04-121-0/+2
| | | | Was forgotten in finishing up the pull request.
* vo_gpu: d3d11: also utilize config cache for d3d11-specific optionsJan Ekström2020-04-121-1/+9
| | | | | Update the cache whenever we utilize p->opts, as recommended by wm4.
* vo_gpu: d3d11: add support for exclusive fullscreenJames Ross-Gowan2020-04-122-1/+92
| | | | | Lets the application fully control the rendering onto the screen instead of the compositor.
* stats: support UP/DOWN to scroll at page 4 (perf)Avi Halachmi (:avih)2020-04-112-14/+86
| | | | | | | | | | | | | | Keys and lines-to-scroll are configurabe, and the scroll keys are only bound on pages which support scrolling (currently only page 4) - also during oneshot (like the page-switching keys). Scroll offset is reset for all pages on any key - except scroll keys, so that entering or switching to a page resets the scroll, as well as when "re-entering" the same page or "re-activating" the stats oneshot view. TODO: print_page(..) is highly associated with extending the oneshot timer if required. The timer handling can probably move into print_page and removed from all the places which boilerplate its management.
* stream_dvb: Remove call to stream_drop_buffers in fill_buffer.Oliver Freyermuth2020-04-101-2/+0
| | | | | | | | The call was hidden very well, via dvb_streaming_read -> dvb_update_config -> dvb_streaming_start -> dvb_set_channel, and broke the stream buffering logic. Dropping that call does not noticeably slow down channel switches.
* console: reduce memory usage in default modewm42020-04-101-73/+82
| | | | | | | | | | | | | | | This used 1 MB due to building the complete command and property list when starting the script. These are needed only for auto-completion, so build them only on demand. Since building them is fast enough, rebuild them every time. The key bindings table is not that much, but saves some KBs. Oddly, the code to build it uses less memory than the table at runtime (???), so build it at runtime as well. Add 2 tactic collectgarbage() calls as well. This frees unused heap when it is known that the script is going to be completely inactive until re-enabled by the user.
* common: fix mp_round_next_power_of_2()wm42020-04-101-5/+6
| | | | | | | Who write this dumb shit¹? It didn't handle 1<<31, and was unnecessarily slow. ¹ it was me
* stream: actually drop unneeded bufferwm42020-04-101-16/+21
| | | | | | | | | | | | | | | | | | The buffer can be larger than the normal size when "peeking" is used (such as done with some file formats, where a large number of bytes masy need to be "peeked" at the beginning, because FFmpeg). Once normal operation resumes, it's supposed to free this buffer again. Apparently this didn't happen as intended, because normal reading did have no way to discard back buffer before/while resizing the buffer. There's only a path for discarding the back buffer when actually reading. It seems like this unfortunately needs 2 code paths for discarding old data. Just put it into stream_resize_buffer(), where it's rather non-tricky (discarding can be done by adjusting the copy offset when moving data to the new allocation). The function now drops old data if it doesn't fit into the allocation. The caller must ensure that the new size is sufficient; the function signature changes only so the size of the implicitly guaranteed kept part can be checked with assert().
* stream: add assert, a cosmetic changewm42020-04-101-1/+3
| | | | This shouldn't change anything.
* stream: minor adjustment to buffer size limit logicwm42020-04-101-6/+6
| | | | | Instead of having 2 inconsistent limits on the upper possible buffer size (option limit and allocation code), use a shared constant for them.
* stream: fix whitespace within commentwm42020-04-101-1/+1
| | | | arrrrrrrghh
* vo: further reduce redundant wakeupswm42020-04-101-1/+7
| | | | | | | | | | | | | | | In display-sync mode, the core doesn't need to woken up every vsync, but only every time a new actual video frame needs to be queued. So don't wake up if there are still frames to repeat. In audio-sync mode, the wakeup is simply redundant, since there's a separate timer (in->wakeup_pts) to control when to queue a new frame. I think. This finally brings the required playloop iterations down to almost the number of video frames. (As originally intended, really.) Also a fairly risky change.
* video: remove another redundant wakeupwm42020-04-103-20/+46
| | | | | | | | | | | | | | | The wakeup at the end of VO frame rendering seems redundant, because after rendering almost no state changes. The player core can queue a new frame once frame rendering begins, and there's a separate wakeup for this. The only thing that actually changes is in->rendering. The only thing that seems to depend on it and can trigger a wakeup is the vo_still_displaying() function. Change it so that it needs an explicit call to a new API function, so we can avoid wakeups in the common case. The vo_still_displaying() code is mostly just moved around due to locking and for avoiding forward declarations. Also a somewhat risky change (tasty new bugs).
* video: avoid redundant self-wakeup on each queued framewm42020-04-101-1/+2
| | | | | | | | | This should be unnecessary, since the VO itself performs wakeups once a new frame can be queued. The only situation I can think of where this might be required are EOF situations (which are always strange). If I'm wrong, there'll be fun new bugs, probably causing frame drops or temporary stalls.
* player, stats: more silly debug stuffwm42020-04-106-2/+26
| | | | | In addition to stats.c being gross, I don't think master branch code should be littered with debug code. But it's a helpful abomination.
* filter: reduce redundant re-iterationswm42020-04-101-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the player core requests new frames from the filter, this is called external/recursive filtering, which acts slightly differently from when filters request new data internally. Mainly this is so the external user doesn't have to call mp_filter_graph_run() just to get a frame. This causes a number of complications, and the short version is that until now, mp_filter_graph_run() has unnecessarily returned true in the current common case, which made the playloop run too often for no reason. The problem is that when a mp_pin is read externally, updating the same mp_pin during recursive filtering flagged external_pending when the result was written, which made mp_filter_graph_run() return true, which made the playloop call mp_filter_graph_run() again. This is redundant because the caller is obviously checking the new state of the mp_pin immediately. The only situation in which external_pending really must be set is if _another_ pin is changed. In theory, we could also unset it if the set of "external" pins that are not in a signaled state becomes empty, but we don't track that in a convenient way. This commit removes the redundant signaling, and avoids running the playloop an additional time for each video and audio frame (as it actually was planned from the beginning, but duh).
* filter: process asynchronous wakeups during filteringwm42020-04-101-4/+5
| | | | | | | | | | | | | If a filter receives an asynchronous wakeup during filtering, then process newly pending filters resulting from that as well, before returning to the user. Might possibly skip some redundant playloop cycles. There is an explicit comment in the code about how this shouldn't be done, but I think it makes no sense. Filters have no business trying to interrupt the mainloop, and mp_filter_graph_interrupt() provides a proper mechanism to do this (though intended to be used by the filter user, not filters).
* stats: fix crash if both plot_vsync_* options are disabledwm42020-04-091-3/+6
| | | | | | | | | | | In this case, init_buffers() was not called, and the unrelated cache sample buffers were not initialized. It appears they are indeed completely unrelated, so move their initialization away. Not sure what exactly the purpose of calling init_buffers() is, maybe clearing old data when displaying stats again. The new place for initializing the cache sample buffers should achieve the same anyway. Fixes: #7597
* player: do not deinitialize AO on track switchingwm42020-04-091-1/+2
| | | | | | | | This should make it behave roughly like when switching from a file to the next (clearing audio buffers, keeping AO, but closing AO if the audio format seems to have changed and gapless mode is "weak"). Not necessarily useful, but harmless and may help with #7579 (untested).
* options: cleanup .min use for OPT_CHANNELSwm42020-04-094-8/+9
| | | | | | | | Replace use of .min==1 with a proper flag. This is a good idea, because it has nothing to do with numeric limits (also see commit 9d32d62b61547 for how this can go wrong). With this, m_option.min/max are strictly used for numeric limits.
* options: make imgfmt options always accept "no"wm42020-04-092-6/+3
| | | | | | | | This was optional, with the intention that normally such options require a valid format. But there is no reason for this (at least not anymore), and it's actually more logical to accept "no" in all situations this option type is used. This also gets rid of the weird min field special use.
* options: fix ab-loop-* propertieswm42020-04-093-4/+7
| | | | | | | | | | | These used ".min = MP_NOPTS_VALUE" to indicate certain exceptions. This broke with the recent change to how min/max are handled, which made setting min or max mean that a value range is used, thus setting max=0. Fix this by not using magic a value in .min; replace it with a proper flag. Fixes: #7596
* lua: wrap existing allocator instead of reimplementing itNiklas Haas2020-04-091-16/+12
| | | | | | | | This is the proper fix for 1e7802. Turns out the solution is dead simple: we can still set the allocator with lua_getallocf / lua_setalloc. This commit makes memory accounting work on luajit as well.
* lua: disable memory accounting for luajitNiklas Haas2020-04-091-0/+7
| | | | | | | | This is a stopgap measure. In theory we could maybe poll the memory usage on luajit, but for now, simply reverting this part of fd3caa26 makes Lua work again. (And we can still collect cpu usage metrics) Proper solution pending (tm)
* manpage: finish a sentencewm42020-04-091-1/+2
|
* ipc: add --input-ipc-client optionwm42020-04-096-7/+57
| | | | | | | | | While --input-file was removed for justified reasons, wanting to pass down socket FDs this way is legitimate, useful, and easy to implement. One odd thing is that Fixes: #7592
* stats: some more performance graphswm42020-04-0915-11/+519
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* input: add binding to quit on ctrl+wsfan52020-04-041-0/+1
| | | | Other GUI applications typically handle this as "close document" or "close window".
* stats: fix previous commitwm42020-04-031-2/+2
| | | | | The previous commit included a rendering error of the "Speed:" line, caused by incorrect copy&paste.
* stats: move input speed to cache page, make it a graphwm42020-04-031-13/+12
| | | | | | | I think that makes more sense. And also remove the graph from the total cache usage, since that wasn't very interesting. So there's still a total of 2 graphs.
* command: make input speed available as part of cache statge propertywm42020-04-032-0/+9
| | | | | | That's where it comes from after all. The other property does not have much of a reason to exist anymore, but there's no real reason to remove it either.
* umpv: convert to python 3wm42020-04-031-2/+2
| | | | Sigh.
* player: make a function staticwm42020-04-032-2/+1
|
* build: only check for EGL pc in one build optionNicolas F2020-04-021-7/+5
| | | | | | | | | | | | | | | | | Previously, EGL as provided by a pkg-config was checked for independently in several places. The effect this had is that --disable-egl would not actually disable EGL from the build, as this only affected the "egl" option relied upon by egl-x11. wayland-gl and egl-drm did their own EGL checks. By making wayland-gl and drm-egl depend on egl instead, we fix this behaviour and can simplify egl-helpers a bit, as we can now simply check whether egl or one of the other features providing some non-pc egl is enabled, instead of checking every single thing that might be pulling in egl. Future work could make the "egl" option just be a catchall for any EGL implementation, so that brcmegl and angle and Android can piggyback on the egl option as well.
* ytdl_hook: enable runtime changes of script optionssfan52020-03-291-1/+4
|
* ao_oss: remove this audio outputwm42020-03-285-681/+1
| | | | | | | | | | Ancient Linux audio output. Apparently it survived until now, because some BSDs (but not all) had use of this. But these should work with ao_sdl or ao_openal too (that's why these AOs exist after all). ao_oss itself has the problem that it's virtually unmaintainable from my point of view due to all the subtle (or non-subtle) difference. Look at the ifdef mess and the multiple code paths (that shouldn't exist) in the removed source code.
* ao_rsound: remove this audio outputwm42020-03-285-170/+0
| | | | | | I wonder what this even is. I've never heard of anyone using it, and can't find a corresponding library that actually builds with it. Good enough to remove.
* ao_sndio: remove this audio outputwm42020-03-285-338/+0
| | | | | | It was always marked as "experimental", and had inherent problems that were never fixed. It was disabled by default, and I don't think anyone is using it.
* manpage: clarify some event/hook detailswm42020-03-281-4/+18
|
* input: remove deprecated --input-file optionwm42020-03-2811-192/+2
| | | | | This was deprecated 2 releases ago. The deprecation changelog entry says that there are no plans to remove it short-term, but I guess I lied.
* umpv: change from legacy FIFO to socketwm42020-03-281-23/+14
| | | | --input-file is deprecated, and the JSON IPC is saner anyway.
* client API: report IDs of inserted playlist entries on loading playlistwm42020-03-277-15/+70
| | | | | | May or may not help when dealing with playlist loading in scripts. It's supposed to help with the mean fact that loading a recursive playlist will essentially edit the playlist behind the API user's back.
* client API: another minor clarification for conveniencewm42020-03-271-1/+3
| | | | The previous commit actually makes use of this.
* ipc: fix recently added memory leakwm42020-03-271-1/+3
| | | | Sucks.
* scripting: remove race condition when toggling internal scriptswm42020-03-266-31/+31
| | | | | | | | | | Scripts such as the OSC can be loaded and unloaded at runtime by toggling the option that enables them. (It even works, although normally it's only used to control initial loading.) Unloading was racy because it used the client name; fix this. The load-script change is an accidental feature. And probably useless.
* command: use client IDs for hookswm42020-03-264-12/+24
| | | | | Removes weird potential race conditions when a client is removed and a new one with the same name is created.
* client API: add a per client unique IDwm42020-03-264-0/+47
| | | | | | I mostly intend this for internal purposes. Probably pretty useless for external API users, but on the other hand trivial to expose. While it makes a lot of sense internally, I'll probably regret exposing it.
* client API: update MPV_EVENT_PLAYBACK_RESTART docswm42020-03-261-3/+3
| | | | Ordered chapters haven't used user-visible seeks for over 4 years.
* command: make revert seek command use time from end of seekwm42020-03-261-0/+3
| | | | | | | | | This time is set on every seek (but when initiating it). A new seek longer than 2 seconds after this is counted as separate seek for the sake of the revert seek command. If a seek takes a bit longer, this removes time from these 2 seconds. This commits resets it on the end of the seek. (Doing anything special for seeks that take longer than 2 seconds is out of scope of this commit.)
* video: report negative subtitle/OSD margins if necessarywm42020-03-261-4/+4
| | | | | | | | | | | | | | Until now, it used only coordinates clipped to the screen for this, which meant no negative margins were ever reported to libass. This broke proper rendering of explicitly positioned ASS events (libass simply could not know the real video size in this case.) Fix this by reporting margins even if they're negative. This makes it apparently work correctly with vo_gpu at least. Note that I'm not really sure if anything in the rendering chain required non-negative margins. If so, and that code implicitly assumed it, I suppose crashes and such are possible.
* travis: reactivate notifications on failureder richter2020-03-251-1/+1
|
* travis: fix config validation warningsder richter2020-03-251-3/+1
| | | | | private keys should be prefixed with an underscore (_). the sudo key is deprecated and doesn't influence anything anymore.
* vd_lavc: make hwdec fallback message more consistentwm42020-03-241-4/+1
| | | | | | | | | | | The "rule" is that a fallback warning message should be shown only shown if software decoding was used before, or in other words when either hwdec was enabled before, but the stream suddenly falls back, or it was attempted to enable it at runtime, and it didn't work. The message wasn't printed the first time in the latter case, because hwdec_notified was not set in forced software decoding mode. Fix it with this commit. Fortunately, the logic becomes simpler.
* lua: mp.get_property[_osd] don't need special handling anymoreAvi Halachmi (:avih)2020-03-231-11/+2
| | | | Because they recently became normal autofree functions.
* lua: readdir: fix double closedir, use one more autofreeAvi Halachmi (:avih)2020-03-221-3/+1
| | | | | The double closedir is a regression from the previous commit, which also forgot to use the autofree context with the fullpath string.
* lua: autofree: use in few more places where it could leakAvi Halachmi (:avih)2020-03-221-14/+49
| | | | | | | This also uses talloc destructors- like the JS autofree does. The lua autofree is now used at the same places where the JS autofree is used.
* lua: autofree: the ctx is now an argumentAvi Halachmi (:avih)2020-03-221-40/+41
| | | | | | | | | | | There's no more need to call mp_lua_PITA to get the ctx, and the autofree prototype is now enforced at the C level at compile time. Also remove the redundant talloc_free_children at these functions since it's now freed right after the function completes. Also, rename auto_free_node to steal_node_allocations to be more explicit and to avoid confusion with the autofree terminology.
* lua: use an autofree wrapper instead of mp_lua_PITAAvi Halachmi (:avih)2020-03-221-38/+51
| | | | | | | | | | | | | | | | | | | Advantages of this approach: - All the resources are released right after the function ends regardless if it threw an error or not, without having to wait for GC. - Simpler code. - Simpler lua setup which most likely uses less memory allocation and as a result should be quicker, though it wasn't measured. This commit adds the autofree wrapper and uses it where mp_lua_PITA was used. It's not yet enforced at the C level, there are still redundant talloc_free_children leftovers, and there are few more places which could also use autofree. The next commits will address those.
* encode: fix occasional init crash due to initialization order issueswm42020-03-222-9/+7
| | | | | | | | Looks like the recent change to this actually made it crash whenever audio happened to be initialized first, due to not setting the mux_stream field before the on_ready callback. Mess a way around this. Also remove a stray unused variable from ao_lavc.c.
* lua: restore recent end-file event, and deprecate itwm42020-03-224-6/+18
| | | | | | | | | | | | Lua changed behavior for this specific event. I considered the change minor enough that it would not need to go through deprecation, but someone hit it immediately and ask on the -dev channel. It's probably better to restore the behavior. But mark it as deprecated, since it's problematic (mismatch with the C API). Unfortunately, no automatic warning is possible. (Or maybe it is, by playing sophisticated Lua tricks such as setting a metatable and overriding indexing, but let's not.)
* ci: remove missed remnants of libass from the macOS script as wellJan Ekström2020-03-221-1/+1
|
* ci: remove libass enablementJan Ekström2020-03-222-2/+0
| | | | This is no longer a configurable option.
* travis: shut the fuck upwm42020-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Travis is currently having "problems" and is spamming IRC all the time with pointless failure notifications. Make it so that it hopefully sends a message only when it goes from success to failure, which should exclude these cases. While I'm at it, I'd like to complain how idiotic it is to store CI configuration in a project's source repository. Such a repository should only contain things that are inherently part of the code's function, not part of the organization. You don't store bug reports, build results, the website, developer access controls, etc. in this repository either. But for CI it's supposed to be OK? I'm all for this "configuration as code" thing, but what it should mean is that you store configuration files in some git managed repository, NOT necessarily that you dump them into the main source code repo. There are many arguments why it should not be there, such as this very commit. I have a feeling this is mostly just because all these idiotic web services just want to advertise their shit and bind customers by not giving easy ways to treat source code and CI service configuration orthogonal. And so, the source code repo gets clobbered with stupid shit (both in the set of files and the commit history). It's fairly idiotic and my tolerance for it is waning. (Oh, of course you could probably jump through hoops to make it a separate repo, but I bet that is complicated and has all kinds of downsides because it won't be the way "it's meant to be used".)
* encode: deprecate encoding modewm42020-03-222-1/+3
| | | | | While I'd like to keep it, I'm apparently the maintainer now, and I have no idea what the heck some of this code does, so it's deprecated.
* encode: add some shit that does some shitwm42020-03-221-3/+6
| | | | | | | | ????????????? Makes no sense, can endless loop, but whatever. Part of #7524.
* encode: restore audio muxer timebase usewm42020-03-223-0/+12
| | | | | | Seems to crash hard if an error happens somewhere at init. Who cares. Part of #7524.
* encode: fix whitespacewm42020-03-221-1/+1
|
* js: make wait_event autofreeAvi Halachmi (:avih)2020-03-221-6/+5
| | | | | | | | | | | | The VM could throw at pushnode and before mpv_free_node_contents, which would have resulted in leaked content. Now this case is handled without leaks. Note: the lua code still leaks on such case, but mp_lua_PITA doesn't have destructors like the JS autofree has, which, specifically here, can do mpv_free_node_contents. So TODO: enhance the lua PITA code to behave more similar to the JS autofree.
* js: use unified events (match 218d6643, 8a58a699)Avi Halachmi (:avih)2020-03-211-98/+4
|