summaryrefslogtreecommitdiffstats
path: root/video/out/vo.h
Commit message (Collapse)AuthorAgeFilesLines
* vo: add win32 context menu supportShuanglei Tao2024-04-061-0/+4
|
* vo: move target_params into responsibility of VOsfan52024-03-161-2/+4
| | | | | | | | | The VO generic code tries to be helpful and resets this after each reconfig. However for the simpler VOs the target params are constant after a reconfig or even for the entire lifetime. So it's clearly better to let the VO decide. This also allows the VO to use a static buffer instead.
* vo: add video-target-params propertyKacper Michajłow2024-03-071-0/+2
|
* command: add begin-vo-dragging commandnanahi2024-03-011-0/+3
| | | | | | This command initializes a vo dragging request for VOs that implement the new VOCTRL_BEGIN_DRAGGING voctrl. This allows scripts to begin vo dragging for any button press event.
* vo: remove VOCTRL_SET_EQUALIZER and simplify into UPDATE_VIDEODudemanguy2024-02-171-2/+0
| | | | | | | | | | | | | | | Since 03cf150ff3516789d581214177f291d46310aaf4, the only purpose of this VOCTRL was to signal a redraw to the vo. It actualy could have been removed in 531868fe0d2a35fbbff78d9a9ff8f96df73e69fd, but this was missed. The UPDATE_VIDEO flag is better anyway because it allows us to handle a wide variety of options scattered around that require the VO to update itself and redraw. We can remove both of the custom callbacks in vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that commit also introduced vo_set_want_redraw, but this is redundant and not needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set vo->want_redraw, and those are the only VOs where these options are relevant in the first place. So we can remove this as well and just let the big callback in player/command do everything.
* Reapply "video: remove another redundant wakeup"Kacper Michajłow2024-02-151-0/+1
| | | | This reverts commit 44c398c3e133379e01f06c89fd78b6692694849c.
* player: ensure runtime updates of certain rendering optionsDudemanguy2024-02-051-0/+1
| | | | | | | | | | When adding things like brightness or gamma, the video obviously needs a redraw if paused. This happened to work in the normal case because the OSD notification triggered a redraw, but if you use no-osd the picture won't change. Fix this by adding another option flag, UPDATE_VIDEO, and simply signalling we want a redraw. This gets handled along with the normal osd redrawing check in the playloop so something like "no-osd add gamma 1" actually works.
* vo: change vo_frame duration to doubleKacper Michajłow2024-01-271-1/+1
| | | | | | | 32-bit signed integer can hold ~2.1s stored as nanoseconds. While frame duration doesn't make sense to be this long, the existing clamp is to 10s. Change type to double, which is consistent with other fields in vo_frame.
* command: export current-gpu-context propertynanahi2024-01-201-0/+3
| | | | | | | This exports `current-gpu-context` property, which is the string description of the current active GPU context. This allows scripts to uniquely identify the platform and backend used for --vo=gpu and --vo=gpu-next.
* vo: add params mutexKacper Michajłow2023-11-221-1/+9
| | | | | | | | | | | | This mostly is added to resolve player command synchronization with VO thread discussed in 477a0f83. The current uses does not necessarily need this as they are all managed by playloop. But for future use with other params that will be handy. Those params are mostly to observe current state of VO and does not necessarly need to be locked along with frame drawing, that changes the params once at the end.
* vo: pass approximate frame duration in vo_frameKacper Michajłow2023-11-181-0/+2
| | | | | | This information is already there, but speed adjusted. To avoid duplicating the calculation of frame duration, it's kept in the vo_frame structure.
* vo: add frame vsync and vsync durationKacper Michajłow2023-11-111-0/+4
| | | | | | | | Relative to frame PTS timeline as oposed to display vblank. Those values are relative to unadjusted video timeline. They will be used by gpu-next where it expect virtual frame vsync, not display vblank time.
* cocoa: remove OpenGL cocoa backendder richter2023-11-101-1/+0
| | | | | | the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is completely unmaintained and can't properly playback anything anymore on the newest macOS. it is time to remove it.
* vo: replace VOCTRL_HDR_METADATA with direct VO params readKacper Michajłow2023-11-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently VOCTRL are completely unusable for frequent data query. Since the HDR parameter addition to video-params, the parameters can change each frame. In which case observe on those parameter would be triggered constantly. The problem is that quering those parameters involves VOCTRL which in turn involves whole render cycle of delay. Instead update VO params on each draw_frame. This requires changes to VO reconfiguration condition, but in practice it should only be triggered when image size or data layout changes. In other cases it will be handled internal by VO driver. I'm not quite happy with this solution, but don't see better one without changing observe/notify logic significantly. There is no good way currently to handle VOCTRL that are constantly queried. This adds unfortunate synchronization of player command with VO thread, but there is not way around that and if too frequent queries of this param becomes a problem we can thing of other solutions. Changes the way to get data from VO driver added by a98c5328dc Fixes: 84de84b Fixes: #12825
* vo: replace max swapchain depth magic numberDudemanguy2023-11-071-0/+1
|
* csputils: change mp_hdr_metadata to pl_hdr_metadataKacper Michajłow2023-11-051-1/+1
|
* vo: define <= 0 as unsupported for last_queue_display_timeKacper Michajłow2023-10-231-1/+1
| | | | Also sanitize vsync values, just in case.
* vd_lavc: align buffers to multiple of image sizeNiklas Haas2023-10-191-2/+2
| | | | Fixes: https://github.com/mpv-player/mpv/issues/12672
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-1/+1
| | | | | | | | | | | | In many cases, this is purely cosmetic because poll still only accepts microseconds. There's still a gain here however since pthread_cond_timedwait can take a realtime ts now. Additionally, 37d6604d70c8c594de2817db26356c4c950ac0fd changed the value added to timeout_ms in X11 and Wayland to ensure that it would never be 0 and rounded up. This was both incomplete, several other parts of the player have this same problem like drm, and not really needed. Instead the MPCLAMP is just adjusted to have a min of 1.
* vo: use nanoseconds for frame duration and ptsDudemanguy2023-10-101-3/+3
|
* Revert "video: remove another redundant wakeup"Kacper Michajłow2023-10-071-1/+0
| | | | | | | | | | | | | | | vo_still_displaying() is racey with vo_request_wakeup_on_done() and above that it doesn't work as expected. VO can run out of work and go to sleep for 1000s, while the play thread still returns on vo_still_displaying() check, because of a check `now < frame_end` so it never advances and go to sleep itself. This fixes dead lock that we have when image parameters changes during playback. This reverts commit 0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3. Fixes: #12575
* vo_gpu_next: improve updating overlaysDudemanguy2023-10-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | fbe154831a8addfc18a4f81e1c4b9284c31acace added a new VOCTRL to signal when the OSD changed for gpu-next's handling of subtitles, but this is both not necessary and actually incomplete. The VOCTRL would signal OSD changes, but not all subtitle changes (like selecting another non-external sub track for example). VOCTRL_OSD_CHANGED was used to increment p->osd_sync which would then redraw the blended subtitles if the player was paused. But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the sub_bitmap_list object will have items in it if it changed in any way, so we don't need the VOCTRL_OSD_CHANGED method at all. That can be removed. The check that fp->osd_sync < p->osd_sync stays in place since that's an optimization while the video is playing, but we also check the pause state as well since the VO can know this. If we're paused, then always do update_overlays since core must be signalling a redraw to us if we get a draw_frame call here. Additionally in update_overlays itself, the p->osd_sync counter is incremented if we have any items since the frame signature will need that. As for the actual bug that is fixed, changing subtitle tracks while paused with blended subtitles now correctly works. Previously, it was never updated so the old subtitle stayed there forever until you deselected it (since VOCTRL_OSD_CHANGED triggered there). Also include some cosmetic code fixes that were noticed.
* vo_dmabuf_wayland: eliminate an extra frame copyDudemanguy2023-10-031-1/+5
| | | | | | | | | | | | | | When implementing vo_dmabuf_wayland, it always did a copy of the image from the current frame and worked with that. The reason was because mpv's core held onto the frame and caused some timing issues and rendering glitches depending on when it freed the image. This is pretty easy to fix: just make vo_dmabuf_wayland manage the the frames. In vo.h, we add a boolean that a VO can set to make them manage freeing frames directly. After doing this, change the buffers in vo_dmabuf_wayland to store the whole vo_frame instead of just the image. Then, just modify some things a bit so frame is freed instead of the image. Now, we should truly have zero-copy playback. Well as long as you don't use libass to render anything (that's still a copy from system memory).
* vo: fully replace draw_image with draw_frameDudemanguy2023-10-011-16/+0
| | | | | | | | | | | | 0739cfc20934ac7772ab71dbae7ecba4ba10fda4 added the draw_frame API deprecated draw_image internally. VOs that still used draw_image were around, but really there's no reason to not just "upgrade" them anyway. draw_frame is what the "real" VOs that people care about (gpu/gpu-next) use. So we can just simplfy the code a bit now. VOCTRL_REDRAW_FRAME is also no longer needed so that can be completely deleted as well. Note that several of these VOs are legacy crap anyway (e.g. vaapi) and maybe should just be deleted but whatever. vo_direct3d was also completely untested (not that anyone should ever use it).
* vo: change vsync base to nanosecondsKacper Michajłow2023-09-291-2/+2
| | | | | There is no reason to use microseconds precision. We have precise timers all all relevant platforms.
* vo: change vsync_interval to doubleDudemanguy2023-09-091-1/+1
| | | | | | | | | | | | | | | So strangely enough, estimated_vsync_interval is stored as a double but nominal_vsync_interval is not and neither is the vsync_interval. Those are stored as int64_t. This loss of precision can matter even in common cases. For instance, take a typical 60 Hz monitor. Instead of 16666.6666 (repeating) being calculated as the vsync interval, you would get 16666 since the decimals are truncated. This is not really good at all and affects the calculated speed values you get when using display sync. For consistency and better precision, these should all be doubles just like estimated_vsync_interval. Technically this means that we won't be able to store as high of an integer value but such values would be absurdly huge and never actually needed. Also estimated_vsync_interval already can't handle such a case anyway.
* vo: add VOCTRL_HDR_METADATA to get mp_hdr_metadataKacper Michajłow2023-08-291-0/+2
|
* vo: make mp_frame_perf thread safeKacper Michajłow2023-05-251-4/+2
| | | | | | | It was unsafe to return pointer to memory that was freed on another thread, just copy the string to caller owned sturcture. Fixes crashes when displaying passes stats with gpu-next.
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* player/screenshot: pass on ability to output native CSPNiklas Haas2023-02-131-1/+1
| | | | Fixes: #10988
* vd_lavc: add "auto" choice for vd-lavc-drsfan52023-01-231-0/+5
| | | | | | | | | | | | --vd-lavc-dr defaulted to "yes", which caused issues on certain hardware. Instead of disabling it, add a new "auto" value and make it the default. The "auto" choice will enable DR only when we can request host-cached buffers (as signalled by the new VO_DR_FLAG_HOST_CACHED). Co-authored-by: Nicolas F. <ovdev@fratti.ch> Co-authored-by: Niklas Haas <git@haasn.dev>
* vo: add `int flags` to the get_image signatureNiklas Haas2023-01-231-3/+5
| | | | | This is a huge disgusting mess to thread through everywhere. Maybe I'm stupid for attempting to solve the problem this way.
* drm: rewrite based around vo_drm_stateDudemanguy2023-01-211-0/+1
| | | | | | | | | | | A longstanding pain point of the drm VOs is the relative lack of state sharing. While drm_common does provide some sharing, it's far less than other platforms like x11 or wayland. What we do here is essentially copy them by creating a new vo_drm_state struct and using it in vo_drm and context_drm_egl. Much of the functionality that was essentially duplicated in both VOs/contexts is now reduced simple functions in drm_common. The usage of the term 'kms' was also mostly eliminated since this is libdrm nowadays from a userspace perspective.
* player: add window-id propertyNRK2022-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | currently only supported on x11. one practical use-case of this is wanting to embed something (such as dmenu) into the mpv window to use as a menu/selection. there might be other use-cases as well (e.g doing some shenanigans with `xdotool` or whatnot). it's currently possible to: * listen for 'current-window-scale' change (to check if the window has been created or not) * call an external tool like `xdo` or `xdotool` and grab the xid from mpv's pid. however it adds unnecessary dependency on external tools when mpv is fully capable of easily providing this information. closes: #10918
* player/video: add VOCTRL_CONTENT_TYPEDudemanguy2022-11-151-0/+9
| | | | | | | | | | | | mpv's core already keeps track of whether or not it thinks a track is an image. Some VOs (i.e. wayland) would benefit from knowing if what is currently being displayed is an image or not so add a new VOCTRL that signals this anytime we load a new file with a VO. Additionally, let's add a helper enum for signaling the kind of content that is being displayed. There is now MP_CONTENT_NONE (strictly for force window being used on a track with no image/video), MP_CONTENT_IMAGE, and MP_CONTENT_VIDEO. See the next commit for the actual usage of this (with wayland).
* vd_lavc: add vo caps and option to set GPU film grain applicationLynne2022-04-051-0/+2
|
* vo_gpu_next: refactor subtitle renderingNiklas Haas2022-02-211-0/+3
| | | | | | | | | | | | | | | Render subs at the output resolution, rather than the video resolution. Uses the new APIs found in libplacebo 197+, to allow controlling the OSD resolution even for image-attached overlays. Also fixes an issue where the overlay state did not get correctly updated while paused. To avoid regenerating the OSD / flushing the cache constantly, we keep track of OSD changes and only regenerate the OSD when the OSD state is expected to change in some way (e.g. resolution change). This requires introducing a new VOCTRL to inform the VO when the UPDATE_OSD-tagged options have changed. Fixes #9744, #9524, #9399 and #9398.
* vo_gpu_next: implement VOCTRL_EXTERNAL_RESIZEsfan52021-12-191-1/+1
| | | | | | This is only needed on Android and supposed to handle a context resize without reconfiguring the image parameters. reconfig() already does exactly this so plug it in there.
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-151-1/+1
|
* command: add display-width/display-height propertyDudemanguy2021-05-061-0/+1
| | | | | | | | | For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES and use it to obtain the current display's resolution from each vo/windowing backend if applicable. Users can then access the current display resolution as display-width and display-height as per the client api. Note that macOS/cocoa was not attempted in this commit since the author has no clue how to write swift.
* vo_vdpau: remove deprecated/inactive --vo-vdpau-deint optionwm42020-09-091-2/+0
| | | | | I think this has been dead code for quite a while. It was deprecated anyway.
* command: add read-only focused propertyGuido Cella2020-09-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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().
* video: remove another redundant wakeupwm42020-04-101-0/+1
| | | | | | | | | | | | | | | 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).
* vo: fix typo in commentwm42020-02-091-1/+1
|
* command, vo: add a mechanism for runtime DPI scale changeswm42020-01-091-3/+3
| | | | | Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
* command: add property returning hidpi scalewm42019-12-201-0/+1
|
* command, vo: remove old option change notification mechanismswm42019-12-171-13/+1
| | | | | | | These all have been replaced recently. There was a leftover in window.swift. It couldn't have done anything useful in the current state of the code, so drop these lines.
* wayland: update Maximize and Minimize handling to use new optionsPhilip Langdale2019-12-011-3/+0
| | | | | | | | | | | I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
* command: change window-minimized/window-maximized to optionswm42019-11-291-4/+3
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* x11: use new option stuff to implement fullscreenwm42019-11-291-4/+8
| | | | | | | | | | | | | | | - remove VOCTRL_FULLSCREEN and VOCTRL_GET_FULLSCREEN - have your own m_config_cache for the fullscreen option (vo->opts_cache cannot be used because you lose per-option change notifications, and it'd be a mess anyway) - use VOCTRL_VO_OPTS_CHANGED to update it (it's used for convenience) - when updating it, check for the fullscreen option (wasn't sure how to do it best; currently, it compares the raw option pointers, but this could be changed) - do not send VO_EVENT_FULLSCREEN_STATE on FS change - instead write the option on FS change (assign in opt. struct + m_config_cache_write_opt)
* command: add `window-maximized` and make `window-minimized` settablePhilip Langdale2019-11-291-1/+5
| | | | | | | | | | | If we want to implement window pseudo-decorations via OSC, we need a way to tell the vo to minimize and maximize the window. Today, we have minimized as a read-only property, and no property for maximized. Let's made minimized settable and add a maximized property to go with it. In turn, that requires us to add VOCTRLs for minimizing or maximizing a window, and an additional WIN_STATE to indicate a maximized window.
* Revert "vo: add support for externally driven renderloop and make wayland ↵dudemanguy2019-10-101-3/+0
| | | | | | | | | | use it" The externally driven renderloop was originally added for the wayland context (to make display sync somewhat work), but it has a lot of issues with mpv's internal structure. A different approach should be used. This reverts commit a743fef837bcab206b1e576db7e7a64b02890449.
* context_android: move common code to a separate filesfan52019-09-271-0/+1
| | | | | | In preparation for a Vulkan Android context. This also replaces querying for EGL_WIDTH and EGL_HEIGHT with equivalent ANativeWindow calls.
* vo: remove unused equalizer control remainswm42019-09-201-14/+1
| | | | | | | | | | Equalizer control was redone in 03cf150ff3516789d5812 (over 2 years ago). Ever since, the equalizer control structs and the GET voctrl have been unused. Only the SET voctrl is still used as notification mechanism (actually a bad hack to avoid some further option change handling complexity). Remove the unused parts.
* vo, vo_gpu, glx: correct GLX_OML_sync_control usagewm42018-12-061-11/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I misunderstood how this extension works. If I understand it correctly now, it's worse than I thought. They key thing is that the (ust, msc, sbc) tripple is not for a single swap event. Instead, (ust, msc) run independently from sbc. Assuming a CFR display/compositor, this means you can at best know the vsync phase and frequency, but not the exact time a sbc changed value. There is GLX_INTEL_swap_event, which might work as expected, but it has no EGL equivalent (while GLX_OML_sync_control does, in theory). Redo the cont