summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* github/workflows: workaround git permissions errorDudemanguy2022-04-211-0/+2
| | | | | | | | | | Recently, git patched a CVE which makes it much more strict about different users operating on directories they don't own. For us, this causes breakage with version.sh and version.py since they both run a git describe command to fetch the commit hash. Currently, this only affects the tumbleweed container (likely because it was recently changed) and thus the git describe command always errors out. Workaround this by just explictly adding the mpv directory as a safe directory for git.
* DOCS/options: update the --load-osd-console documentationGuido Cella2022-04-211-4/+3
| | | | | | | | | | - Say built-in which is more common than builtin - Move "By default" because only the key to open the console is customizable, and fix the punctuation and case of the sentence - ` opens the console, not ´ - Remove the sentences that explains which user script console.lua is based on since it's no longer relevant now that the console has been part of mpv for over 2 years.
* DOCS/input: update the ASS tags documentation URLGuido Cella2022-04-211-1/+2
| | | | The current one hasn't worked in years.
* options: make --cover-art-auto=exact the defaultGuido Cella2022-04-212-3/+3
| | | | | | | | | Now that a separate --cover-art-whitelist option exists, files like cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so only load files that have exactly the media filename by default, since fuzzy loading is probably more likely to load unwanted images than to load cover art that the user intended to display, especially if you play audio files with a short filename like a.mp3.
* player: add cover-art-whitelist optionGuido Cella2022-04-214-3/+12
| | | | | | | | This allows more fine grained control over which cover art to load. With --cover-art-auto=exact and --cover-art-whitelist=yes, you can now load cover art with the exact media filename and the whitelisted filenames, but not cover art that contains the media filename (--cover-art-auto=fuzzy).
* DOCS: fix the typo of --sub-justifyhooke0072022-04-211-1/+1
|
* DOCS: correct --sub-shadow-colorhooke0072022-04-211-6/+6
|
* DOCS/{mpv,options}: document the watch later functionalityGuido Cella2022-04-213-67/+99
| | | | | | | | | | This adds a section to the documentation to explain how resuming playback works, and in particular it explains how it affects which playlist entry mpv starts playing from, since this feature was only implied in the --playlist-start documentation. It also groups the documentation of the watch later options together to make them easier to find.
* vo_wlshm: use draw_frame instead of draw_imageDudemanguy2022-04-211-3/+3
| | | | | | | | draw_image is an old API that was deprecated long ago. However when wlshm was originally added, it used draw_image. There's no particular reason for this and it can trivially be switched to draw_frame instead. This has some real advantages (notably --vo=wlshm --idle --force-window actually works).
* mpv.desktop: add japanese translationDudemanguy2022-04-211-0/+3
|
* ci: switch Tumbleweed build to openSUSE container registryMia Herkt2022-04-191-1/+1
|
* vd_lavc: fixup unchecked usage of AV_CODEC_EXPORT_DATA_FILM_GRAINJan Ekström2022-04-131-0/+7
| | | | | | | | | | | | | | This fixes build failures with avcodec 58.113.100 or before, matching FFmpeg release versions 4.0 to 4.3. This flag was added in between avcodec 58.113.100 and 58.114.100 during the FFmpeg 4.4 development cycle. It lacks its own version bump, so instead a check for the define is utilized instead. Additionally, warn the user if they request GPU film grain with too old of an FFmpeg. Fixes #10088
* vd_lavc: fix decoder initialization when no VO is availableJan Ekström2022-04-111-6/+20
| | | | | | | | | | | | | | | | | The VO is available during decoder initialization mostly for direct rendering purposes, so if f.ex. a complex filter chain is utilized, there is no video renderer information available via mp_filter_find_stream_info during creation of the decoder filter. Thus, check for whether the VO is available before attempting to check the capabilities flag from it. Additionally - to simplify logic - makes explicitly requesting GPU film grain to always disable decoder film grain functionality. The warning is still shown if the VO is available and no support for film grain application is available. Fixes #10079
* vd_lavc: remove duplicate vd_ffmpeg_ctx pointer from init_avctxJan Ekström2022-04-111-2/+1
| | | | | Seems like in some functions this was called p and in others ctx, and thus it was added as the `p` pointer was not available.
* wayland: use wl_output v4 for --fs-screen-nameDudemanguy2022-04-111-3/+30
| | | | | | | | | | In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
* x11: avoid wasteful rendering when possibleDudemanguy2022-04-117-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because wayland is a special snowflake, mpv wound up incorporating a lot of logic into its render loop where visibilty checks are performed before rendering anything (in the name of efficiency of course). Only wayland actually uses this, but there's no reason why other backends (x11 in this commit) can't be smarter. It's far easier on xorg since we can just query _NET_WM_STATE_HIDDEN directly and not have to do silly callback dances. The function, vo_x11_check_net_wm_state_change, already tracks net wm changes, including _NET_WM_STATE_HIDDEN. There is an already existing window_hidden variable but that is actually just for checking if the window was mapped and has nothing to do with this particular atom. mpv also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same as being minimized but according to the spec, that's not neccesarily true (in practice, it's likely that these are the same though). Anyways, just keep track of this state in a new variable (hidden) and use that for determing if mpv should render or not. There is one catch though: this cannot work if a display sync mode is used. This is why the previous commit is needed. The display sync modes in mpv require a blocking vsync implementation since its render loop is directly driven by vsync. In xorg, if nothing is actually rendered, then there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so it returns immediately. This, of course, results in completely broken video. We just need to check to make sure that we aren't in a display sync mode before trying to be smart about rendering. Display sync is power inefficient anyways, so no one is really being hurt here. As an aside, this happens to work in wayland because there's basically a custom (and ugly) vsync blocking function + timeout but that's off topic.
* player: rearrange video sync opts/enums/definesDudemanguy2022-04-116-32/+32
| | | | | | | | | | | | | | | | | The video sync logic for mpv lies completely within its core at essentially the highest layer of abstraction. The problem with this is that it is impossible for VOs to know what video sync mode mpv is currently using since it has no access to the opts. Because different video sync modes completely changes how mpv's render loop operates, it's reasonable that a VO may want to change how it renders based on the current mode (see the next commit for an example). Let's just move the video sync option to mp_vo_opts. MPContext, of course, can still access the value of the option so it only requires minor changes in player/video.c. Additionally, move the VS_IS_DISP define from to player/core.h to common/common.h. All VOs already have access to common/common.h, and there's no need for them to gain access to everything that's in player/core.h.
* wayland: unify visibility checking codeDudemanguy2022-04-117-23/+33
| | | | | | | | | | | A bit of a personal pet peeve. vulkan, opengl, and wlshm all had different methods for doing wayland's "check for visibility before drawing" thing. The specific backend doesn't matter in this case and the logic should all be shared. Additionally, the external swapchain that the opengl code on wayland uses is done away with and it instead copies vulkan by using a param. This keeps things looking more uniform across backends and also makes it easier to extend to other platforms (see the next couple of commits).
* vo_gpu/d3d11: add message ID based log level mappingJan Ekström2022-04-111-6/+64
| | | | | | | | | | | | | This lets us remap various messages which might now be happening at each frame onto the trace level, thus unaffecting the initial debug log level. Additionally - thanks to this ability - the previously globally denied message queue abandonment messages can now be handled and mapped to trace log level, as on that log level they may be of use. Recommended by rossy and based on his libplacebo commit 6d72f6445566eddb0493447d0bda72d98a99d40c .
* vo_gpu/d3d11: mimic libplacebo backbuffer usageJan Ekström2022-04-111-7/+10
| | | | | | Instead of always having the reference outside of calling resize, request a backbuffer at start and relieve the backbuffer at submission for presentation.
* vo_gpu/d3d11: enable receival of color depth without active backbufferJan Ekström2022-04-111-2/+12
| | | | | | | Query the description of the swap chain, which should in all theory contain the format of the backbuffer. Then utilize a newly added ra_d3d11 function to map the format to an ra_format. After that, utilize the depth of the first plane of the format, as previously.
* vo_gpu/d3d11: add helper function to get ra_format from DXGI_FORMATJan Ekström2022-04-112-0/+16
|
* vo_gpu_next: switch to unpooled hwdec mappingNiklas Haas2022-04-115-69/+90
| | | | | | | | | | | | This makes use of the new frame acquire/release callbacks to hold on to hwdec images only as long as necessary. This should greatly improve the smoothness/efficiency of hwdec interop, by not holding on to them for longer than needed. This also avoids the need to pool hwdec mappers altogether. Should fix #10067 as well, since frames are now only mapped when we actually use them.
* x11: fix screen-name optionDudemanguy2022-04-081-0/+1
| | | | | | | | | | | 9a7b2015e1a711a57b6e660774c36956ac59a7f6 added the --screen-name option for x11, but it was unfortunately broken. The commit does correctly handle vo_x11_update_screeninfo and select the correct screen. However, vo_x11_sizehint was missed. Specifically, the force_pos bool was always false because it only took into account --screen being set and not --screen-name. To fix this, just add an extra condition to the force_pos bool so it becomes true if there's a string in --screen_name. Fixes issue #9877.
* mpv.desktop: add turkish translationOğuz Ersen2022-04-081-0/+3
|
* options.lua: remove unused functionGuido Cella2022-04-081-7/+0
| | | | | val2str isn't used anywhere. Its only use was removed in dd3e52fe68, when it was still part of osc.lua.
* options: add osd-playing-msg-durationGuido Cella2022-04-074-1/+10
|
* egl_helpers: request at least 8 alpha bits if necessaryOlivier Perret2022-04-071-1/+1
| | | | | | Previously on wayland, it would result in an egl config with only 2 alpha bits, which technically matches what was requested, but is not very useful. Fixes #9862
* DOCS/input: mark chapter-list as writableGuido Cella2022-04-071-1/+1
|
* drm: context_drm_egl: add support for enabling VRRPhilip Langdale2022-04-056-0/+41
| | | | | | | | | | | | | | Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used with DRM by setting the VRR_ENABLED property on a crtc if the connector reports that it is VRR_CAPABLE. This is a useful feature for us as it is common to play 24/25/50 fps content on displays that are nominally locked to 60Hz. VRR can allow this content to play at native framerates. This is a simple change as we just need to check the capability and set the enabled property if requested by the user. I've defaulted it to disabled for now, but it might make sense to default to auto in the long term.
* vd_lavc: add vo caps and option to set GPU film grain applicationLynne2022-04-054-1/+32
|
* vo_gpu_next: apply film grain if such metadata is presentLynne2022-04-051-0/+5
|
* vf_format: support forwarding/stripping film grain metadataLynne2022-04-053-0/+11
|
* mp_image: support film grain parametersLynne2022-04-052-0/+12
|
* vd_lavc: hide a deprecation warning in already handled compatible codeJan Ekström2022-04-031-1/+3
| | | | | | | | | | | The field has been deprecated, yet the upcoming new default is not yet the default. Thus, until lavc major hits 60 and the default behavior finally gets changed, we have to explicitly set the field's value. The deprecation had already been handled by adding the required version limitation for this code in bbbf3571edfbb0e849d3ef60148743352b84fe84 , this change merely just removes the warning which would otherwise appear until lavc major version gets bumped to 60.
* sub/osd: use atomic for osd_state.force_video_ptsAman Karmani2022-04-022-11/+8
| | | | | | | | | | this field is used only in a special vo draining edge case. switching to an atomic reduces osd->lock contention between the mpv core (in write_video) and vo threads which are managing osd rendering manually (such as vo_rpi). Signed-off-by: Aman Karmani <aman@tmm1.net>
* osdep/atomic: add mp_atomic_doubleAman Karmani2022-04-021-0/+2
| | | | Signed-off-by: Aman Karmani <aman@tmm1.net>
* Revert "vo_gpu_next: remove unnecessary dependency"Niklas Haas2022-04-011-2/+1
| | | | | | This reverts commit 1c2dde91d369987199782f4914f56019e5a2272c. Fixes #10037
* ao_pipewire: Do not hold thread lock during loop stopThomas Weißschuh2022-03-311-3/+1
| | | | | | | Stopping the thread is done using pw_thread_loop_stop(), *which must be called without the lock held.* Fixes #10033
* ao_pipewire: fix resource lifetimesThomas Weißschuh2022-03-301-7/+21
| | | | | | | We have to destroy the core before destroying the loop. Also we have to lock the mainloop for operations on its objects. Fixes #10003
* vo_gpu_next: remove unnecessary dependencyNiklas Haas2022-03-291-1/+2
| | | | | | Pulling in <libplacebo/utils/libav.h> in particular triggers the notorious _av_vkfmt_from_pixfmt linking issue when FFmpeg is built without Vulkan support.
* lua: use correct chunkname when loading script filessfan52022-03-231-3/+6
| | | | This was brought up in #10007 and it turned out mpv did not follow Lua conventions.
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-2112-32/+59
| | | | | | | | | When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
* common/av_log: explicitly include version.h for required librariesLeo Izen2022-03-171-0/+6
| | | | | | | | | | | FFmpeg recently split version.h into version.h and version_major.h, and no longer automatically includes version.h in avcodec.h (and the other libraries). This should allow mpv to build against ffmpeg git master. See FFmpeg/ffmpeg@f2da2e1458b76a1d6c068673430b46cf2850bc51 These headers are not new, so their inclusion should not affect backwards compatibility.
* vo_gpu_next: also include stride alignment in DR sizeNiklas Haas2022-03-141-2/+3
| | | | Fixes #9976
* vulkan: correctly inherit proc_addr pointerNiklas Haas2022-03-131-0/+1
| | | | | | As found out by @philipl, failing to pass this from the VkInstance to the VkDevice is bad style. We might want to override the get_proc_addr pointer in the future.
* ao_sndio: fix parentheses warningLaserEyess2022-03-111-3/+3
| | | | | No change in logic, but wrap the LT operator and the && in parentheses to silence the compiler warning.
* client API: also export mpv_stream_cb_add_roDudemanguy2022-03-111-2/+2
| | | | | | | 20c4036daa680ebf9d379c9a7566bcf3ae12d405 switched to hiding all symbols by default and exporting the ones we want with MPV_EXPORT. However, the mpv_stream_cb_add_ro function was missed and it is part of the client API. Export it too. Fixes #9971.
* vo_gpu: hwdec_vaapi: Improve logging when probing surface formatsPhilip Langdale2022-03-102-4/+25
| | | | | | | | | | | Our logging here today is very poor. We don't make it clear what formats we are probing, or even that a certain format failed in most cases. In the case where we do log the error, we don't make it clear which format it was that failed. The end result is that we have no idea what the possible and final format spaces are, which makes it very hard to debug whether things are working correctly, or to work on supporting additional formats.
* DOCS/options.rst DOCS/vo.rst: Update discussion of hwdec usagePhilip Langdale2022-03-092-90/+99
| | | | | | | | | | | | | The documentation's current discussion of hwdec usage is out of date, and unnecessarily pessemistic when applied to modern hardware. The reality is that modern APIs on modern hardware produce reasonable results and there's no need to pretend otherwise. The current language that tries to drive people away from using hwdecs at all leads to them making bad choices when they do try to use it. Let's also make it clearer that users should use vo=gpu with hwdecs rather than vo=vaapi or vo=vdpau. Even the existing admonitions have proven insufficient, so let's strengthen that language.
* vo_gpu_next: fix crash when disabling DR at runtimeNiklas Haas2022-03-081-5/+6
| | | | | | | This code fails if we have DR buffers, but none of them correspond to the current frame. Normally only happens if e.g. changing the decoder at runtime, since DR buffers are not properly reinit in that case. (Arguably a separate bug)
* vo_gpu_next: don't leak mpi on failed uploadNiklas Haas2022-03-081-32/+37
| | | | | | | The current map_frame() code fails to clean up after itself on the failure paths. But if map_frame returns false, no cleanup code is ever attempted. Add the relevant calls to clean up state manually, throughout.
* vo_gpu_next: properly keep track of DR allocationsNiklas Haas2022-03-071-27/+39
| | | | | | | | | | | | | | | | | | | So, turns out the approach in 7f67a553f doesn't work for all codecs. In particular, sometimes lavc will internally allocate a new AVBuffer that just points at the old AVBuffer but has a different opaque field for some reason. In these cases, the DR metadata doesn't survive the round-trip through libavcodec. I explored several alternative ways of solving this problem, including adding new mp_image fields, but in the end none of them survived the round-trip through AVFrame and back. The `priv` and `opaque` fields in respectively `mp_image` and `AVFrame` are also too heavily overloaded to be of much help. In the end, bite the bullet and use the same approach as done in `vo_gpu`, which is to just keep track of a list of all allocations. This is a really ugly way of doing things IMO, but ultimately, completely safe.
* hwdec: warn on unsupported hwdec option valueAvi Halachmi (:avih)2022-03-071-5/+10
| | | | | | | | | | | | | | | | | | | | | | | Previously, when mpv was invoked with unsupported hwdec value, such as --hwdec=foobar, there was no indication that it doesn't exist. The reason it's not validated during options parsing is that the name is only evaluated when selecting hwdec for actual decoding, by matching it against runtime list of names from ffmpeg. Additionally, when selecting hwdec for decoding, matching the name came after filtering by codec, hence overall never-matched-name did not necessarily indicate it's unsupported (doesn't exist at all). Now we check the name before filtering by codec, and when done, warn if no hwdec with that name exists at all. This means that an unsupported name will now generate such warning whenever we try to choose a hwdec, i.e. possibly more than once. It's much better than no notification at all, and arguably adequate for a sort of configuration error (linked ffmpeg has no such hwdec name) which we don't validate during option parsing.
* vo_gpu_next: don't allocate dr_buf as part of the AVBufferRefNiklas Haas2022-03-061-20/+9
| | | | | | | | | | | | | | | | | | Some decoders, notably hevcdec, will unconditionally memset() the entire AVBufferRef based on the AVBufferRef size. This is bad news for us, since it also overwrites our `struct dr_buf`. Rewrite this code to make it more robust - keep track of the DR buf metadata in a separate allocation instead. Has the unfortunate downside of technically being undefined behavior if `opaque` is not at least 64 bits in size, though, but avoids this issue. Maybe there's a better way for us to unconditionally keep track of DR allocation metadata. I could try adding it into the `mp_image` itself. Maybe on a rainy day. For now, this works. Fixes #9949 Might fix #9526
* hwdec: fix out-of-date preprocessor variable nameNiklas Haas2022-03-041-1/+1
| | | | This was renamed to HAVE_VAAPI_LIBPLACEBO.
* ytdl_hook.lua: consider any subprocess status != 0 as errorAvi Halachmi (:avih)2022-03-031-1/+6
| | | | | | | | | | | Previously only status<0 was considered as error, but status>0 is also an error (the process exit code). Change to status != 0. This likely makes little to no difference in practice, because if stdout is empty or can't be parsed as JSON then it's considered an error anyway, but still, this is more correct. Also, on error, add the complete subprocess result to the verbose log.
* vo_gpu_next: add D3D11 RA texture wrapping/unwrapping for hwdecJames Ross-Gowan2022-03-033-5/+44
| | | | This mostly copies the API used in the GL backend.
* vo_gpu_next: add support for hardware decodingNiklas Haas2022-03-033-40/+166
| | | | | | | | | | | | | | | | There are two major ways of going about this: 1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing hwdec mappers, and then add code in vo_gpu_next to rewrap tho