summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ao_audiotrack: change buffer sizing logicAman Karmani2021-10-211-2/+2
| | | | | | | | Previously number of channels was being ignored. The buffer will now be between 75ms and 150ms Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: allocate chunk buffer based on negotiated sizeAman Karmani2021-10-211-2/+3
| | | | Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: support delay up to 2s as normalAman Karmani2021-10-211-2/+2
| | | | | | Fixes issues streaming to echo speaker pair from firetv devices. Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: set device_buffer based on underlying buffer size when availableAman Karmani2021-10-211-0/+10
| | | | Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: use new style initializer for AudioTrack when availableAman Karmani2021-10-211-11/+114
| | | | | | Fixes deprecation warnings printed when using this driver. Signed-off-by: Aman Karmani <aman@tmm1.net>
* egl_helpers: ensure debug context attrs/bit existDudemanguy2021-10-211-0/+9
| | | | | | | Regression from e13fe1299d8aefdc264e74159cce07b8bfcf722c. Apparently, Broadcom's EGL does not support the EGL_CONTEXT_FLAGS_KHR attribute nor EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR. Just define these as EGL_NONE and 0 respectively if we do not have them.
* editorconfig: add initial file/configEmil Velikov2021-10-201-0/+10
| | | | | | | | | | | | | | | editorconfig configuration files hold editor style hints, and is supported by many popular editors. See https://editorconfig.org/ . The vast majority of the mpv source/text files are already styled as 4 space indentation, trailing newline at EOF, and UTF-8 encoding. This commit adds a single .editorconfig root file which applies these rules to all files using the glob "[*]". If it turns out to be too inclusive then we can narrow it down later. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* lua: makenode: prevent lua stack corruptionAvi Halachmi (:avih)2021-10-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally there was no issue, but when the code converted a deeply nested table into an mpv node - it didn't ensure the stack has room. Lua doesn't check stack overflow when invoking lua_push* functions, and leaves this responsibility to the (c) user via lua_checkstack. Normally that's not an issue because when a lua (or autofree) function is called, it's guaranteed at least LUA_MINSTACK (20) pushes. However, pushnode and makenode are recursive, and each iteration can add few values at the stack (which are popped when the recursion unwinds), so checkstack must be used on (recursive) entry. pushnode already checked the stack, makenode did not. This commit checks the stack at makenode as well. The value of 6 (stack places to reserve) is with some room to spare, and in pratice each iteration needs 2-3 at most (pushnode also leaves room). Example which could previously corrupt the stack: utils.format_json({d1={d2={<8 more times>}}} This uses makenode to convert the lua table into an mpv node which the json writer uses as input, and if the depth is 10 or more then corruption could occur. mp.command_native is also affected, as well as any other mp/utils command which takes a lua table as input. While at it, fix the error string which pushnode used (luaL_checkstack uses the provided string with "Stack overflow (%s)", so the user message only needs to be additional info).
* lua: autofree infrastructure: x2 fasterAvi Halachmi (:avih)2021-10-191-17/+47
| | | | | | | | | | | | | | | | | | | | | The speedup is due to moving big part of the autofree runtime overhead (new lua c closure) to happen once on init at af_pushcclosure, instead of on every call. This also allows supporting upvalues trivially, even if mpv doesn't use it currently, and is more consistent with lua APIs. While x2 infrastructure speedup is meaningful - and similar between lua 5.1/5.2/jit, in practice it's a much smaller improvement because the autofree overhead is typically small compared to the "real" work (the actual functionality, and talloc+free which is needed anyway). So with this commit, fast functions improve more in percentage. E.g. utils.parse_json("0") is relatively fast and is now about 25% faster, while a slower call like mp.command_native("ignore") is now about 10% faster than before. If we had mp.noop() which does nothing (but still "needs" alloc/free) - it would now be about 50% faster. Overall, it's a mild performance improvements, the API is now more consistent with lua, and without increasing code size or complexity.
* js: custom-init: use ~~/init.js instead of ~~/.init.js (dot)Avi Halachmi (:avih)2021-10-193-7/+15
| | | | | | | | | | | | | | | | | | | | mpv doesn't have other dot files in its config dir, and it also shouldn't be "invisible". The new name ~~/init.js now replaces ~~/.init.js While mpv usually deprecates things before outright removing them, in this case the old (dot) name is replaced without deprecation: - It's a bad idea to execute hidden scripts, even if at a config dir, and we don't want to do that for the next release cycle too. - We warn if the old (dot) name exists and the new name doesn't, which should be reasonably visible for affected users. - It's likely niche enough to not cause too much pain. If for some reason both names are needed, e.g. when using also an old mpv versions, then the old name could be symlinked to the new one, or simply have one line: `require("~~/init")` to load the new name, while a new mpv version will load (only) the new name without warning.
* egl_helpers: add support for debug contextsEmil Velikov2021-10-161-0/+4
| | | | | | | With the recent refactor and quick look against the GLX code path, it's fairly obvious, and trivial, how to add support for debug contexts. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: context_glx: cleanup create_context_x11_gl3 code pathEmil Velikov2021-10-161-23/+37
| | | | | | | | | | | | | | | | | | | Drop the gl3 suffix from the function name - it's no longer needed, with the _old function gone. Push the mpgl_min_required_gl_versions[] looping within the function, reducing the identical glXGetProcAddress/glXQueryExtensionsString calls while making the code neater. v2: - tabs -> spaces indentation - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions - 320 -> 300 (in glx code path) v3: - legacy code path is gone \o/ Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: context_glx: remove legacy create_context_x11_old()Emil Velikov2021-10-161-43/+9
| | | | | | | | | | | | | | | | | | | | | | | | | The old/legacy code-path isn't really needed for mpv use-cases. In particular: All Mesa drivers (even GL 2.1 ones like lima/vc4) work fine with the "non-legacy" path. From proprietary/binary drivers - the vendor either does not support desktop GL or the drivers/HW is not actively supported. Looking at the Nvidia HW - anything GeForce 7 and older is GL 2.1 and lacks decent video acceleration. The latest official drivers are from 2017. All newer Nvidia HW is GL 3.3+ thus must have GLX_ARB_create_context as in the non-legacy path, while also good acceleration albeit via VDPAU in some cases. With the old path gone, provide meaningful error message in the very unlikely case that GLX_ARB_create_context is missing. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* egl_helpers: fixup the EGL_KHR_create_context-less codepathEmil Velikov2021-10-163-44/+9
| | | | | | | | | | | | | | | | | | | With earlier commit f8e62d3d82 ("egl_helpers: fix create_context fallback behavior") we added a fallback for creating OpenGL context while EGL_KHR_create_context is missing. While it looked correct at first, it is missing the eglMakeCurrent() call after creating the EGL context. Thus calling glGetString() fails. Instead of doing that we can just remove some code - simply pass the CLIENT_VERSION 2, as attributes which is honoured by EGL regardless of the client API. This allows us to remove the special case and drop some code. v2: - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* video: opengl: rework and remove ra_gl_ctx_test_version()Emil Velikov2021-10-164-46/+37
| | | | | | | | | | | | | | | | The ra_gl_ctx_test_version() helper is quite clunky, in that it pushes a simple check too deep into the call chain. As such it makes it hard to reason, let alone have the GLX and EGL code paths symmetrical. Introduce a simple helper ra_gl_ctx_get_glesmode() which returns the current glesmode, so the platforms can clearly reason about should and should not be executed. v2: - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions - 320 -> 300 (in glx code path) Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: opengl: remove --opengl-restrictEmil Velikov2021-10-163-16/+2
| | | | | | | | | | | | | | | | | | | | As the documentation of the toggle says - the implementation can (and will actually if they follow the GLX/EGL spec) return context version greater than the one requested. This happens with all Mesa drivers that I've tested as well as the Nvidia binary drivers. This toggle seems like a workaround for buggy drivers, yet it's lacking context about the vendor and version. Remove it for now - I'll be happy to reinstate it (partially or in full) as we get concrete details. This allows us to simplify ra_gl_ctx_test_version() making the whole context creation business easier to follow by mere mortals. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* egl_helpers: remove explicit GLES 3 requestEmil Velikov2021-10-161-23/+12
| | | | | | | | | | | | | | | | | | Alike the GL commit earlier - the EGL spec essentially mandates that implementation will return GLES 3.0+ (if supported by the driver), even though only GLES 2 is requested. The only thing we should watch out is - we should add both ES2_BIT and ES3_BIT as EGL_RENDERABLE_TYPE. This has been verified against the Mesa drivers (i965, iris, swrast) and Nvidia binary drivers. v2: - int es_version -> bool es - unloop create_context() execution Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: opengl: reduce versions in mpgl_preferred_gl_versionsEmil Velikov2021-10-164-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently mpv requires a bare minimum of GL 2.1, although it tries to use 3.2+ core contexts when possible. The GLX and EGL spec effectively guarantee that the implementation will give you the highest compatible version possible. In other words: Requesting 3.2 core profile will always give you core profile and the version will be in the 3.2 .. 4.6 range - as supported by the drivers. Similarly for 2.1 - implementation will give you either: - 2.1 .. 3.1, or - 3.2 .. 4.6 compat profile This has been verified against the Mesa drivers (i965, iris, swrast) and Nvidia binary drivers. As such, drop the list to 320, 210 and terminating 0. v2: - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions - update ^^ comment Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* drm: re-enable drmSet/DropMaster callsEmil Velikov2021-10-151-14/+7
| | | | | | | | | | | | | | | The ioctls were disabled a while back since they error out and allegedly cause problem with X running in another VT. Omitting the ioctls is not cool, even as a workaround. If they fail, the user is supposed to fallback appropriately - use a suid wrapper, logind-like daemon or otherwise. As of kernel 5.10, they should just work in nearly all cases, so let's just reinstate the calls. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* context_drm_egl: re-enable drmSet/DropMaster callsEmil Velikov2021-10-151-17/+10
| | | | | | | | | | | | | | | The ioctls were disabled a while back since they error out and allegedly cause problem with X running in another VT. Omitting the ioctls is not cool, even as a workaround. If they fail, the user is supposed to fallback appropriately - use a suid wrapper, logind-like daemon or otherwise. As of kernel 5.10, they should just work in nearly all cases, so let's just reinstate the calls. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* command: with lavfi-complex, make current-tracks return the first oneGuido Cella2021-10-152-9/+12
| | | | | | | | | | | | | | | | | | | This behavior is more convenient and allows profile conditions like: [video] profile-cond=get('current-tracks/video/image') == false [image] profile-cond=get('current-tracks/video/image') Otherwise, these profiles have to be manually applied and restored in a script. The note about discouraging the use of current-tracks in scripts is removed, because it makes people avoid using this convenient property. It was added in 720bcd79d03 without leaving an explanation of why you shouldn't use it, and the only reason seems to be that it doesn't work with lavfi-complex, but this commit changes that.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-1410-5/+22
| | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image, which is useful for profile conditions, property expansion and lavfi-complex. The lavf demuxer sets image to true when the existing check detects an image. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* demux_lavf: improve image detectionGuido Cella2021-10-141-9/+9
| | | | | | | | | | | | | | | | | | | | This moves the image check to where the number of frames is available of comparison, which allows not detecting jpg and png videos as images, and detecting 1-frame gifs as images. This works with the mjpeg and png videos in the FATE suite, though unfortunately the bmp video is still detected as an image since it has nb_frames = 0. aliaspix streams are also now considered images. Attached pictures are now treated like standalone images, so audio with attached pictures now has mf-fps as container-fps instead of unavailable, which makes it consistent with external cover art, which was already being assigned mf-fps. Unfortunately images in a codec commonly used for videos are never detected, and detection was inaccurate even using the now private codec_info_nb_frames field in AVStream, and mediainfo gets them wrong too, so I guess it's just a lost cause.
* js: custom init: ignore ~~/.init.js with --no-configAvi Halachmi (:avih)2021-10-122-1/+6
| | | | | | The custom init script should be considered a configuration file, and as such it should be ignored when the user wants vanilla mpv - and now it is ignored with --no-config.
* DOCS/options: refine --no-input-default-bindingsAvi Halachmi (:avih)2021-10-111-4/+4
|
* input: new option: --no-input-builtin-bindingsAvi Halachmi (:avih)2021-10-113-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is similar to [no-]input-default-bindings, but affects only builtin bindings (while input-default-bindings affects anything which config files can override, like scripting mp.add_key_binding). Arguably, this is what input-default-binding should have always done, however, it does not. The reason we add a new option rather than repurpose/modify the existing option is that it behaves differently enough to raise concerns that it will break some use cases for existing users: - The new option is only applied once on startup, while input-default-bindings can be modified effectively at runtime. - They affects different sets of bindings, and it's possible that the set of input-default-bindings is useful enough to keep. Implementation-wise, both options are trivial, so keeping one or the other or both doesn't affect code complexity. It could be argued that it would be useful to make the new option also effective for runtime changes, however, this opens a can of worms of how the bindings are stored beyond the initial setup. TL;DR: it's impossible to differentiate correctly at runtime between builtin bindings, and those added with mp.add_key_bindings. The gist is that technically mpv needs/uses two binding "classes": - weak/builtin bindings - lower priority than config files. - "user" bindings - config files and "forced" runtime bindings. input-default-bindings affects the first class trivially, but input-builtin-bindings would not be able split this class further at runtime without meaningful changes to a lot of delicate code. So a new option it is. It should be useful to some libmpv clients (players) which want to disable mpv's builtin bindings without breaking mp.add_key_bindings for scripts. Fixes #8809 (again. the previous fix 8edfe70b only improved the docs, while now we're actually making the requested behavior possible)
* ci: update libs used by mingw buildsfan52021-10-072-4/+5
|
* github/workflows: enable macOS 11.x CIJan Ekström2021-10-061-0/+1
| | | | This image has finally become public.
* vo_gpu: libplacebo: add missing includeNiklas Haas2021-10-041-0/+1
| | | | | This was removed from common.h upstream since it was a cyclic dependency. We need to re-import it into utils.h manually.
* vo_gpu: libplacebo: drop conditional code paths for old versionsNiklas Haas2021-10-043-34/+1
| | | | No longer needed with the bump to v3.104.
* vo_gpu: libplacebo: drop code deprecated in libplacebo v3Niklas Haas2021-10-043-13/+2
| | | | | This is only needed for back-compat with libplacebo v2, and will break due to upstream removal starting with libplacebo v4.
* wscript: bump libplacebo minimum versionNiklas Haas2021-10-041-1/+1
| | | | Switching to v3 allows us to drop the use of deprecated/removed members.
* options: add missing dash in msg-level help messageEmil Velikov2021-10-031-1/+1
| | | | | | | | Currently using mpv --msg-level=help, shows an instance of --msglevel (missing dash). Seems like the help message was only partially updated with the -msglevel -> --msg-level transition. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* osc.lua: avoid infinite ticks loop on idleAvi Halachmi (:avih)2021-10-031-1/+11
| | | | | | | | | | | | | | | Before this commit, animation-end was handled at render(), however, it's not called on idle, which resulted in state.anitype ~= nil, with nothing to reset it during idle, which caused in an infinite tick() loop (starts on first mouse move). Now tick resets the animation on idle, and also, as a safety measure, if we're past 1s after the animation deadline. The safety measure is because the osc states are complex, and it's easier to detect a "we really shouldn't be animating now" at tick() itself rather than detecting the exact states where animation should be reset. Generally, the safety mmeasure is not needed.
* osc.lua: unify animation reset function (no-op)Avi Halachmi (:avih)2021-10-031-6/+8
|
* build: lua 5.1/5.2: use generic version namesAvi Halachmi (:avih)2021-10-032-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 . For unversioned 'lua.pc', use the name luadef51/luadef52 . Autodetection remains the same (5.2 names, luajit, 5.1 names). The old names are still supported, but not auto-detected. Before this patch, if one wanted to choose a specific lua version when more than one is installed, then the names were a mess, e.g. 51obsd is also the name detected on Arch linux, and other (distro) names are also not unique to a specific distro/platform. So to ask mpv to choose the package name (specifically, the pkg-config file name), one needs to look at the mpv sources and find the (arbitrary) distro name which has the same lua version naming as they do on their own system, e.g. --lua=51obsd on Arch. This is a pain. Now we add generic names: - luadef51/luadef52 - generic pkg-config lua.pc (version is inside). - lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc (the names are curated, e.g. --lua=foo won't detect foo.pc). - The legacy names (e.g. 51deb) are still supported, but undocumented, and the new generic names take precedence during auto-detection. The fact that the generic names all start with "lua" has an additional benefit that it shows right after "lua" at the output of mpv -v, while the old names start with numbers, so they're first at the list, making it hard to understand that e.g. "51obsd" is the lua version. None of these names are actually used at the mpv code. The C code checks the version using the lua headers (LUA_VERSION_NUM).
* build: lua version: sanitize id before storage (no-op)Avi Halachmi (:avih)2021-10-032-3/+5
| | | | | | | | | | | | | | | | | | | | | | The lua version names which are autodetected/chosen (such as "51deb") are used for two things: - as key for storing the pkg-config compile/link flags. - as ID for config.h and elsewhere - they're sanitized to use "_". Due to some inconsistensies, if the sanitized ID is different than the original name, then the compile/link flags are stored with the original name as key, while the retrieval happens with the sanitized ID - and therefore fails to find the correct flags. The solution is to use the original name only for display purpose at the output of configure, while using the sanitized version for everything else, so that storage and retrieval use the same key. Currently there's no issue and the patch has no effect, because the sanitizer considers all the current names as valid IDs. However, the next commit will add names which the sanitizer modifies, such as "lua-5.1", so this commit makes such names work too.
* Revert "player: add track-list/N/image sub-property"Jan Ekström2021-10-0210-53/+14
| | | | | | | | Unfortunately, this functionality in large part based on a struct member that was made private in FFmpeg/FFmpeg@7489f632815c98ad58c3db71d1a5239b5dae266c in May. Unfortunately, this was not noticed during review. This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
* github/workflows: disable seccomp for linux native CIJan Ekström2021-10-021-0/+4
| | | | | | | | | | This CI builder bases on openSUSE Tumbleweed, and recently had its glibc updated. This led to new syscalls such as 'clone3' not being allowed through the security layer. Can be reverted after Github Actions updates their security policy. actions/virtual-environments#3812
* player: add track-list/N/image sub-propertyGuido Cella2021-10-0210-14/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image. This is useful for profile conditions, property expansion and lavfi-complex, and is more accurate than any detection even Lua scripts can perform, since they can't differentiate between images and videos without container-fps and audio and with duration 1 (which is the duration set by the mf demuxer with the default --mf-fps=1). The lavf demuxer image check is moved to where the number of frames is available for comparison, and is modified to check the number of frames and duration instead of the video codec. This doesn't misdetect videos in a codec commonly used for images (e.g. mjpeg) as images, and can detect images in a codec commonly used for videos (e.g. 1-frame gifs). pix files are also now detected as images, while before they weren't since the condition was checking if the AVInputFormat name ends with _pipe, and alias_pix doesn't. Both nb_frames and codec_info_nb_frames are checked because nb_frames is 0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing --demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4, wmv3). The duration is checked as well because for some uncommon codecs and containers found in FFMpeg's FATE suite, libavformat returns nb_frames = 0 and codec_info_nb_frames = 1. For some of them it even returns duration = 0, so they are blacklisted in order to never be considered images. The extra codecs that would have to be blacklisted without checking the duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO, AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO, AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg. The lower limit for duration is 10 because that's the duration of 1-frame gifs. Streams with codec_info_nb_frames 0 are not considered images because vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we can't rely on just the duration to detect them because they could be livestreams without an initial duration, and actually even if we could for these codecs libavformat returns huge negative durations like -9223372036854775808. Some more images in the FATE suite that are really frames cut from a video in an uncommon codec and container, like cine/bayer_gbrg8.cine, could be detected by allowing codec_info_nb_frames = 0, but then any present and future video codec with nb_frames = 0 and codec_info_nb_frames = 0