summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* playlist: remove unused code to track redirectsGuido Cella2023-08-283-22/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the code to track redirects (playlists and directories) never worked correctly, only the last redirect is remembered and num_redirects is never greater than 1. You can see this by doing quit-watch-later with the old watch later system, before dbf244fd2f, on a m3u playlist of files and a m3u playlist of directories. Only in the first case a redirect entry for the m3u file is created, because in the second case the m3u redirect is replaced by the directory one. If you did mpv --directory-mode=lazy /foo it did create redirect entries for all subdirectories e.g. /foo/bar, /foo/bar/baz, /foo/bar/baz/qux, this made it seem like it worked correctly, but actually /foo/bar/bar/qux was the only redirect entry and thus it was considered as the first redirect, and mpv created redirect entries for each segment of the first redirect only. In the previous commit dbf244fd2f, rather than figuring out how to fix the code to track redirects, and since creating redirect entries for multiple redirects is overkill, I just used the new playlist-path property which does the same thing but only for the last redirect. By replacing the only other use of the old redirect code with playlist-path, we can remove it.
* player: always write redirect entries for resuming playbackGuido Cella2023-08-283-36/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 35f43dfacbe added a system to write resume files for redirects, i.e. directories and playlists that mpv expands. It creates a resume file for each redirect, and for the first redirect only, it writes a resume file for each segment of its path, without even converting it to an absolute path if it's relative. This is incomplete: mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3' This doesn't save any redirect entry. mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on Hallowed Be Thy Name This saves a redirect entry for "Iron Maiden", but not for "1982 The Number of the Beast". It doesn't save redirect entries for the directories above "Iron Maiden" either because "Iron Maiden" isn't converted to an absolute path. In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't resume from "Hallowed Be Thy Name" because "1982 The Number of the Beast" isn't the first subdirectory and there is no redirect entry for it. 503dada42f made mpv recursively expand subdirectories precisely to fix this, and f266eadf1e added back an option not to expand them. But if we fix how redirect entries are stored, we can make the superior --directory-mode=lazy (because it's faster and doesn't result in massive playlists) the default, and also ensure that mpv will resume playback even when you quit-watch-later a file without redirects and then play the directories above it. Fix this by always creating redirect entries for all segments of the absolute path of the file, so that both mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3' and mpv --directory-mode=lazy 'Iron Maiden' will create redirect entries for /$USER /$USER/music /$USER/music/Iron Maiden /$USER/music/Iron Maiden/1982 The Number of the Beast making mpv --directory-mode=lazy "Iron Maiden" resume from "Hallowed Be Thy Name". This commit also makes mpv delete the redirect entries of parent directories when resuming playback, because if for example you have a playlist with all the songs in a discography: 1980 Iron Maiden/1 Prowler.mp3 1980 Iron Maiden/2 Remember Tomorrow.mp3 ... 1981 Killers/1 The Ides of March.mp3 1981 Killers/2 Wrathchild.mp3 ... Now mpv will eventually create redirect entries for every album. If you later decide to play the directories instead and there are 20 albums, you would have to do mpv * 20 times to clear all the redirect entries.
* vo_dmabuf_wayland: unmap osd surface when not neededRobert Mader2023-08-281-1/+9
| | | | | | | Attaching a NULL buffer unmaps the surface, allowing compositors to skip blending the empty buffer. Closes #12236
* vo_gpu_next: fix --target-contrast=infNiklas Haas2023-08-281-1/+1
| | | | | | Somehow this overrode max_luma instead of min_luma... Fixes: 347fbd6fa357e854cfb0bc6d3c9b3d12994d5c0c
* README: replace outdated xinerama reference with xpresentDudemanguy2023-08-271-1/+1
| | | | | | | 200992f90c49fdc2d5605cf79ffaa5247fd62e3e stopped linking mpv to libXinerama so this library isn't needed anymore. However, we do use xpresent so mention that instead since all the other needed xorg libraries are listed as well.
* f_lavfi: don't reject dynamic lavfi ins/outsllyyr2023-08-282-3/+13
| | | | | | | | | | Ideally, users should be using lavfi-complex instead of lavfi-bridge for such a use case, however currently lavfi-complex doesn't support hwdec. So we can allow filters with dynamic inputs to work with lavfi-bridge, at the cost of them only being able to take in only one input. This should probably be reverted when/if lavfi-complex has hwdec, but for now this allows us to use libplacebo as a video filter with hwdec in mpv again.
* osc: fix margin for forced-only subs toggle in bar layoutllyyr2023-08-271-1/+2
| | | | | | This ensures the spacing between forced-only sub toggle button and the volume button matches the spacing between the volume and the fullscreen button on bottombar/topbar layouts
* osc: only add sub forced-only toggle to layout for DVD/PGS subsllyyr2023-08-271-12/+13
| | | | | | | | | | | | | | | | | Fixes: 945d7c1eda47c97c4bfba884fb21f398a64b2289 Previously, we would have a button with empty string added to the layout for non DVD/PGS subtitles. This would cause there to be an invisible button present that would take up space and could still be clicked despite being invisible when the current subtitle track was not DVD/PGS. The idea was that the button would be invisible for regular subtitle tracks, and be visible as "[ ]"/"[F]" for DVD/PGS subtitle tracks. This commit modifies the bar and box layouts to only add this button if the current subtitle track is DVD/PGS. This results in there no longer being an invisible button, and also prevents it from taking up space. The button is added to layout as before when the current subtitle track is DVD/PGS, matching the same logic as before.
* input: add missing windows multimedia keysChristoph Heinrich2023-08-271-1/+10
| | | | | | | | x11 and wayland had a lot of multimedia keys mapped that were missing on windows. Now the only ones they map that windows doesn't are `MP_KEY_WWW`, `MP_KEY_ZOOMIN` and `MP_KEY_ZOOMOUT`, which apparently don't have any equivalent ones on windows.
* command: add `sub-ass-extradata` propertyllyyr2023-08-274-0/+39
|
* vo_gpu_next: update tmp params before rendering frameNiklas Haas2023-08-271-7/+6
| | | | | Gives the correct queue size value for the subsequent pl_queue_update() calls, which avoids a bit of unnecessary overhead.
* vo_gpu_next: make option shim consistent with new APINiklas Haas2023-08-271-18/+20
| | | | | Avoids some unnecessary #ifdef and allows us to isolate the shim to a single location.
* vo_gpu_next: avoid duplicate code (cosmetic)Niklas Haas2023-08-271-5/+4
| | | | Also avoids 80col violation.
* vo_gpu_next: correctly set params.frame_mixerNiklas Haas2023-08-271-4/+3
| | | | | | | This was incorrectly adapted from the old options system, we forgot to ever actually assign p->frame_mixer to params.frame_mixer. Fixes: d2082841df8bc39c585fc9d4be6498d1a296fed8
* vo_gpu_next: don't nuke main options state in video_screenshotNiklas Haas2023-08-271-6/+13
| | | | | | | | This actually fixes a bug that was present in this code even before the new pl_options system, which is that `video_screenshot` would permanently leave `peak_detect_params.allow_delayed` as false, until something else forced options re-application due to options cache change.
* vo_gpu_next: don't override main options in draw_frameNiklas Haas2023-08-271-8/+10
| | | | | | | Instead, take a stack copy of the relevant struct. Avoids leaving temporary state dangling after this function returns. Fixes: 40b6afcfca81a30c29531a49b6368b53ad5d501f
* hwtransfer: check if the source format is accepted directly by the VOPhilip Langdale2023-08-261-0/+26
| | | | | | | | | | | | | | | | | This may seem obvious in retrospect, but we need to explicitly account for the case where the source format is supported by the VO, but not a valid target format for the conversion filter. In that situation, we would conclude that conversion was necessary, because we relied solely on the conversion filter to identify acceptable target formats. To avoid that, we should go through the VO's reported set of supported formats and if the source format is on the list, ensure that format is also on the target list. This is mostly a no-op as most VOs do not report supported formats (instead assuming that all formats decoders can produce are supported) and in the case where it matters (vaapi), there is only one format that the VO supports which the conversion filter does not (yuv444p).
* hwtransfer: use the right hardware config to find conversion targetsPhilip Langdale2023-08-264-24/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last piece in the puzzle for doing hardware conversions automatically is ensuring we only consider valid target formats for the conversion. Although it is unintuitive, some vaapi drivers can expose a different set of formats for uploads vs for conversions, and that is the case on the Intel hardware I have here. Before this change, we would use the upload target list, and our selection algorithm would pick a format that doesn't work for conversions, causing everything to fail. Whoops. Successfully obtaining the conversion target format list is a bit of a convoluted process, with only parts of it encapsulated by ffmpeg. Specifically, ffmpeg understands the concept of hardware configurations that can affect the constraints of a device, but does not define what configurations are - that is left up to the specific hwdevice type. In the case of vaapi, we need to create a config for the video processing endpoint, and use that when querying for constraints. I decided to encapsulate creation of the config as part of the hwdec init process, so that the constraint query can be down in the hwtransfer code in an opaque way. I don't know if any other hardware will need this capability, but if so, we'll be able to account for it. Then, when we look at probing, instead of checking for what formats are supported for transfers, we use the results of the constraint query with the conversion config. And as that config doesn't depend on the source format, we only need to do it once.
* autoconvert: destroy sub filter immediately if reconfiguration is neededPhilip Langdale2023-08-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm currently not convinced that the way the output_chain is handled as part of reconfiguration is correct. If there is an event requiring reconfiguration, such as toggling the use of hwdec, we currently do not ensure that the filter chain is fully drained first. This creates a situation where the filter chain is invalidated while the autoconvert's sub filter (that does the real work) still has a frame to process and pass on. As the autoconvert code calls mp_subfilter_drain_destroy(), it returns early to allow for draining before destroying the subfilter, but that means the subfilter is still present in its original configuration, and no actually draining is done before the existing filters reinitialise themselves. This leads to a situation where, if a hardware scaling filter is being used by autoconvert, that filter is still present and responds when told to reinitialise. But it cannot successfully reinitialise if the triggering event is disabling hw decoding, as the input frame to the filter will now be a software frame, so reinit fails, leading to total failure of the filter chain, which is a fatal error, and we exit. I think this was never noticed before, because I think it's not possible for the hwtransfer filter to be active in a situation where you can dynamically change the state such that the input or output formats of the output chain are invalidated. eg: If the autoconverter is activated because of `--vf=format=vaapi`, it is actually not possible to toggle hwdec off, as the explicit user filter ensure the hwdec is always present and active. So, my solution here is to destroy the sub filter, regardless of whether it needs draining or not. We simply have no opportunity to drain and reconfigure in the correct order, and we must consider the remaining frame in the filter as a casualty of the toggling process. I'm sure there is a more substantial rework of the output_chain reconfiguration process that could ensure draining before reconfiguration begins, but my ambitions do not currently extend that far.
* output_chain: don't reset autoconvert on changes to unrelated filtersPhilip Langdale2023-08-261-1/+5
| | | | | | | | | | | | | | | | | | | | | This has been a standing behaviour for a long time, but I noticed it while implementing the hw->hw autoconvert functionality. Today, the output_chain will reset the autoconvert state when any output_chain filter sees the input format change. This is wasteful as it leads to the image converter having to be reinitialised each time it happens, so we should only do it when the actual "convert" filter sees the input format change. It doesn't matter if one of the other filters in the chain sees a change (although in practice, a format change will basically always propagate down the chain, so they all see a change at the same time). The practical effect of the old behaviour was that a format change would always lead to the image converter being rebuilt twice - once after the "convert" filter sees the format change, and then again after the "out" filter (the end of the chain) sees the change. In this commit, we check which filter is seeing the change, and only reset the autoconvert state for the "convert" filter itself.
* hwtransfer: implement support for hw->hw format conversionPhilip Langdale2023-08-265-48/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, we have not attempted to support hw->hw format conversion in the autoconvert logic. If a user needed to do these kinds of conversions, they needed to manually insert the hw format's conversion filter manually (eg: scale_vaapi). This was usually fine because the general rule is that any format supported by the hardware can be used as well as any other. ie: You would only need to do conversion if you have a specific goal in mind. However, we now have two situations where we can find ourselves with a hardware format being produced by a decoder that cannot be accepted by a VO via hwdec-interop: * dmabuf-wayland can only accept formats that the Wayland compositor accepts. In the case of GNOME, it can only accept a handful of RGB formats. * When decoding via VAAPI on Intel hardware, some of the more unusual video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats which gpu-next cannot handle, causing rendering to fail. In both these cases (at least when using VAAPI with dmabuf-wayland), if we could detect the failure case and insert a `scale_vaapi` filter, we could get successful output automatically. For `hwdec=drm`, there is currently no conversion filter, so dmabuf-wayland is still out of luck there. The basic approach to implementing this is to detect the case where we are evaluating a hardware format where the VO can accept the hardware format itself, but may not accept the underlying sw format. In the current code, we bypass autoconvert as soon as we see the hardware format is compatible. My first observation was that we actually have logic in autoconvert to detect when the input sw format is not in the list of allowed sw formats passed into the autoconverter. Unfortunately, we never populate this list, and the way you would expect to do that is vo-query-format returning sw format information, which it does not. We could define an extended vo-query-format-2, but we'd still need to implement the probing logic to fill it in. On the other hand, we already have the probing logic in the hwupload filter - and most recently I used that logic to implement conversion on upload. So if we could leverage that, we could both detect when hw->hw conversion is required, and pick the best target format. This exercise is then primarily one of detecting when we are in this case and letting that code run in a useful way. The hwupload filter is a bit awkward to work with today, and so I refactored a bunch of the set up code to actually make it more encapsulated. Now, instead of the caller instantiating it and then triggering the probe, we probe on creation and instantiate the correct underlying filter (hwupload vs conversion) automatically.
* player: make all autoload extensions configurableDudemanguy2023-08-268-22/+101
| | | | | | | | | | | | | | | | | | | | | | | | --audio-file-auto, --cover-art-auto, and --sub-auto all work by using an internally hardcoded list that determine what file extensions get recognized. This is fine and people periodically update it, but we can actually expose this as a stringlist option instead. This way users can add or remove any file extension for any type. For the most part, this is pretty pretty easy and involves making sub_exts, etc. the defaults for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and --sub-auto-exts). There's actually one slight complication however. The input code uses mp_might_be_subtitle_file which guesses if the file drag and dropped file is a subtitle. The input ctx has no access to mpctx so we have to be clever here. For this, the trick is to recognize that we can leverage the m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which fires when the player starts up. Then in the callback, we can set the value of sub_exts in external_files to opts->sub_auto_exts. Whenever the option updates, the callback is fired again and sub_exts updates. That way mp_might_be_subtitle_file can just operate off of this global variable instead of trying to mess with the core mpv state directly. Fixes #12000.
* player: use audio pts corresponding to playing audio on EOFllyyr2023-08-251-2/+1
| | | | | | | | | We should account for ao queue when setting playback position on EOF, previously we were using the pts value corresponding to the start of the ao queue, rather than the currently playing audio. This fixes time-remaining being a negative number when mpv seeks to EOF while playback is paused.
* input: add missing keypad key definesChristoph Heinrich2023-08-255-14/+30
| | | | | | | | So far all the keypad keys except for `0` and `,` mapped to the same MP_KEY_* independent of numlock state, even though different key codes are received. Now all the alternative functions map to appropriate MP_KEY_* defines, with missing ones added.
* sub/osd: signal osd_changed on resizellyyr2023-08-251-0/+1
| | | | | We should update the osd when the window is resized, previously we weren't signalling for an update.
* win32: don't ignore --screen and --fs-screenKacper Michajłow2023-08-231-8/+14
| | | | | Fixes: 57ba77fc736f6976bc114974f5955c972139740f Fixes: #12220
* DOCS/mpv: document ZOOMIN & ZOOMOUT multimedia keysJames Cuzella2023-08-231-0/+2
| | | | | | | Document default key mappings for ZoomIn & ZoomOut: ZOOMIN add video-zoom 0.1 ZOOMOUT add video-zoom -0.1
* input: add new keys: Back, Tools, ZoomIn, ZoomOutJames Cuzella2023-08-235-0/+14
| | | | | | | | | | | | | | | | | These were the only keys missing to support mapping all keycodes on a [popular RF Remote][1] used with Linux HTPC apps. Note that X11/XWayland + xkbcomp still warns about keycodes > 255, due to the 8-bit limit in Xorg but `mpv` on Wayland is able to handle these. For X11 users, there are [a couple options][2]: - [Gianni Ceccarelli's patched `xf86-input-evdev`][3] - [Use udev hwdb to map scancodes to keycodes][4] [1]: https://www.mythtv.org/wiki/Air_mouse_rf_remote [2]: https://unix.stackexchange.com/a/436233/7688 [3]: https://www.thenautilus.net/SW/xf86-input-evdev/ [4]: https://wiki.archlinux.org/title/Map_scancodes_to_keycodes
* vo_gpu_next: move line to correct location (cosmetic)Niklas Haas2023-08-211-1/+1
|
* vo_gpu_next: correctly handle GAMUT_AUTONiklas Haas2023-08-211-3/+3
| | | | Fixes: https://github.com/mpv-player/mpv/issues/12208
* ci/mingw: disable vulkan for 32-bit buildsfan52023-08-211-6/+10
| | | | | | | | There's some cdecl / stdcall linking nonsense breaking the build which I'm not inclined to debug this Sunday at all. 32-bit is not important anyway, so just disable it there. On the plus side the new functional structure makes this very painless.
* ci/mingw: don't include useless DLLs in artifactsfan52023-08-211-4/+17
|
* ci/mingw: refactor build script into functionssfan52023-08-211-54/+78
|
* ci/mingw: enable more ffmpeg featuressfan52023-08-211-1/+2
| | | | | | If someone wants to use the CI artifacts for day-to-day usage or even for certain tests it can be useful to take screenshots and use e.g. DShow (--disable-devices option), so enable those.
* ci/mingw: add necessary deps and enable vulkansfan52023-08-211-14/+48
|
* ci/mingw: move functional test to workflowsfan52023-08-212-1/+7
| | | | Arguably the better place for this as it provides fine-grained feedback.
* ci/mingw: update dependency versionssfan52023-08-211-3/+3
|
* vo_gpu_next: reword error message on empty screenshotNiklas Haas2023-08-211-1/+1
| | | | | This can happen under perfectly legitimate circumstances if no file is loaded yet.
* DOCS/options: clarify the video-pan-x/y exampleDudemanguy2023-08-201-3/+3
| | | | | | | | | | 1fa6669bc0e60421f76c7507c3355537ca09fd0e misinterpreted the example and changed the pixel value from 128 to 168 (thinking that it meant pixels after scaling), but likely the original calculation was correct because the line specifically says "of the source video". This is just confusing not really useful information so instead change the example to a more common resolution (1920x1080) and remove any references to the source video resolution. Also mention video-pan-y while we're at it.
* aspect: change --video-pan-x/y to be relative to the destination rectKacper Michajłow2023-08-203-4/+3
| | | | | | | | | | | | | | | | It makes it more usable to virtually move dst rect instead of scaled src. The issue with the latter is that it is affected by video-zoom paramters. For example if we do `--video-pan-x=-0.5` in normal case it will move video -50%, but if we apply video-zoom/scale the video will float towards the middle in unintuitive way. Extreme case is when one do --video-zoom-x=0.01, now it is impossible to move video unless you specify huge video-pan-x value, but it is limited to [-3, 3]. So you cannot do anything. With this changes regardless of video scale/zoom, video-pan will keep center of scaled video in one place.
* aspect: don't allow scaled_src_size be 0Kacper Michajłow2023-08-201-0/+1
| | | | | | | It doesn't make sense to have zero here and it breaks, logic below. Width was still campled to 1, but with broken offset. This fixes things like video-scale-x=0
* DOCS/options: fix typo in video-pan-x exampleKacper Michajłow2023-08-201-1/+1
| | | | | Width of the video would fill fully display at this resolution, so moving it 168px to the left, would hide also 168px.
* meson: rename all features with underscoressfan52023-08-202-18/+17
| | | | The convention is to use dashes.
* context_drm_egl: remove references to VAAPI in error messagessfan52023-08-201-3/+2
| | | | | VAAPI is not the only hwdec that won't work when the render node isn't available.
* context_drm_egl: more correctness fixes for uninit proceduresfan52023-08-201-6/+5
| | | | | | | | | | | | | - uninit gl before the VO - destroy EGL surface before context: reverse of the creation order. I also checked other code which doesn't even call this and leaves it up to eglTerminate, which frees everything anyway. But this seems more correct since we're destroying the gbm surface afterwards. - check against at EGL_NO_DISPLAY instead of 0: there is probably no EGL implementation where this makes a difference, it is more correct regardless - remove pointless eglDestroyContext call - check render_fd before close
* Revert "ao/pulse: implement period_size"sfan52023-08-201-1/+0
| | | | | | | This is why you don't merge three year old contributions without checking that they're even applicable anymore. This reverts commit 5a94c86029a2d0e5452c07a7c12d2a6981f607df.
* w32_common: try to get the monitor from the window boundsZenos2023-08-201-1/+5
|
* w32_common: don't fit to screen when VO_WIN_FORCE_POS is setZenos2023-08-201-1/+1
|
* ao/pulse: implement period_sizeNicolas F2023-08-201-0/