summaryrefslogtreecommitdiffstats
path: root/video/out/vo.c
Commit message (Collapse)AuthorAgeFilesLines
* vo: move target_params into responsibility of VOsfan52024-03-161-4/+0
| | | | | | | | | 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/+14
|
* vo: make libmpv last in the auto-probing order for cocoa-cb onlyder richter2024-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | this partially reverts commit 7b5a258. back then the only properly working vo on macOS was cocoa-cb (libmpv). it would always use the deprecated opengl cocoa backend or no vo at all. because of that libmpv was moved to the top of the auto-probing order, so the preferred vo was used on macOS only. we now have a working vulkan gpu/gpu-next backend on macOS which should be the new default vo. though disabling the auto-probing again for libmpv would probably cause the undesired behaviour on macOS that cocoa-cb would never be auto selected again. especially if not build with vulkan support or without vulkan driver on macOS, this would lead to no video output at all. so instead of completely reverting the mentioned commit, we instead move libmpv to the bottom of the auto-probing order but only auto select it when mpv was built with cocoa-cb support. this restores the previous behaviour on all other platforms besides macOS, but also lets us auto select cocoa-cb if supported.
* vo: remove VOCTRL_SET_EQUALIZER and simplify into UPDATE_VIDEODudemanguy2024-02-171-28/+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.
* vo: ensure that frames are not eaten on reconfigKacper Michajłow2024-02-151-13/+41
| | | | | | | | | | | | | | | | | | | | This avoids clearing the queued frame and the currently displayed one on VO reconfiguration requests that happen when new frames arrive. Instead, let those frames be fully displayed. Fixes mf:// playback issues introduced after commit ef11d31. Instead of removing the frame timing check embrace and fix it to wake up the playloop as needed. The frame display duration is problematic to handle as both VO and playloop thread would already be sleeping, but in certain use cases it is needed to display frames in full, so in this case, let the VO sleep to the end of frame, wake up the core as requested and go back sleeping. Note that this patch series reintroduces 0c9ac5835, which is esenitally fixed in this commit. It is still not perfect, but it is better than just busy waiting on playloop, even if those events when this would be needed are quite rare.
* Reapply "video: remove another redundant wakeup"Kacper Michajłow2024-02-151-19/+41
| | | | This reverts commit 44c398c3e133379e01f06c89fd78b6692694849c.
* Revert "vo: remove frame timing check from vo_still_displaying()"Kacper Michajłow2024-02-151-3/+10
| | | | This reverts commit ef11d31c3acfd71307a94e44ad164a4861287675.
* player: remove all rpi-specific codeDudemanguy2024-02-051-4/+0
| | | | | | | | | | | | | | | | | | | | | | vo_rpi and its related code has pretty much historically been a disaster in mpv. The build regularly gets broken and since nobody uses it, it takes months for anyone to notice. There was also that time where fullscreen was broken for about a year and a half. Also building in waf was entirely broken for about a couple of years or so due to mysterious reasons no one ever figured out (meson magically fixed it). Anyways, once again the build is broken due to rpi being forgotten about again, but instead of pretending to support this crap. Just drop it all. Nowadays, mmal hwdec is a relic since these devices are better off using the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1 and 2 probably can't do this and will remain broken but oh well blame Broadcom for being special snowflakes and not using standard APIs (my rockpro worked out of the box; just saying). RPI 2 is nearly 10 years old anyways, so I think you can afford a new SBC by now. If we were nicer, there would be a deprecation period, but this is broken in the last major release anyway so too late. Closes #13402.
* player: ensure runtime updates of certain rendering optionsDudemanguy2024-02-051-0/+10
| | | | | | | | | | 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: ensure a dropped frame is always freedDudemanguy2024-01-261-1/+1
| | | | | | | | | 7b8a30fc8132203bc93d35ac887682d2044ad5a9 made it possible for a VO to have direct ownership of frame objects since the it may be beneficial for the frame to follow the lifecycle of that particular VO instead (i.e. the wayland compositor for dmabuf-wayland). But when frames are dropped, this always has to be unconditionally freed since the VO isn't aware of it. Fixes #13364.
* vo: add params mutexKacper Michajłow2023-11-221-2/+8
| | | | | | | | | | | | 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: avoid overshooting the expected end of the frame during pauseKacper Michajłow2023-11-181-2/+7
| | | | | | The `current_frame` can be redrawn even if the remaining `num_vsync` is equal to 0. In this scenario, the vsync offset would be incremented beyond the target point.
* vo: delay vsync samples by at least 10 refreshesKacper Michajłow2023-11-141-1/+2
| | | | | | | | This filters out vastly inaccurate values from presentation feedback that can happen shortly after restarting playback or seeking. Makes estimated vsync converge almost instantly instead of waiting until those outliers are dropped from the past samples.
* vo: add frame vsync and vsync durationKacper Michajłow2023-11-111-0/+1
| | | | | | | | 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.
* vo: replace some magic numbers with timer macrosDudemanguy2023-11-091-5/+5
| | | | | | | | | | Most importantly, the wait_until addition was missed while doing the unit conversions to nanoseconds which meant mpv woke up roughly every second since not nearly enough time was added. It was meant to be 1000 seconds (1e9 in microseconds). Use a macro so it's more readable. Also put some other wild 1e9 calculations inside of a macro as well. Fixes a899e14bccb667af243f8fce454160e17ae45c2a.
* vo: replace VOCTRL_HDR_METADATA with direct VO params readKacper Michajłow2023-11-081-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: require successive vsyncs to be more than swapchain depthDudemanguy2023-11-071-1/+1
| | | | To make sure that present_sync is in line with the vsync timings here.
* Revert "vo: clear vsync_offset if drawing while paused"llyyr2023-11-061-3/+0
| | | | | | This reverts commit 640c07fb19b7ea11f1a97784e517c38449f816d0. This commit isn't needed anymore after the previous commit.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-94/+90
|
* options: rename --override-display-fps to --display-fps-overrideDudemanguy2023-10-251-1/+1
| | | | | | Other similar options are in the form of --foo-override not --override-foo. The display-fps one was backwards so flip it around the other way for consistency reasons.
* meson: make libplacebo a required dependencyllyyr2023-10-231-2/+0
| | | | | | | Make it not possible to build mpv without the latest libplacebo anymore. This will allow for less code duplication between mpv and libplacebo, and in the future also let us delete legacy ifdefs and track libplacebo better.
* vo: define <= 0 as unsupported for last_queue_display_timeKacper Michajłow2023-10-231-2/+12
| | | | Also sanitize vsync values, just in case.
* vo: change spammy log to traceKacper Michajłow2023-10-231-2/+2
|
* vo: average more vsync samplesKacper Michajłow2023-10-231-1/+1
| | | | Improves averaging on high refresh rate displays.
* various: sort some standard headersNRK2023-10-201-5/+5
| | | | | | | | | | | | since i was going to fix the include order of stdatomic, might as well sort the surrouding includes in accordance with the project's coding style. some headers can sometime require specific include order. standard library headers usually don't. but mpv might "hack into" the standard headers (e.g pthreads) so that complicates things a bit more. hopefully nothing breaks. if it does, the style guide is to blame.
* osdep: remove atomic.hNRK2023-10-201-1/+1
| | | | | | | replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with explicit _Atomic qualified types. also add missing config.h includes on some files.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-2/+2
| | | | | | | | | | | | 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-10/+10
|
* vo: remove vo_get_estimated_vsync_interval conversion to secondsDudemanguy2023-10-101-2/+1
| | | | | This is weird. The caller should be responsible for converting the value if desired. Move the conversion to player/command.c instead.
* vo: remove frame timing check from vo_still_displaying()Kacper Michajłow2023-10-071-10/+3
| | | | | This timing dependency does not guarantee that we will wake up in the future, depending on processing times.
* Revert "video: remove another redundant wakeup"Kacper Michajłow2023-10-071-41/+19
| | | | | | | | | | | | | | | 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-1/+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-2/+3
| | | | | | | | | | | | | | 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-13/+2
| | | | | | | | | | | | 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: don't invoke wait, when not neededKacper Michajłow2023-09-291-0/+3
| | | | | | | | This causes only problems, because we convert mp_time to realtime, which is not atomic, so we introduce error. And even though on sane platforms it should work fine, after all the sleep time is in the past. winpthreads like to sleep for like over 10ms when the time is less than current time, but not more than 1s.
* vo: increase display refresh rate estimation limit from 99 Hz to 400 HzKacper Michajłow2023-09-291-1/+1
| | | | High refresh rate displays exists...
* vo: change vsync base to nanosecondsKacper Michajłow2023-09-291-13/+13
| | | | | There is no reason to use microseconds precision. We have precise timers all all relevant platforms.
* timer: rename mp_time_us_to_timespec to reflect what it actually doesKacper Michajłow2023-09-291-2/+2
|
* vo: avoid unnecessary redraws when the OSD showsDudemanguy2023-09-191-6/+6
| | | | | | | | | | | | | | | | 296d40dc6f38401085d005bb4627f8afff46b041 changed how the vo handled redraw requests in order to fix a race condition that can occur with pausing. However, there was a slight oversight because a redraw request that occurred while the core was unlocked and the video was still playing would still be kept true (previously, this was always cleared). That redraw is essential if mpv is paused otherwise the old issue comes back, but if the video is playing it's unnecessary since the next loop around will simply draw whatever we needed. The extra redraw could cause a frame drop for some people in certain instances, so the solution is to simply always clear redraw requests if !in->paused. This eliminates the extra redraw but still keeps it when pausing. Fixes #12426 and fixes #11579.
* vo: change vsync_interval to doubleDudemanguy2023-09-091-11/+11
| | | | | | | | | | | | | | | 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.
* meson: remove redundant libplacebo-next checkNiklas Haas2023-08-181-1/+1
| | | | Now implied by the minimum libplacebo version.
* vo: clear vsync_offset if drawing while pausedDudemanguy2023-08-161-0/+3
| | | | | | | | | | | | | | | libplacebo doesn't like it when the queue_params PTS is less than the actual PTS of the frame for the first frame and skips mixing it during interpolation. This can happen if you seek while paused because mpv will always keep the vsync_offset value as if it was still playing. So in some cases, this can be a negative value and thus the PTS will end up decreasing and libplacebo interprets this frame as a first frame. This skips mixing the frame and thus you get a black screen. To fix this this, just realize that vsync timings are completely meaninglessly in while paused. If you are not actively pushing frames, there's no reason to care about vsync_offset. So just clear it and make it zero when the VO's internal state is paused and we're trying to render a frame. Makes libplacebo happy and fixes #11958.
* mp_image: abort on av_buffer_ref() failureNRK2023-06-281-3/+1
| | | | | | | | | | | | | | this changes mp_image_new_ref() to handle allocation failure itself instead of doing it at its many call-sites (some of which never checked for failure at all). also remove MP_HANDLE_OOM() from the call sites since this is not necessary anymore. not all the call-sites have been touched, since some of the caller might be relying on `mp_image_new_ref(NULL)` returning NULL. Fixes: https://github.com/mpv-player/mpv/issues/11840
* vo: fix race condition with redraw requestsDudemanguy2023-03-021-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a very subtle race in vo that can manifest itself on pause events. In the renderloop, render_frame, unsurprisingly, does the heavy lifting of actually queuing up and flipping the frames. This is called during normal playback. Sometimes various parts of the player can make a redraw request which will latter trigger another render of the frame later down in the loop (do_redraw). Because these requests can happen at essentially anytime, sometimes the redraw request will happen *before* do_redraw and it'll be caught in render_frame. When this happens, the existing render_frame run works perfectly fine as a redraw so it clears out the request which is sensible. Normally this is all locked of course, but there's one catch. render_frame has to unlock itself when propagating down into specific VOs/backends. That's what causes this bug. While render_frame is unlocked, other parts of the player can send redraw requests which will cause in->request_redraw to become true. The logic in the code always clears out this parameter after a successful render, but this isn't correct. When in->request_become becomes true in the middle of render_frame, there needs to be one more draw afterwards to reflect whatever actually changed (usually the OSD). Instead, this gets simply discarded. If you rapidly spam pause while rendering things to the OSD at the same time, it's possible to for the last render to be behind a frame and appear as if your osd event was ignored. Once you realize what is happening, the fix is quite simple. Just store the initial value of in->request_redraw before the unlock step. After we do the render step and unlock again, only set in->request_redraw to false if there was an initial redraw request. We just finished doing a redraw, so it is safe to clear. Otherwise, leave in->request_redraw alone. If it is initially false, then it will still be false and nothing changes. However if it updated to true in the middle of the rendering, this value is now preserved so we can go and call do_redraw later and show what that last frame was meant to be when you pause. One unfortunate thing about this design is that it is technically possible for other internal things in vo to update during that unlocked period. Hopefully, that doesn't actually happen and only redraw requests work like this. Fixes #8172 and #8350.
* vo: add `int flags` to the get_image signatureNiklas Haas2023-01-231-5/+5
| | | | | This is a huge disgusting mess to thread through everywhere. Maybe I'm stupid for attempting to solve the problem this way.
* vo: make driver list staticThomas Weißschuh2023-01-161-1/+1
|
* vo: remove trailing NULL element from driver arrayThomas Weißschuh2023-01-161-3/+2
|
* various: replace if + abort() with MP_HANDLE_OOM()sfan52023-01-121-2/+1
| | | | | MP_HANDLE_OOM also aborts but calls assert() first, which will result in an useful message if compiled in debug mode.
* vo_kitty: Introduce modern sixel alternativeMia Herkt2022-12-211-0/+2
| | | | | | | | | | | | | See https://sw.kovidgoyal.net/kitty/graphics-protocol/ This makes no attempt at querying terminal features or handling terminal errors, as it would require mpv to pass the response codes from the terminal to the vo instead of interpreting them as keystrokes made by the user and acting very unpredictably. Tested with kitty and konsole. Fixes #9605
* vo_vaapi_wayland: remove, as it is superceded by vo_dmabuf_waylandAaron Boxer2022-10-261-4/+0
|
* vo_dmabuf_wayland: wayland VO displaying dmabuf buffersAaron Boxer2022-10-261-1/+5
| | | | | | | | | | | | | Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
* vo: allow vaapi_wayland and vaapi_x11 to coexistAaron Boxer