summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* encode: set sample_aspect_ratio on AVStream structHEADmasterekisu5 days1-0/+5
| | | | | Some libavformat muxers (e.g. matroskaenc.c) expect this field to be set on the AVStream struct, and not only in the AVCodecParameters.
* vo_gpu: fix taking screenshots of rotated videoswnoun5 days1-2/+6
|
* vo_gpu: hwdec_vaapi: Synchronise after exporting VA surfacePhilip Langdale13 days1-0/+3
| | | | | | | This is documented as required (although we did not do it in the old GL codepath, with no visible problems) and I have seen transient artifacts after seeking which _appear_ to have gone away after introducing this.
* DOCS/compile-windows: remove angleproject-git from depsRicardo Constantino2019-07-301-1/+1
| | | | | Basically just to trigger a doc rebuild, but might as well do a useful change, since angleproject-git is no longer a valid package in MSYS2.
* TOOLS/travis-rebuild-website: update condition after docker transitionRicardo Constantino2019-07-301-1/+1
| | | | Closes #6822
* cocoa-cb: migrate to swift 5 with swift 4 fallbackder richter2019-07-219-85/+143
| | | | | | | | | | | | | this migrates our current swift code to version 5 and 4. building is support from 10.12.6 and xcode 9.1 onwards. dynamic linking is the new default, since Apple removed static libs from their new toolchains and it's the recommended way. additionally the found macOS SDK version is printed since it's an important information for finding possible errors now. Fixes #6470
* cocoa-cb: fix optional cases on macOS 10.12der richter2019-07-211-4/+4
|
* build: fix build with older command line toolsder richter2019-07-211-8/+28
|
* build: make macOS SDK path and version configurable via env varsder richter2019-07-211-3/+15
|
* cocoa-cb: conditional compilation for Dark Mode and Material featuresder richter2019-07-214-2/+40
| | | | Fixes #6621
* build: add check for macOS SDK versionder richter2019-07-212-1/+22
| | | | | this provides an easy way to check for a specific macOS SDK version and with that the availability of features.
* osxbundle: bundle the dynamic swift std library when neededder richter2019-07-211-1/+20
|
* osxbundle: print the output of the dylib-unhell callder richter2019-07-211-2/+2
|
* build: add Swift dynamic linking supportder richter2019-07-212-2/+26
| | | | | | | | | | | | | | | this is in preparation for the upcoming swift 5 transition, where static linking was replaced by dynamic linking the swift libraries as the preferred way, by Apple. furthermore Apple removed the static swift libs from their dev Tools starting with xcode 10.2/swift 5. because of ABI incompatibility dynamic linking for swift versions prior to 5 doesn't use the system lib path for the dynamic swift libs. for now static linking is still the default, but that will be changed when swift 5 support is added and swift 3 support is dropped. Fixes #6232
* build: make Swift lib and compiler paths configurable via env varsder richter2019-07-211-6/+22
|
* build: add support for Swift toolchains not provided by Appleder richter2019-07-211-12/+48
| | | | | | | | | | | | | | | | | | the xcode-select tool only properly works with Apple provided toolchains but not with third party ones from swift.org. in the latter case the swift compiler executable is found in the proper path but the swift libs from the xcode or command line tools will be picked. this leads to a not wanted discrepancy of the swift compiler and libs and possible errors. instead of relying on the xcode-select tool search for the libs relative to the swift executable. that relative path seems to be the same for all toolchains. if for any reasons a swift executable is not found in the relative path, fall back to the old xcode-select method. furthermore, both static and dynamic libs will be searched for but only the former will be used for now. this is a preparation for the upcoming swift 5 migration.
* build: add all configure flags as conditional flags to Swift compilerder richter2019-07-211-0/+10
|
* build: don't check for Swift when disabledder richter2019-07-211-1/+2
|
* client: fix potential mpv_cmd/async leakdudemanguy2019-07-081-4/+8
|
* vo_gpu: hwdec_vaapi: Count planes rather than layers in Vulkan interopPhilip Langdale2019-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | We saw a segfault when trying to use the intel-media-driver (iHD) rather than the normal intel va driver. This happened because the iHD driver reports P010 (and maybe other formats) with multiple layers to represent the interleaved UV plane. The normal va driver reports one UV layer to match the plane. This threw off my logic which assumed that the number of layers could not exceed the number of planes. There's a way one could fix this in a fully generalised form, but I'm just going to do what the EGL path does and assume that: * Layer 'n' is on Plane 'n' for n < total number of planes * These layers always start at offset 0 on the plane You can imagine ways that these assumptions are violated, but at least the failure will look the same for both EGL and Vulkan paths.
* vo_gpu: hwdec_vaapi: Suppress format errors when probingPhilip Langdale2019-07-082-3/+7
| | | | | | | | | | Today, we normally see a format error when probing because yuyv422 cannot be used, but it's in the normal set of probed formats. This error is distracting and confusing, so only log probing errors at the VERBOSE level. Fixes #6411
* vo_gpu: hwdec_vaapi: Add Vulkan interopPhilip Langdale2019-07-085-158/+304
| | | | | | | | | | | | | | | | | | | | | | | | This change introduces a vulkan interop path for the vaapi hwdec. The basic principles are mostly the same as for EGL, with the exported dma_buf being imported by Vukan. The biggest difference is that we cannot reuse the texture as we do with OpenGL - there's no way to rebind a VkImage to a different piece of memory, as far as I can see. So, a new texture is created on each map call. I did not bother implementing a code path for the old libva API as I think it's safe to assume any system with a working vulkan driver will have access to a newer libva. Note that we are using separate layers for the vaapi surface, just as is done for EGL. This is because libplacebo doesn't support multiplane images. This change does not include format negotiation because no driver implements the vk_ext_image_drm_format_modifier extension that would be required to do that. In practice, the two formats we care about (nv12, p010) work correctly, so we are not blocked. A separate change had to be made in libplacebo to filter out non-fatal validation errors related to surface sizes due to the lack of format negotiation.
* vo_gpu: hwdec_vaegl: Rename and move to hwdec_vaapiPhilip Langdale2019-07-082-1/+1
| | | | | In preparation for adding Vulkan interop support, let's rename to remove the egl reference and move to an api neutral location.
* vf_vapoursynth: allow multithreaded writing of source framesChainik2019-07-081-0/+3
|
* vf_vapoursynth: allow multithreaded reading of returned framesChainik2019-07-081-8/+9
|
* vo/gpu: hwdec_vdpau: Support direct mode for 4:4:4 contentPhilip Langdale2019-07-084-5/+20
| | | | | | | New releases of VDPAU support decoding 4:4:4 content, and that comes back as NV24 when using 'direct mode' in OpenGL Interop. That means we need to be a little bit smarter about how we set up the OpenGL textures.
* opengl/context_wayland: Fix crash on configure before initial reconfigMichael Forney2019-07-081-1/+3
| | | | | | | | | If the compositor sends a configure event before the surface is initially mapped, resize gets called before the egl_window gets created, resulting in a crash in wl_egl_window_resize. This was fixed back in 618361c697, but was reintroduced when the wayland code was rewritten in 68f9ee7e0b.
* video/out/gpu: Add a `storable` flag to ra_formatPhilip Langdale2019-07-085-1/+9
| | | | | | | | | | | | | | | | While `ra` supports the concept of a texture as a storage destination, it does not support the concept of a texture format being usable for a storage texture. This can lead to us attempting to create a texture from an incompatible format, with undefined results. So, let's introduce an explicit format flag for storage and use it. In `ra_pl` we can simply reflect the `storable` flag. For GL and D3D, we'll need to write some new code to do the compatibility checks. I'm not going to do it here because it's not a regression; we were already implicitly assuming all formats were storable. Fixes #6657
* codec_tags: fix wrong buffer sizewm42019-07-031-1/+1
| | | | | | | Obvious mistake. This reported 44 bytes more data than what was available. Could cause out of bounds reads. Security researchers would claim a major victory if they found something like this in more popular software, and would create a website for it.
* appveyor: remove broken packages, install libplaceboJames Ross-Gowan2019-07-033-3/+7
| | | | | | | | Support for Ada and Objective-C was removed from MSYS2, which made pacman refuse to update GCC while the gcc-ada and gcc-objc packages were installed. Remove those packages before updating the others. Also remove ANGLE, which has been removed from MSYS2, and add libplacebo, which is now needed for the Vulkan VO.
* vo_gpu: process three component together in error diffusionBin Jin2019-06-161-42/+70
| | | | | | | | | | | | | | | | This started as a desperate attempt to lower the memory requirement of error diffusion, but later it turns out that this change also improved the rendering performance a lot (by 40% as I tested). Errors was stored in three uint before this change, each with 24bit precision. This change encoded them into a single uint, each with 8bit precision. This reduced the shared memory usage, as well as number of atomic operations, all by three times. Before this change, with the minimum required 32kb shared memory, only the `simple` kernel can be used to render 1080p video, which is mostly useless compare to `--dither=fruit`. After this change, 32kb can handle `burkes` kernel for 1080p, or `sierra-lite` for 4K resolution.
* vo_gpu: fix use of existing textures in error diffusionBin Jin2019-06-161-6/+8
| | | | | | | error diffusion requires two texture rendering pass. The existing code reuses `screen_tex` and creates another for such purpose. This works generally well for opengl, but could potentially be problematic for vulkan, due to its async natural.
* vo_gpu: implement error diffusion for ditheringBin Jin2019-06-166-1/+454
| | | | | | | | | | | | | | | | | This is a straightforward parallel implementation of error diffusion algorithms in compute shader. Basically we use single work group with maximal possible size to process the whole image. After a shift mapping we are able to process all pixels column by column. A large ring buffer are allocated in shared memory to speed things up. However the size of required shared memory depends linearly on the height of video window (or screen height in fullscreen mode). In case there is no enough shared memory, it will fallback to `--dither=fruit`. The maximal allowed work group size is hardcoded as 1024. Ideally we could query `GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS`. But for whatever reason, it seems most high end card from nvidia and amd support only the minimal required value, so I guess we can stick to it for now.
* ci: Remove snapshot-deps config from tw buildsMartin Herkt2019-06-141-2/+0
| | | | | OBS isn’t really set up to support this. If needed, we should instead git clone FFmpeg as part of the CI. I don’t think it is, though.
* build: Add support for static spirv-crossMartin Herkt2019-06-141-1/+14
| | | | | This assumes a non-upstream .pc file since upstream doesn’t seem to give a fuck about this use case at all.
* demux_mkv: copy attachments (fonts) from ordered chapter sourcesPhilip Sequeira2019-06-121-0/+10
| | | | | | They might be needed for rendering subs from those sources. Fixes #6009.
* vo_gpu: d3d11: use the SPIRV-Cross C API directlyJames Ross-Gowan2019-06-124-28/+77
| | | | | | | | | | When the D3D11 backend was first written, SPIRV-Cross only had a C++ API and no guarantee of API or ABI stability, so instead of using SPIRV-Cross directly, mpv used an unofficial C wrapper called crossc. Now that KhronosGroup/SPIRV-Cross#611 is resolved, SPIRV-Cross has an official C API that can be used instead, so remove crossc and use SPIRV-Cross directly.
* vo_gpu: fix --scaler-resizes-only for fractional ratio scalingBin Jin2019-06-061-3/+6
| | | | | | | | The calculation of scale factor involves 32-bit float, and a strict equality test will effectively ignore `--scaler-resizes-only` option for some non-integer scale factor. Fix this by using non-strict equality check.
* vo_gpu: expose texture_off to user shaderBin Jin2019-06-061-0/+1
| | | | | It will provide low level access to coordinate mapping other than texmap().
* vo_gpu: allow user shader to fix texture offsetBin Jin2019-06-064-10/+52
| | | | | This commit essentially makes user shader able to fix offset (produced by other prescaler, for example) like builtin `--scale`.
* wayland: fix segfault on uninitNiklas Haas2019-05-261-1/+1
| | | | Probably the same issue as #6732
* wayland: fix various memory leaksdudemanguy2019-05-211-0/+33
|
* cocoa-cb: fix quit in fs with none native fsder richter2019-05-111-1/+2
| | | | | | | | | | since the none native fs is a special legacy case it needs a special quit routine. it indefinitely waited for an exit fs screen event to shutdown properly, though that event only fires for the native fs. now we check if we really are using a native fullscreen and if not shutdown immediately. Fixes #6704
* win32-console-wrapper: silence missing prototype warningsJames Ross-Gowan2019-05-101-2/+4
|
* w32_common: avoid unnecessary sprintfsJames Ross-Gowan2019-05-101-8/+5
| | | | | | | | | | These were unnecessary for a couple of reasons, but it seems like the old code went through a lot of effort to avoid duplicating the code to print a RECT, even though the windowrc gets printed anyway at the end of the function. Avoid printing the same windowrc twice by only printing it when it gets changed (in the w32->current_fs branch.)
* man: clarify vavpp requirementsNicolas F2019-05-051-2/+3
| | | | | | | | | | | | I assume (but cannot confirm) that VA-AP-API is in fact a typo, because most if not all search engine results related to it are from mpv's manual page. By changing this to VA-API and clarifying that this requires VA-API support on a system to use it, we can hopefully make it clear to unsuspecting Windows users that this is not the filter they're looking for. Concerns #6690.
* libarchive: add fallback for systems without C.UTF-8dudemanguy2019-05-042-2/+6
|
* drm_common: Support --drm-mode=<preferred|highest|N|WxH[@R]>Anton Kindestam2019-05-042-16/+241
| | | | | | | This allows to select the drm mode using a string specification. You can either select the the preferred mode, the mode with the highest resolution, by specifying WxH[@R] or by its index in the list of modes as before.
* drm_common: Don't export functions only being used internallyAnton Kindestam2019-05-042-22/+22
| | | | | As far as I know none of these functions were being used outside of drm_common, nor should there really be a need to use them.
* drm_common: Add proper help option to drm-modeAnton Kindestam2019-05-045-26/+95
| | | | | | | This was implemented by using OPT_STRING_VALIDATE for drm-mode, instead of OPT_INT. Using a string here also prepares for future additions to drm-mode that aim to allow specifying a mode by its resolution.
* drm_common: Add option to toggle use of atomic modesettingAnton Kindestam2019-05-045-11/+29
| | | | | | It is useful when debugging to be able to force atomic off, or as a workaround if atomic breaks for some user. Legacy modesetting is less likely to break by virtue of being a less complex API.
* vo/gpu: hwdec_cuda: Refactor gpu api specific code into separate filesPhilip Langdale2019-05-036-750/+848
| | | | | | | | The amount of code now present that's specific to Vulkan or OpenGL has reached the point where we really want to split it out to avoid a mess of #ifdefs. At the same time, I'm moving the code to an api neutral location.
* context_drm_egl: Add support for presentation feedbackAnton Kindestam2019-05-031-15/+118
| | | | | This implements presentation feedback for context_drm_egl using the values that get fed to the page flip handler.
* cocoa-cb: remove all force unwrappings of optionalsder richter2019-04-257-334/+448
| | | | | | the force unwrapping of optionals caused many unpredictable segfaults instead of gracefully exiting or falling back. besides that, it is bad practice and the code is a lot more stable now.
* vo_gpu/hwdec_cuda: fixup compilation with vulkan disabledJan Ekström2019-04-221-0/+2
| | | | | | | The actual code utilizing this enum was seemingly properly if'd, but not the enum in the struct itself. Fixes compilation.
* docs: add mentions of the Vulkan rendering abstraction replacementJan Ekström2019-04-222-0/+54
| | | | From internal to libplacebo.
* vo/gpu: hwdec_cuda: Reorganise backend-specific codePhilip Langdale2019-04-211-151/+223
| | | | | This tries to tidy up the GL vs Vulkan code to be a bit cleaner and easier to read.
* vo_gpu: hwdec_cuda: Implement interop for placeboPhilip Langdale2019-04-212-146/+225
| | | | | | | | | | | | | | | | | | | | This change updates the vulkan interop code to work with the libplacebo based ra_vk, but also introduces direct VkImage sharing to avoid the use of the intermediate buffer. It is also necessary and desirable to introduce explicit semaphore bsed synchronisation for operations on the shared images. Synchronisation means we can safely reuse the same VkImage for every mapped frame, by ensuring the frame is copied to the VkImage before mapping the next frame. This functionality requires a 417.xx or newer nvidia driver, due to bugs in the VkImage interop in the earlier 411 and 415 drivers. It's definitely worth the effort, as the raw throughput is about twice that of implementation using an intermediate buffer.
* vo/gpu: ra_pl: Add helper to get pl_fmt from ra_formatPhilip Langdale2019-04-211-0/+5
| | | | | | | When interacting directly with libplacebo, we may need to pass a pl_fmt based on an ra_format. Although the mapping is currently trivial, it's worth wrapping to make it easy to adapt if this changes in the future.
* vo_gpu: ra_pl: Add getter for pl_gpuPhilip Langdale2019-04-212-1/+8
| | | | | We need access to the underlying pl_gpu to make libplacebo calls from hwdecs.
* vo_gpu: vulkan: Add back context_win for libplaceboPhilip Langdale2019-04-213-4/+106
| | | | | Feature parity with the original ra_vk obviously requires win32 support, so let's put it back in.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-2124-4368/+868
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* mp_image: align stride to multiple of texel sizeNiklas Haas2019-04-211-0/+3
| | | | | | | This helps with compatibility and/or performance in particular for oddly-sized formats like rgb24. We use a loop to avoid having to calculate the lcm (or waste bytes in the extremely common case of the byte size and the stride align having shared factors).
* vo_gpu: fix segfault when OSD tex creation failsNiklas Haas2019-04-211-1/+1
| | | | If !osd->texture, then mpgl_osd_draw_prepare fails.
* vo_gpu: index desc namespaces by raNiklas Haas2019-04-215-5/+5
| | | | | No reason to require them be constant. This allows them to depend on runtime characteristics of the `ra`.
* appveyor: fix shaderc dependenciesJames Ross-Gowan2019-04-161-4/+3
| | | | | | Shaderc comes with a Python script that automatically fetches "known-good" versions of its dependencies. Use that instead of manually cloning dependencies to third-party.
* version.sh: update MPVCOPYRIGHT to include the current year, 2019JCount2019-04-161-1/+1
|
* options/path: fix url detection per RFC3986john2019-04-051-3/+7
|
* ao/audiounit: include AVAudioSession buffer in latency calcAman Gupta2019-04-051-1/+1
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* ao/audiounit: improve a/v syncAman Gupta2019-04-053-4/+18
| | | | | | | This more closely mimics ao_coreaudio, on which this driver was originally based. Signed-off-by: Aman Gupta <aman@tmm1.net>
* man/input: clarify behavior of seek's +exactNoSuck2019-04-021-2/+3
| | | | | | As discussed here: https://github.com/mpv-player/mpv/issues/6545#issuecomment-476015318
* cocoa-cb: add support for custom colored title barder richter2019-04-027-0/+44
|
* cocoa-cb: refactor title bar stylingder richter2019-04-027-63/+192
| | | | | | | | | | | | | half of the materials we used were deprecated with macOS 10.14, broken and not supported by run time changes of the macOS theme. furthermore our styling names were completely inconsistent with the actually look since macOS 10.14, eg ultradark got a lot brighter and couldn't be considered ultradark anymore. i decided to drop the old option --macos-title-bar-style and rework the whole mechanism to allow more freedom. now materials and appearance can be set separately. even if apple changes the look or semantics in the future the new options can be easily adapted.
* cocoa-cb: add support for mac 10.14 Dark mode and run time switchingAkemi2019-04-021-5/+10
| | | | | | setting the appearance of the window to nil will always use the system setting and changes on run time switches too. this is only the case for macOS 10.14.
* cocoa-cb: move all title bar related functionality in its own fileder richter2019-04-025-156/+179
| | | | | | | | | quite a lot of the title bar functionality and logic was within our window. since we recently added a custom title bar class to our window i decided to move all that functionality into that class and in its own file. this is also a preparation for the next commits.
* cocoa-cb: remove an unused variableAkemi2019-04-021-1/+0
|
* cocoa-cb: simplify CGL pixel format creationAkemi2019-04-021-57/+75
| | | | | | | | | | | | | | | i found the old pixel format creation a bit too messy. pixel format attribute arrays and look ups were all over the place, the actual logic what kind of format was created was inscrutable, the software pixel format was hardcoded and no probing was done. i split the attributes into mandatory and optional ones, one mandatory for a hardware and software pixel format each, and moved those to the top of the class. that way new attributes can be easily added to either the mandatory or optional attributes and they don't mess up the actual pixel creation logic any more. furthermore both hardware and software pixel formats are being probed the same way now. to minimise code duplications the probing was moved into its own function.
* cocoa-cb: add support for dragging certain strings onto the windowAkemi2019-04-021-2/+31
| | | | | | | | | | | | | | | only the dragged types NSFilenamesPboardType and NSURLPboardType were supported to be dropped on the window, which was inconsistent with the dragged types the dock icon supports. the dock icon additional supports strings that represents an URL or a path. the system takes care of validating the strings properly in the case of the dock icon, but in the case of dropping on the window it needs to be done manually. support for strings is added by also allowing the NSPasteboardTypeString type and manually validating the strings. strings are split by new lines and trimmed, to also support a list of URLs and paths. every new element is checked if being an URL or path and only then being added to the playlist.
* cocoa-cb: synchronise the flush with the renderAkemi2019-04-022-4/+6
| | | | | | | this could lead to a crash on deinit when flush was called while the opengl state was cleaned up. Fixes #6323
* cocoa-cb: fix a Cocoa window position on init bugAkemi2019-04-021-0/+13
| | | | | | | | | | | | on init an NSWindow can't be placed on a none Main screen NSScreen outside the Main screen's frame bounds. To fix this we just check if the target screen is different from the main screen and if that is the case we check the actual position with the expect one. if they are different we try to reposition the window to the wanted position. Fixes #6453
* cocoa-cb: fix Space switching when quitting fsAkemi2019-04-021-4/+6
| | | | | | | when quitting mpv in fullscreen the System always switchs to Space 1 regardless of which Space mpv was on previous to switching to fs. to fix this we close the window before quitting fs. that way the System switches back the the Space mpv was previous on before fs.
* cocoa-cb: notify vo when window is minimisedAkemi2019-04-021-0/+8
|
* cocoa-cb: fix crash when querying window stateAkemi2019-04-021-1/+2
| | | | Fixes #6489
* cocoa-cb: wakeup vo when new events are availableAkemi2019-04-022-0/+3
| | | | | | | new events were added but not fetched by the vo, because we didn't signal the vo that new events were available. actually wakeup the vo when new events are available.
* build: bump minimum swift version to 3.0.2Akemi2019-04-021-1/+1
| | | | | | | | | | #6299 reported problems with earlier 3.0.x swift versions. i tested with 3.0.2/SDK 10.12.2 and just assumed it also works with the older 3.0.x swift and 10.12.x SDK versions. due to the unstable nature of swift there were slight API differences that caused build problems. since swift is bundled with the SDK we just bump the minimum swift version.
* build: slightly adjust swift check output messages on failder richter2019-04-021-3/+7
| | | | to make it consistent with the other checks and their output messages.
* build: use StrictVersion for swift version comparisonAkemi2019-04-022-7/+7
|
* demux: support cue sheets longer than 100 minuteszc622019-04-011-7/+8
| | | | | | | Remove the 2-digit-number restriction when reading the number of minutes in the cue sheet INDEX command. Fixes #6481
* player: show restart positionAman Gupta2019-04-011-1/+1
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* DOCS/man/mpv.rst: Fix big-cache profile exampleLeo Izen2019-03-161-1/+2
| | | | | | The cache options were changed, and this commit fixes the example big-cache profile to use the new cache options.
* x11: fix cursor hiding initial statePhilip Sequeira2019-03-162-2/+4
| | | | | | | | | Regression from 8e3308d687c3acdd0d572015b06efd5b492d93ee. Broken cases were: * --no-cursor-autohide acted like --cursor-autohide=always. * --cursor-autohide-fs-only always hid the cursor if starting non-fullscreen; entering fullscreen at least once fixed it.
* vo_gpu: increase user shader size limitBin Jin2019-03-131-1/+1
| | | | | | | | | | | | | The old size limit was chosen before LUT texture was supported in user shader. At that time, the whole user shader will be compiled and run on GPU, which makes large user shader impractical to be used. With the introduction of LUT texture, the old size limit doesn't make any sense. For example, a 1024x1024 rgba16f LUT will cost 32MB shader size. Fix this by increasing the size limit to a value that's unlikely be reached.
* build: fix adding of object files to linking with cplugins disabledAkemi2019-03-131-1/+1
| | | | | | | | | | | | this was meant to be fixed by 546f038, but with --disable-cplugins the do_the_symbol_stuff function was never called and the handle_add_object function was again always called before the actual linking task was created. to fix this we explicitly call handle_add_object only after all the tasks the do_the_symbol_stuff function is called after too. Fixes #6028
* macosx_events: fix crash when shutting down during window animationsRodger Combs2019-03-131-1/+3
|
* build: enable swift debug information when requestedRodger Combs2019-03-131-0/+3
|
* player: fix core activity state checkAvi Halachmi (:avih)2019-03-121-1/+1
| | | | | | | | | | | | Adds the negation missed in 8816e1117ee65039dbb5700219ba3537d3e5290e when moving from a positive-is-active to positive-is-idle variable. This leads to proper updates to properties such as "eof-reached", as well as fixes screensaver state updates. Separately found and fixed by avih and wnoun. Co-authored-by: wnoun <wnoun@outlook.com>
* vo_libmpv: fix null pointer dereferencewnoun2019-03-111-3/+5
| | | | Closes: #6507
* Merge branch 'master' into pr6360Jan Ekström2019-03-1132-318/+583
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * vo_gpu: add two useful operators to user shaderBin Jin2019-03-092-0/+7
| | | | | | | | | | | | | | | | modulo operator could be used to check if size is multiple of a certain number. equal operator could be used to verify if size of different textures aligns.
| * vo_gpu: make texture offset available to CHROMA hooksBin Jin2019-03-091-16/+25
| | | | | | | | | | | | | | | | | | | | Before this commit, texture offset is set after all source textures are finalized. Which means CHROMA hooks won't be able to align with luma planes. This could be problematic for chroma prescalers utilizing information from luma plane. Fix this by find the reference texture early, and set global texture offset early.
| * lcms: allow infinite contrastzc622019-03-092-3/+5
| | | | | | | | Fixes #5980
| * demux_edl: don't assume data follows a comment linePhilip Sequeira2019-03-031-1/+3
| | | | | | | | | | | | There could be another comment line or the end of the file. Fixes #6529.
| * sub: recognize UTF-8 characters in SDH subtitle filterzc622019-03-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | Only printable ASCII characters were considered to be valid texts. Make it possible that UTF-8 contents are also considered valid. This does not make the SDH subtitle filter support non-English languages. This just prevents the filter from blindly marking lines that have only UTF-8 characters as empty. Fixes #6502
| * options: do not enable WMV3 hwdec by defaultMartin Herkt2019-03-012-2/+2
| | | | | | | | | | | | Crashes NVIDIA, probably buggy on others. No one ever tests this shit. See #2192
| * demux: fix seek range update after head packets are prunedGunnar Marten2019-03-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | The seek range update was to early and did not take the removed head packets into account. And therefore missed that the queue was not BOF anymore. This led to not be able to backward seek before the first packet of the first seek range. Fix it by moving the seek range update after the possible removal and the change of the BOF flag. Fixes: #6522
| * player: do not rebase start time for subtitle streamszc622019-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | As stated in the original commit message, if the demuxer set the start time to the first subtitle packet, the subtitles would be shifted incorrectly. It appears that it is the case for external PGS subtitles. This reverts commit 520fc7403621156676b1ca183aed4911bf6c47b5. Fixes #5485
| * context_drm_egl: implement n-bufferingAnton Kindestam2019-02-251-59/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows context_drm_egl to use as many buffers as libgbm or the swapchain_depth setting allows (whichever is smaller). On pause and on still images (cover art etc.) to make sure that output does not lag behind user input, the swapchain is drained and reverts to working in a dual buffered (equivalent to swapchain-depth=1) manner. When possible (swapchain-depth>=2), the wait on the page flip event is now not done immediately after queueing, but is deferred to the next invocation of swap_buffers. Which should give us more CPU time between invocations. Although, since gbm_surface_has_free_buffers() can only tell us a boolean value and not how many buffers we have left, we are forced to do this contortionist dance where we first overshoot until gbm_surface_has_free_buffers() reports 0, followed by immediately waiting so we can free a buffer, to be able to get the deferred wait on page flip rolling. With this commit we do not rely on the default vsync fences/latency emulation of video/out/opengl/context.c, but supply our own, since the places we create and wait for the fences needs to be somewhat different for best performance. Minor fixes: * According to GBM documentation all BO:s gotten with gbm_surface_lock_front_buffer must be released before gbm_surface_destroy is called on the surface. * We let the page flip handler function handle the waiting_for_flip flag.
| * opengl: Support GL_ARB_sync style fences on OpenGL ES 3.0Anton Kindestam2019-02-251-0/+1
| | | | | | | | | | OpenGL ES 3.0 and up has suppport for for GL_ARB_sync style fences. Make sure that mpv can use them.
| * audio: fix segfault caused by incorrect number of planeszc622019-02-231-1/+1
| | | | | | | | | | | | | | Use `mp_aframe_get_planes` to properly get the number of planes, instead of assuming it to be the number of channels. Fixes #6092
| * vo_gpu: fix initial seeding of the peak detect ssboNiklas Haas2019-02-182-5/+7
| | | | | | | | | | | | | | This solves some edge cases when using files with very weird metadata (e.g. MaxCLL 10k and so forth). Instead of just blindly seeding it with the tagged metadata, forcibly set the initial state from the detected values.
| * vo_gpu: use dB units for scene change detectionNiklas Haas2019-02-184-14/+15
| | | | | | | | | | | | | | Rather than the linear cd/m^2 units, these (relative) logarithmic units lend themselves much better to actually detecting scene changes, especially since the scene averaging was changed to also work logarithmically.
| * vo_gpu: clamp sigmoid functionNiklas Haas2019-02-181-0/+2
| | | | | | | | Can explode on some clips otherwise
| * vo_gpu: tone map before gamut mappingNiklas Haas2019-02-181-5/+4
| | | | | | | | | | | | Gamut mapping can take very bright out-of-gamut colors into the negatives, which completely destroys the color balance (which tone mapping tries its best to preserve).
| * vo_gpu: make --gamut-warning warn on negative colorsNiklas Haas2019-02-181-1/+2
| | | | | | | | | | As is the case for actually out-of-gamut colors (rather than just too bright colors).
| * vo_gpu: improve numerical accuracy of PQ OETF constantNiklas Haas2019-02-181-1/+1
| | | | | | | | | | Not a huge deal, but we can do the division in C, which makes the float constant larger.
| * vo_gpu: allow color management in dumb modeNiklas Haas2019-02-181-5/+6
| | | | | | | | | | There's no point to disallow target-trc/prim in dumb mode, since they still work fine.
| * vo_gpu: improve accuracy of HDR brightness estimationNiklas Haas2019-02-182-10/+14
| | | | | | | | | | | | | | This change switches to a logarithmic mean to estimate the average signal brightness. This handles dark scenes with isolated highlights much more faithfully than the linear mean did, since the log of the signal roughly corresponds to the perceptual brightness.
| * vo_gpu: allow boosting dark scenes when tone mappingNiklas Haas2019-02-185-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | In theory our "eye adaptation" algorithm works in both ways, both darkening bright scenes and brightening dark scenes. But I've always just prevented the latter with a hard clamp, since I wanted to avoid blowing up dark scenes into looking funny (and full of noise). But allowing a tiny bit of over-exposure might be a good thing. I won't change the default just yet (better let users test), but a moderate value of 1.2 might be better than the current 1.0 limit. Needs testing especially on dark scenes.
| * vo_gpu: redesign peak detection algorithmNiklas Haas2019-02-185-77/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous approach of using an FIR with tunable hard threshold for scene changes had several problems: - the FIR involved annoying hard-coded buffer sizes, high VRAM usage, and the FIR sum was prone to numerical overflow which limited the number of frames we could average over. We also totally redesign the scene change detection. - the hard scene change detection was prone to both false positives and false negatives, each with their own (annoying) issues. Scrap this entirely and switch to a dual approach of using a simple single-pole IIR low pass filter to smooth out noise, while using a softer scene change curve (with tunable low and high thresholds), based on `smoothstep`. The IIR filter is extremely simple in its implementation and has an arbitrarily user-tunable cutoff frequency, while the smoothstep-based scene change curve provides a good, tunable tradeoff between adaptation speed and stability - without exhibiting either of the traditional issues associated with the hard cutoff. Another way to think about the new options is that the "low threshold" provides a margin of error within which we don't care about small fluctuations in the scene (which will therefore be smoothed out by the IIR filter).
| * vo_gpu: improve tone mapping desaturationNiklas Haas2019-02-186-87/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
| * wayland_common: rename “shell” into “wm_base”Emmanuel Gil Peyrot2019-02-172-11/+11
| | | | | | | | | | | | | | | | This is the naming xdg-shell stable adopted, it doesn’t make much sense to keep using “shell” everywhere with all functions calling it “wm_base”. Finishes what 76211609e3c589dafe3ef9a36cacc06e8f56de09 started.
| * options: do not enable MPEG2 hwdec by defaultMartin Herkt2019-02-132-2/+2
| | | | | | | | | | | | | | | | Too many broken hardware decoders. Noticed wrong decoding of a video file encoded with x262 on RX Vega when using VAAPI (Mesa 18.3.2). Looks fine with swdec and a cheap hardware BD player. Reverts 017f3d0674e48a587b9e6cd7a48f15519c799c3e
| * cocoa-cb: remove empty elements from dropped URLsAkemi2019-02-101-1/+2
| | | | | | | | Fixes #6241
| * cocoa-cb: add support for VOCTRL_GET_DISPLAY_NAMESAkemi2019-02-105-1/+56
| |
| * cocoa-cb: use Swift Extensions for convenienceAkemi2019-02-102-7/+32
| | | | | | | | preparations for the following commit.
| * mac: add missing semicolon to macosx_compat.hKen2019-01-261-1/+1
| | | | | | | | fixes build on older systems
| * wscript_build: de-duplicate build file listAman Gupta2019-01-251-4/+2
| |
| * cocoa-cb: fix side by side Split View againAkemi2019-01-231-3/+2
| | | | | | | | | | | | | | | | | | | | some safety mechanism for the async fs animation aren't needed anymore, due to possible improved logic and slightly different behaviour on new macOS versions. that safety fallback prevented the Split View because it always returned a rectangle of the whole screen, instead of just part/half of it. Fixes #6443
| * DOCS/options.rst: update target-peak descriptionKotori Itsuka2019-01-231-4/+4
| | | | | | | | | | List auto as an option for target-peak, and state that auto is its default operation.
| * vo_gpu: allow resetting target-peak to the trc defaultKotori Itsuka2019-01-231-1/+2
| | | | | | | | | | | | | | | | | | Add "auto" the possible values of target-peak. The default value for target_peak is to calculate the target using mp_trc_nom_peak. Unfortunately, this default was outside the acceptable range of 10-10000 nits, which prevented its later reassignment. So add an "auto" choice to target-peak which lets clients and scripts go back to using the trc default after assigning a value.
| * vd_lavc: increase the possible length of the hwdec nameAkemi2019-01-231-1/+1
| | | | | | | | | | | | | | this lead to an unexpected videotoolbox-copy hwdec name due to the last two chars being cut off. since selection is also done by that name one had to use "videotoolbox-co" to explicitly use the copy mode of videotoolbox.
| * stats: merge multiple properties into one lineJulian2019-01-161-4/+4
| | | | | | | | | | | | | | Merge file-size/file-format and audio channel-count/format into one line respectively. This fixes stats overflowing the screen in larger than 19:6 aspect ratios. In this case a problem was reported for ~21:9 which should be common enough for us to "support" it.
| * lua: execute idle handlers after timers have been processedOlivier Perret2019-01-161-6/+3
| | | | | | | | | | | | | | Idle handlers used to not be executed when timers were active Now they are executed: * After all expired timers have been executed * After all events have been processed (same as when there are no timers)
| * DOCS/man: update man pages to describe ReplayGain fallbackBenjamin Barenblat2019-01-161-2/+4
| | | | | | | | | | | | Describe ReplayGain album-to-track fallback behavior introduced in commits e392d6610d1e35cc0190c794c151211b0aae83e6 and be90f2c8dd0431e252e43d5249e89446309113af.
| * demux: make ALBUM ReplayGain tags optional when using libavformatBenjamin Barenblat2019-01-162-11/+27
| | | | | | | | | | | | | | Commit e392d6610d1e35cc0190c794c151211b0aae83e6 modified the native demuxer to use track gain as a fallback for album gain if the latter is not present. This commit makes functionally equivalent changes in the libavformat demuxer.
| * command: notify on multiplyDan Oscarsson2019-01-161-0/+1
| | | | | | | | | | doing multiply on a property is also a set property command and the change should be notified so others can observe the change
| * stream_dvb: Correct range for dvbin-card option.Oliver Freyermuth2018-12-122-4/+4
| | | | | | | | | | | | Adapt documentation accordingly and also, fix an off-by-one check in the code. closes #6371
* | docs: add removed properties and options to interface-changes.rstsfan52018-12-062-3/+4
| |
* | stats: remove duplicate cache sizessfan52018-12-061-7/+4
| | | | | | | | The stream cache no longer exists, so there is no need to show the demuxer cache separately anymore.
* | demux: fix regression in decision about stream cachingsfan52018-12-061-1/+1
| | | | | | | | | | The `streaming` flag covers more cases than just networked streams, such as files read from NFS, SMB or FUSE mountpoints.
* | demux: fix memleak in allocation with params=NULLNiklas Haas2018-12-061-1/+1
| | | | | | | | | | The default behavior for `does not own stream` should be false, but this condition is inverted so we need to default the base case to `true`.
* | osd: another shitty pointless UBwm42018-12-061-2/+4
| | | | | | | | | | The pointer could be NULL if the number of bytes to copy was 0. In a sane world, this would be fine, but not the current world.
* | demux: fix some theoretical UB with no impactwm42018-12-061-2/+4
| | | | | | | | | | | | If the number of chapters is 0, the chapter list can be NULL. clang complains that we pass NULL to qsort(). This is yet another pointless UB that exists for no reason other than wasting your time.
* | x11: don't hide cursor if window isn't focusedwm42018-12-062-20/+33
| | | | | | | | | | | | | | I found this sort of annoying. You could argue that the "frontend" should maybe contain this logic, but who cares.
* | stream: silence failed seek message on terminationwm42018-12-061-1/+2
| | | | | | | | | | | | Seems to happen often with ytdl pseudo-DASH streams, so whatever. I couldn't reproduce it and check what triggers it, I just remember seeing the error message and found it annoying.
* | stream: somethingwm42018-12-061-3/+4
| |
* | vo, vo_gpu, glx: correct GLX_OML_sync_control usagewm42018-12-063-84/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I misunderstood how this extension works. If I understand it correctly now, it's worse than I thought. They key thing is that the (ust, msc, sbc) tripple is not for a single swap event. Instead, (ust, msc) run independently from sbc. Assuming a CFR display/compositor, this means you can at best know the vsync phase and frequency, but not the exact time a sbc changed value. There is GLX_INTEL_swap_event, which might work as expected, but it has no EGL equivalent (while GLX_OML_sync_control does, in theory). Redo the context_glx sync code. Now it's either more correct or less correct. I wanted to add proper skip detection (if a vsync gets skipped due to rendering taking too long and other problems), but it turned out to be too complex, so only some unused fields in vo.h are left of it. The "generic" skip detection has to do. The vsync_duration field is also unused by vo.c. Actually this seems to be an improvement. In cases where the flip call timing is off, but the real driver-level timing apparently still works, this will not report vsync skips or higher vsync jitter anymore. I could observe this with screenshots and fullscreen switching. On the other hand, maybe it just introduces an A/V offset or so. Why the fuck can't there be a proper API for retrieving these statistics? I'm not even asking for much.
* | demux_mkv: simplify avi compat. codec_tags.c GUID lookupwm42018-12-061-13/+3
| | | | | | | | | | | | | | The redundancy here always annoyed me. Back then I didn't change it because it's hard to test and I just had fixed something. This doesn't matter anymore, so simplify it, without testing and with the risk that something breaks (why care).
* | demux: remove some dead codewm42018-12-062-10/+0
| | | | | | | | | | No idea what that shit is. Likely forgotten when timed metadata was introduced, and some of the old mechanisms were replaced.
* | demux: add another stream recording featurewm42018-12-065-4/+53
| | | | | | | | | | | | --record-file is nice, but only sometimes. If you watch some sort of livestream which you want to record, it's actually much nicer not to record what you're currently "seeing", but anything you're receiving.
* | demux_lavf: to get effective HLS bitratewm42018-12-061-1/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, this could be easily done with custom I/O. In practice, all the halfassed garbage in FFmpeg shits itself and fucks up like there's no tomorrow. There are several problems: 1. FFmpeg pretends you can do custom I/O, but in reality there's a lot that custom I/O can do. hls.c even contains explicit checks to disable important things if custom I/O is used! In particular, you can't use the HTTP keepalive functionality (needed for somewhat decent HLS performance), because some cranky asshole in the cursed FFmpeg dev. community blocked it. 2. The implementation of nested I/O callbacks (io_open/io_close) is bogus and halfassed (like everything in FFmpeg, really). It will call io_open on some URLs without ever calling io_close. Instead, it'll call avio_close() on the context directly. From what I can tell, avio_close() is incompable to custom I/O anyway (overwhelmed by their own garbage, the fFmpeg devs created the io_close callback for this reason, because they couldn't fix their own fucking garbage). This commit adds some shitty workaround for this (technically triggers UB, but with that garbage heap of a library we depend on it's not like it matters). 3. Even then, you can't proxy I/O contexts (see 1.), but we can just keep track of the opened nested I/O contexts. The bytes_read is documented as not public, but reading it is literally the only way to get what we want. A more reasonable approach would probably be using curl. It could transparently handle the keep-alive thing, as well as propagating cookies etc. (which doesn't work with the FFmpeg approach if you use custom I/O). Of course even better if there were an independent HLS implementation anywhere. FFmpeg's HLS support is so embarrassing pathetic and just goes to show that they belong into the past (multimedia from 2000-2010) and should either modernize or fuck off. With FFmpeg's shit-crusted structures, todic communities, and retarded assholes denying progress, probably the latter. Did I already mention that FFmpeg is a shit fucked steaming pile of garbage shit? And all just to get some basic I/O stats, that any proper HLS consumer requires in order to implement adaptive streaming correctly (i.e. browser based players, and nothing FFmshit based).
* | demux, stream: readd cache-speed in some other formwm42018-12-067-1/+70
| | | | | | | | it's more like an input speed rather than a cache speed, but who cares.
* | vo: use a struct for vsync feedback stuffwm42018-12-067-36/+52
| | | | | | | | So new useless stuff can be easily added.
* | vo_gpu: glx: use GLX_OML_sync_control for better vsync reportingwm42018-12-067-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the extension to compute the (hopefully correct) video delay and vsync phase. This is very fuzzy, because the latency will suddenly be applied after some frames have already been shown. This means there _will_ be "jumps" in the time accounting, which can lead to strange effects at start of playback (such as making initial "dropped" etc. frames worse). The only reasonable way to fix this would be running a few dummy frame swaps at start of playback until the latency is known. The same happens when unpausing. This only affects display-sync mode. Correct function was not confirmed. It only "looks right". I don't have the equipment to make scientifically correct measurements. A potentially bad thing is that we trust the timestamps we're receiving. Out of bounds timestamps could wreak havoc. On the other hand, this will probably cause the higher level code to panic and just disable DS. As a further caveat, this makes a bunch of assumptions about UST timestamps. If there are delayed frames (i.e. we skipped one or more vsyncs), the latency logic is mostly reset. There is no attempt to make the vo.c skipped vsync logic to use this. Also, the latency computation determines a vsync duration, and there's no effort to reconcile or share the vo.c logic for determining vsync duration.
* | Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-0598-3147/+3936
|\ \ | |/ |/| | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-3127-1467/+49
| | | | | | | | | | | | The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
| * rendezvous: fix a typowm42018-08-311-1/+1
| |
| * demux: allow cache sizes > 2GBwm42018-08-241-4/+8
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
| * demux_lavf: v4l streams are not seekablewm42018-08-241-0/+2
| | | | | | | | | | | | | | FFmpeg is retarded enough not to give us any indication whether it is (unless we query fields not in the ABI/API). I bet FFmpeg developers love it when library users have to litter their code with duplicated information.
| * player: don't print status line again when quittingwm42018-08-111-2/+5
| | | | | | | | | | | | | | | | Quitting is slightly asynchronous, so the status line can be updated again. Normally, that's fine, but if quitting comes with a message (such as with quit_watch_later), it will print the status line again after the message, which looks annoying. So flush and clear the status message if it's updated during quitting.
| * HACK: prefetch subtitles on track switch a bit morewm42018-06-301-1/+4
| | | | | | | | To get overlapping shit etc.
| * player: don't cache subtitles across deselectionwm42018-06-302-6/+6
| | | | | | | | | | This means reselection triggers full reinit. This is better if you have options that "edit" subtitles or whatever.
| * player: fix coding stylewm42018-05-241-3/+3
| | | | | | | | | | I'm also not sure whether this condition doesn't subtly break a lot of things.
| * m_config: remove a redundant conditionwm42018-05-241-3/+1
| | | | | | | | Always true, because a few lines above it checks for the same thing.
| * demux_lavf: drop obscure genpts optionwm42018-05-242-11/+0
| | | | | | | | | | This code shouldn't even exist in libavformat. If you still need it, you can enable it via --demuxer-lavf-o.
| * vo: remove bogus #ifwm42018-05-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | If anyone happened to build with GL disabled, this could lead to option changes not always refreshing the screen. Since vo_gpu is always enabled now (just not necessarily any backend for it), we can drop the #if completely. (The way this works is a bit idiotic - the option cache exists only to grab the change notification, which will trigger a redraw and make vo_gpu update its own second copy of them. But at least it avoids some layering issues for now.)
| * terminal-unix: stop trying to read when terminal disappearswm42018-05-241-2/+4
| | | | | | | | | | | | | | | | Avoids 100% CPU usage due to terminal code retrying read(). Seems like this was "forgotten" (or there was somehow the assumption poll() would not signal POLLIN anymore). Fixes #5842.
| * options: add --http-proxywm42018-05-242-0/+11
| | | | | | | | Often requested, trivial.
| * command: avoid some direct MPOpts write accesseswm42018-05-241-7/+7
| | | | | | | | | | | | | | | | | | | | | | This is working towards a change intended in the future: nothing should write to the option struct directly, but use functions that raise proper notifications. Until this is complete it will take a while, and this commit does not change all cases of direct access, just some simple ones. In all of these 3 changes, the actual write access is done by the generic property-option bridge.
| * m_config: fix build with emulated stdatomicwm42018-05-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | C11 can access atomic variables normally (in which case they use the strictest memory access semantics). But the mpv stdatomic wrapper for C99 compilers does not allow it, because it couldn't give any guarantees. This means we always need to access them with atomic macros. While we're at, use relaxed semantics for the m_config_cache field, since because it's accessed from a single thread only (essentially used in a non-atomic way). Switch the comparison arguments to make the formatting look slightly less weird.
| * m_config: make m_config_cache_update() return more fine grainedwm42018-05-241-3/+7
| | | | | | | | | | | | | | | | | | Although the new code actually fires update notifications only when needed, m_config_cache_update() itself returned a rather coarse change value, which could indicate change even if none of the cached options were changed. On top of that, some code (like vo_gpu) calls the update function on every frame, which would reconfigure the renderer even on unrelated option changes.
| * player: get rid of mpv_global.optswm42018-05-2416-63/+75
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * vd_lavc: move hwdec opts to local config, don't use global MPOptswm42018-05-244-43/+50
| | | | | | | | | | | | | | The --hwdec* options are a good fit for the vd_lavc local option struct. This annoyingly requires manual prefixing of most of these options with --vd-lavc (could be avoided by using more sub-struct craziness, but let's not).
| * path: don't access global option structwm42018-05-244-7/+20
| | | | | | | | | | | | | | The path functions need to access the option that forces non-default config directories. Just add it as a field to mpv_global - it seems justified. The accessed options were always enforced as immutable after init, so there's not much of a change.
| * m_config: add a special define to access main configwm42018-05-242-5/+7
| | | | | | | | | | | | | | | | Passing NULL to mp_get_config_group() returns the main option struct. This is just a dumb hack to deal with inconsistencies caused by legacy things (as I'll claim), and will probably be changed in the future. So before littering the whole code base with hard to find NULL parameters, require using callers an easy to find separate define.
| * ao: use a local option structwm42018-05-246-19/+44
| | | | | | | | Instead of accessing MPOpts.
| * player: remove deprecated vo/ao auto profileswm42018-05-242-9/+2
| | | | | | | | | | These were deprecated almost 2 years ago. Now they happen to be in the way.
| * m_config: optimize initialization of each optionwm42018-05-241-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Options with dynamic memory allocations (such as strings) require some care. They need to be fully copied on initialization, and if a static default value was declared, we must not free that value either. Instead of going through the entire thing even for simple types like integers, really run it only for options with dynamic allocations. To distinguish types which use dynamic allocations, we can use the fact that they require a free callback (otherwise they would leak). As a result initialization of simple types becomes chaper, and the init function does nothing at all if src==dst for a simple type. (It's funny how mplayer had M_OPT_TYPE_DYNAMIC since 2002, until we replaced it by the same heuristic as used here in commit 3bb134969eb6. It's also funny how the new check was used only for some asserts, and finally removed in commit 7539928c1c. I guess at this time I felt like having uniform code was more important than pointless micro-optimizations.) The src==NULL case is removed because it can't happen.
| * m_config: remove extra default_data fieldwm42018-05-243-20/+29
| | | | | | | | Just wastes memory (a few KB, because there are so many options).
| * m_config: remove unused fieldswm42018-05-242-8/+2
| |
| * build: prefer C11 modewm42018-05-241-1/+6
| | | | | | | | | | | | C99 still works, but in theory we're using C11 features already, such as stdatomic.h. gcc/clang let us use it in C99 mode too, but using C11 is at least more proper.
| * m_config: reduce redundant option change notificationswm42018-05-241-1/+1
| |
| * m_config: remove an old temporary hackwm42018-05-242-308/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually rewrite most of the option management code. This affects how options are allocated, and how thread-safe access to them is done. One thing that is nicer is that creating m_config_cache does not need to ridiculously recreate and store the entire option list again. Instead, option metadata and option storage are now separated. m_config contains the metadata, and m_config_data all or parts of the actual option values. (m_config_cache simply uses the metadata part of m_config, which is immutable after creation.) The mentioned hack was introduced in commit 1a2319f3e4cc4, and is the global state around g_group_mutex. Although it was "benign" global state, it's good that it's finally removed.
| * osdep: add portable C11-like alignof() macrowm42018-05-241-0/+5
| |
| * m_config: remove outdated commentwm42018-05-241-1/+0
| |
| * m_config: check for int16_t offset overflowwm42018-05-241-1/+3
| | | | | | | | | | | | | | | | For some reason shadow_offset is a int16_t variable (to save some space or something), which means the static part of the entire option list must be below 32KB. This is fine, but still add a check against overflows. (Currently it's 3.6KB. This does not include dynamic allocations like strings.)
| * m_config: remove an unused functionwm42018-05-242-15/+0
| |
| * m_option: remove an unused fieldwm42018-05-242-13/+0
| |
| * m_config: cosmetics: fix 2 typoswm42018-05-241-2/+2
| |
| * input: remove now unused "abort command" and cancel infrastructurewm42018-05-245-75/+7
| | | | | | | | The previous commit removed all uses.
| * player: make playback termination asynchronouswm42018-05-248-32/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
| * player: change the role of the "stop_play" and "playing" variablewm42018-05-245-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this, mpctx->playing was often used to determine whether certain new state could be added to the playback state. In particular this affected external files (which added tracks and demuxers). The variable was checked to prevent that they were added before the corresponding uninit code. We want to make a small part of uninit asynchronous, but mpctx->playing needs to stay in the place where it is. It can't be used for this purpose anymore. Use mpctx->stop_play instead. Make it never have the value 0 outside of loading/playback. On unloading, it obviously has to be non-0. Change some other code in playloop.c to use this, because it seems slightly more correct. But mostly this is preparation for the following commit.
| * demux: add a way to destroy the demuxer asynchronouslywm42018-05-242-8/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This will enable the player core to terminate the demuxers in a "nicer" way without having to block on network. If it just used demux_free(), it would either have to block on network, or like currently, essentially kill all I/O forcefully. The API is slightly awkward, because demuxer lifetime is bound to its allocation. On the other hand, changing that would also be awkward, and introduce weird in-between states that would have to be handled in tons of places. Currently unused, to be user later.
| * player: move a function (no functional changes)wm42018-05-241-7/+7
| |
| * manpage: update --demuxer-thread optionwm42018-05-241-3/+6
| | | | | | | | Be a bit more detailed, and discourage disabling it.
| * player: some further cleanup of the mp_cancel crapwm42018-05-246-79/+62
| | | | | | | | | | | | | | | | | | | | Alway give each demuxer its own mp_cancel instance. This makes management of the mp_cancel things much easier. Also, instead of having add/remove functions for mp_cancel slaves, replace them with a simpler to use set_parent function. Remove cancel_and_free_demuxer(), which had mpctx as parameter only to check an assumption. With this commit, demuxers have their own mp_cancel, so add demux_cancel_and_free() which makes use of it.
| * demux: get rid of free_demuxer[_and_stream]()wm42018-05-248-27/+31
| | | | | | | | | | | | | | Them being separate is just dumb. Replace them with a single demux_free() function, and free its stream by default. Not freeing the stream is only needed in 1 special case (demux_disc.c), use a special flag to not free the stream in this case.
| * player: simplify edition switchingwm42018-05-244-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The player fully restarts playback when the edition or disk title is changed. Before this, the player tried to reinitialized playback partially. For example, it did not print a new "Playing: <file>" message, and did not send playback end to libmpv users (scripts or applications). This playback restart code was a bit messy and could have unforeseen interactions with various state. There have been bugs before. Since it's a mostly cosmetic thing for an obscure feature, just change it to a full restart. This works well, though since it may have consequences for scripts or client API users, mention it in interface-changes.rst.
| * command: whitelist some blocking accesses for certain demuxers/streamswm42018-05-247-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The properties/commands touched in this commit are all for obscure special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream layer. For network streams, this blocking is very unwelcome. They will affect playback and probably introduce pauses and frame drops. The player can even freeze fully, and the logic that tries to make playback abortable even if frozen complicates the player. Since the mentioned accesses are not needed for network streams, but they will block on network streams even though they're going to fail, add a flag that coarsely enables/disables these accesses. Essentially it establishes a whitelist of demuxers/streams which support them. In theory you could to access BD/DVD images over network (or add such support, I don't think it's a thing in mpv). In these cases these controls still can block and could even "freeze" the player completely. Writing to the "program" and "cache-size" properties still can block even for network streams. Just don't use them if you don't want freezes.
| * timer: remove an unused helper functionwm42018-05-242-16/+0
| | | | | | | | It's also dumb.
| * thread_pool: add a helper functionwm42018-05-242-10/+30
| | | | | | | | | | The behavior of mp_thread_pool_queue() doesn't or shouldn't change, but the new helper function requires touching its logic.
| * thread_pool: move comments to .h filewm42018-05-242-17/+17
| |
| * command: make loadlist command async and abortablewm42018-05-245-7/+15
| | | | | | | | | | | | | | | | | | | | Don't allow it to freeze everything when loading a playlist from network (although you definitely shouldn't do that, but whatever). This also affects the really obscure --ordered-chapters-files option. The --playlist option on the other hand has no choice but to freeze the shit, because there's no concept of aborting the player during command line parsing.
| * player: make various commands for managing external tracks abortablewm42018-05-245-54/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, they could be aborted only by ending playback, and calling mpv_abort_async_command didn't do anything. This requires furthering the mess how playback abort is done. The main reason why mp_cancel exists at all is to avoid that a "frozen" demuxer (blocked on network I/O or whatever) cannot freeze the core. The core should always get its way. Previously, there was a single mp_cancel handle, that could be signaled, and all demuxers would unfreeze. With external files, we might want to abort loading of a certain external file, which automatically means they need a separate mp_cancel. So give every demuxer its own mp_cancel, and "slave" it to whatever parent mp_cancel handles aborting. Since the mpv demuxer API conflates creating the demuxer and reading the file headers, mp_cancel strictly need to be created before the demuxer is created (or we couldn't abort loading). Although we give every demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer), it's still rather messy to create/destroy it along with the demuxer.
| * demux: add a "cancel" fieldwm42018-05-245-5/+8
| | | | | | | | | | Instead of relying on demuxer->stream->cancel. This is better because the stream is potentially closed and replaced.
| * stream_file: use a separate mp_cancel thingwm42018-05-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The intention is to avoid that the parent mp_cancel retains the internally allocated wakeup pipe. File FDs are a relatively scarce resource, so try to avoid having too many. This might matter for subtitle files, for which it is relatively likely that they are loaded in large quantities. demux_lavf.c will close the underlying stream for most subtitle files, and now it will free the wakeup pipe too. Actually, there are currently only 1 or 2 mp_cancel objects per mpv core, but this could change if every external subtitle track gets its own mp_cancel in later commits.
| * thread_tools: unify mp_cancel POSIX/win32 paths, add featureswm42018-05-242-52/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OS specifics are merged because the resulting ifdeffery is not much worse than the old ifdeffery, but the logic that is now shared is becoming more complex. Create all objects lazily. The intention is to make mp_cancel instances cheaper. POSIX pipes and win32 Events are pretty heavy weight, and are only needed in special situations. Add a mechanism to "chain" mp_cancel instances. Needed by the later commits for whatever reasons. Untested on win32.
| * misc: add linked list helperswm42018-05-242-0/+269
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides macros for managing intrusive doubly linked lists. There are many ways how to do those in a "generic" way in C. For example Solaris style lists are pretty nice: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/list.h https://github.com/illumos/illumos-gate/blob/master/usr/src/common/list/list.c I even have an independent implementation of this, which could be ISC licensed. But I think it's easier to vomit ~100 lines of preprocessor garbage, which has a lower footprint, and I think it wins slightly on the side of type safety, simplicity, and ease of use, even if it doesn't look as magically nice.
| * thread_tools: minor simplificationwm42018-05-241-3/+1
| |
| * misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-2415-145/+171
| | | | | | | | | | | | | | | | | | | | | | | | It seems a bit inappropriate to have dumped this into stream.c, even if it's roughly speaking its main user. At least it made its way somewhat unfortunately to other components not related to the stream or demuxer layer at all. I'm too greedy to give this weird helper its own file, so dump it into thread_tools.c. Probably a somewhat pointless change.
| * cmd: do not use a random value for MP_CMD_OPT_ARGwm42018-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | This flag is used only by the command parser. Its value overlapped with some of the existing m_option flags, but only flags that did not matter for the command parser (i.e. the flag bits used had mostly private uses in each component). It's still a bit unclean and dangerous to use an essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it. Since M_OPT_OPTIONAL_PARAM has a slightly longer name than MP_CMD_OPT_ARG, I'm going to keep the old name.
| * input: slightly improve --input-cmdlist outputwm42018-05-242-6/+7
| | | | | | | | | | Output argument names, whether varargs are used, and indicate optional arguments correctly (instead of only half of them).
| * command: give named arguments to almost all commandswm42018-05-245-249/+409
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, only 1 command or so had named arguments. There is no reason why other commands can't have them, except that it's a bit of work to add them. Commands with variable number of arguments are inherently incompatible to named arguments, such as the "run" command. They still have dummy names, but obviously you can't assign multiple values to a single named argument (unless the argument has an array type, which would be something different). For now, disallow using named argument APIs with these commands. This might change later. 2 commands are adjusted to not need a separate default value by changing flag constants. (The numeric values are C only and can't be set by users.) Make the command syntax in the manpage more consistent. Now none of the allowed choice/flag names are in the command header, and all arguments are shown with their proper name and quoted with <...>. Some places in the manpage and the client.h doxygen are updated to reflect that most commands support named arguments. In addition, try to improve the documentation of the syntax and need for escaping etc. as well. (Or actually most uses of the word "argument" should be "parameter".)
| * json: add some non-standard extensionswm42018-05-243-7/+77
| | | | | | | | | | Also clarify this and previously existing differences to standard JSON in ipc.rst.
| * json: format slightly nicer escape sequenceswm42018-05-242-6/+20
| | | | | | | | | | | | Make use the escape sequences allowed by JSON. Also update the linked RFC to the newest one.
| * test: add tests for json parser/formatterwm42018-05-241-0/+86
| | | | | | | | This should have been done sooner.
| * misc: move some helper code from client.cwm42018-05-243-49/+56
| | | | | | | | | | (Slightly oddly function names, because I want to avoid starting them with mpv_*, which is reserved for public API.)
| * player: use canonical playback time for video refresheswm42018-05-241-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When changing video filters during initialization, there was a small time window where video was initialized, but playback restart was not complete yet. In this time window, playback_pts is not set. But since issue_refresh_seek() was using this, it could lead to no refresh being done _if_ the "video" had only 1 frame (such as cover art). Fix this by using get_current_time() instead, which is the current time with corner cases such as ongoing loading or seeks taken into account. See also the previous commit. Without that, get_current_time() could return NOPTS during init. Fixes #5831.
| * player: don't reset last_seek_pts on playback state resetwm42018-05-242-4/+2
| | | | | | | | | | | | | | | | | | | | | | This is nonsense. Didn't matter in most situations, because seeking itself set this after it was cleared. But some callers don't do this, see e.g. commit ed73ba89644fc6. There is no need to clear it at all, and it causes issues with the next commit. It only needs to be reset on loading. Also move the initialization on loading up, which doesn't change behavior, but makes the intention clearer.
| * manpage: mention that fd:// file descriptors may be modifiedwm42018-05-241-0/+2
| | | | | | | | | | For example, we call setmode() to switch a FD from text to binary mode on garbage OSes.
| * stream_file: properly detect stdin as pipewm42018-05-241-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | There is some code that checks a FD for whether it is a regular file or not. If it's not a regular file, it e.g. enables use of poll() to avoid blocking forever. But this was done only for FDs that were open()ed by us, not from stdin special handling or fd://. Consequently, " | mpv -" could block the player. Fix this by moving the code and running for it on all FDs. Also, set p->regular_file even on mingw.
| * vd_lavc: minor simplification for get_format fallbackwm42018-05-241-7/+1
| | | | | | | | | | | | | | | | | | | | | | The default get_format does exactly do this, so we don't need to duplicate it. The only potential problem with this is that the logic doesn't entirely prevent that the avcodec_default_get_format hw_device_ctx path is triggered, which would probably work, but has unknown consequences and interactions. But the way the logic currently works it can't happen, provided the hwaccel metadata libavcodec provides is correct.
| * manpage: remove a reference to a removed optionwm42018-05-241-2/+1
| |
| * demux: late streams on start shouldn't restrict the seek rangewm42018-05-241-1/+9
| | | | | | | | | | | | If a stream starts later than the others at the start of the file, it shouldn't restrict the seek range to the time stamp where it begins. This is similar to the previous commit, just for the other end.
| * demux: streams that reached EOF shouldn't restrict the seek rangewm42018-05-241-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, the seek range is the minimum overlap of the cached ranges of each stream. But if one of the streams ends earlier, this leads to the seek range getting cut off, even if you could seek there. Change it so that EOF streams cannot restrict the end of the seek range. They can only extend it. This is the opposite from not-EOF streams, so they need to be handled separately. In particular, they get exluded from normal end range calculation, but when full EOF is reached, all streams are EOF, and the maximum end time can be used to set the seek end time. (In theory we could also take the max with the demuxer signaled total file duration, but let's not for now.) Also, if a stream is completely empty, essentially skip it, instead of considering the range unseekable. (Also, we don't need to mess with seek_start in this case, because it will be NOPTS and is skipped anyway.)
| * demux: fix/improve aspects of EOF signalingwm42018-05-241-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current packet queue was completely empty, and EOF was reached, the queue->is_eof flag was not correctly set to true. Change this by reading ds->eof to check whether the stream is considered EOF. We also need to make sure update_seek_ranges() is called in this case, so change the code to simply call it when queue->is_eof changes. Also, read_packet() needs to call adjust_seek_range_on_packet() if ds->eof changes. In that case, the decoder also needs to be notified about EOF. So both of these should be called when ds->eof changes to true. (Other code outside of this function deals with the case when ds->eof is changed to false.) In addition, this code was kind of shoddy about calling wakeup_ds() correctly. It looks like there was an inverted condition, and sent a wakeup to the decoder only when ds->eof was already true, which is obviously bogus. The final EOF case tried to be somehow clever about checking in->last_eof for notifying the codec, which is sort of OK, but seems to be strictly worse than just checking whether ds->eof changed. Fix these things.
| * client API: kill async commands on terminationwm42018-05-245-14/+65
| | | | | | | | | | | | | | | | | | | | | | This affects async commands started by client API, commands with async capability run in a sync way by client API (think mpv_command_node() with "subprocess"), and detached async work. Since scripts might want to do some cleanup work (that might involve launching processes, don't ask), we don't unconditionally kill everything on exit, but apply an arbitrary timeout of 2 seconds until async commands are aborted.
| * demux_lavf: remove ffm blacklist entrywm42018-05-241-2/+0
| | | | | | | | ffm (ffserver) was removed from ffmpeg.
| * ipc: some user-visible changes to prepare for making all commands asyncwm42018-05-243-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I wanted to put all commands through mpv_command_node_async() instead of mpv_command_node(). Using synchronous commands over a synchronous transport doesn't make sense anyway. This would have used the request_id field in IPC requests as reply ID for the async commands. But the latter need to be [u]int64, while the former can be any type. To avoid that we need an extra lookup table for mapping reply IDs to request_id values, we now require that request_id fields are integers. Since this would be an incompatible change, just deprecate non-integers for now, and plan the change for a later time.
| * ipc: cosmetic: switch a negated if/elsewm42018-05-241-3/+3
| |
| * ipc: alias set_property_string to set_propertywm42018-05-242-28/+4
| | | | | | | | | | | | | | | | | | The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
| * lua: expose mpv_abort_async_command()wm42018-05-244-3/+47
| | | | | | | | Also somewhat cleans up mp.command_native_async() error handling.
| * command: make "subprocess" explicitly abortablewm42018-05-242-5/+9
| | | | | | | | Now mpv_abort_async_command() can be used to stop the process.
| * command: add a way to abort asynchronous commandswm42018-05-2412-9/+169
| | | | | | | | | | | | | | | | | | | | | | | | Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
| * player: rename "lock" to "abort_lock"wm42018-05-243-12/+12
| | | | | | | | | | | | If a struct as large as MPContext contains a field named "lock", it creates the impression that it is the primary lock for MPContext. This is wrong, the lock just protects a single field.
| * lua: reimplement mp.subprocess_detached() by invoking the "run" commandwm42018-05-243-30/+7
| | | | | | | | | | | | | | | | The "run" command is old. I'm not sure why the separate Lua implementation was added. But maybe it as because the "run" command used to be limited to a small number of arguments. This limit has been removed a while ago. In any case, the old implementation is not needed anymore.
| * lua: reimplement mp.subprocess() by invoking the new subprocess commandwm42018-05-244-118/+41
| | | | | | | | | | | | | | We keep mp.subprocess() with roughly the same semantics for compatibility with scripts (including the internal ytdl script). Seems to work with rhe ytdl wrapper. Not tested further.
| * command: add a subprocess commandwm42018-05-245-0/+108
| | | | | | | | | | | | | | This supports named arguments. It benefits from the infrastructure of async commands. The plan is to reimplement Lua's utils.subprocess() on top of it.
| * input: add glue code for named argumentswm42018-05-244-47/+248
| | | | | | | | | | | | | | | | | | | | Named arguments should make it easier to have long time compatibility, even if command arguments get added or removed. They're also much nicer for commands with a large number of arguments, especially if many arguments are optional. As of this commit, this can not be used, because there is no command yet which supports them. See the following commit.
| * node: move a mpv_node helper from ipc.c to shared codewm42018-05-243-14/+17
| | | | | | | | This particular one is needed in a following commit.
| * thread_pool: set thread namewm42018-05-241-0/+3
| |
| * video: trust container FPS early on if possiblewm42018-05-241-1/+2
| | | | | | | | | | If the container FPS is correct, this can help getting ideal mix factors for vo_gpu interpolation mode. Otherwise, it doesn't matter.
| * input: add a define for the number of mouse buttons and use itwm42018-05-243-1/+7
| | | | | | | | (Why the fuck are there up to 20 mouse buttons?)
| * TOOLS: add a stupid test program for Lua async commandswm42018-05-241-0/+53
| |
| * lua: expose async commandswm42018-05-243-0/+49
| | | | | | | | Might be useful for some.
| * screenshot: report success to callerwm42018-05-241-3/+7
| | | | | | | | Matters only to API callers, but still nice to have.
| * client API: merge status_reply() helper with only remaining callerwm42018-05-241-12/+5
| | | | | | | | | | All other callers had to be changed, so there's no point in keeping this helper function around. It's just another unnecessary indirection.
| * client API: add returning of data from async commandswm42018-05-243-12/+33
| | | | | | | | This was not done sooner out of laziness.
| * client API: clarify asynchronous call ordering non-guaranteeswm42018-05-241-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Both asynchronous and synchronous calls used to be put into the core's dispatch queue. Also, asynchronous calls were actually synchronous, just without forcing a wait on the client's thread. This meant that both kinds of calls were always strictly ordered. A longer time ago, synchronous calls were changed to simply lock the core. This could possibly lead to reordering. Recently, some commands were changed to run on worker threads, which made the order even looser. Also remove another now incorrect doxygen comment regarding async commands.
| * input: remove unused fieldwm42018-05-241-1/+0
| | | | | | | | This was forgotten in commit fb9bbf2a0d7f8.
| * screenshot: change async behavior to be in line with new semanticswm42018-05-245-130/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically reimplement the async behavior on top of the async command code. With this, all screenshot commands are async, and the "async" prefix basically does nothing. The prefix now behaves exactly like with other commands that use spawn_thread. This also means using the prefix in the preset input.conf is pointless (without effect) and misleading, so remove that. The each_frame mode was actually particularly painful in making this change, since the player wants to block for it when writing a screenshot, and generally doesn't fit into the new infrastructure. It was still relatively easy to reimplement by copying the original command and then repeating it on each frame. The waiting is reentrant now, so move the call in video.c to a "safer" spot. One way to observe how the new semantics interact with everything is using the mpv repl script and sending a screenshot command through it. Without async flag, the script will freeze while writing the screenshot (while playback continues), while with async flag it continues.
| * command: move screenshot command stubs to screenshot.cwm42018-05-243-67/+66
| | | | | | | | | | | | | | | | | | | | Commands are not a monolithic giant switch() statement anymore, but individual functions. There's no reason to have the command handlers themselves in command.c, with a weird under-defined API in between. (In the future, I'd like to split up command.c further, and when I do that, scrrenshot.c will probably gets its own mp_cmd_def[] array, and define the commands locally instead of exporting the raw handlers.)
| * manpage: mention that --no-correct-pts can break seeking toowm42018-05-241-2/+2
| |
| * player: make all external file loading actions asyncwm42018-05-244-23/+93
| | | | | | | | | | Still missing: not freezing when removing a track (i.e. closing demuxer) with the sub-remove/audio-remove/rescan-external-files commands.
| * player: make abort during loading faster if ytdl_hook is usedwm42018-05-241-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically, the ytdl_hook script will not terminate the script, even if you change to a new playlist entry. This happens because ytdl_hook keeps the player core in an early loading stage, and the forceful playback abort is done only in the ermination code. This does not handle the "stop" and "quit" commands, which can still take longer than expected, but on the other hand have some weird special handling (see below). I'm not doing this out of laziness. Playback stopping will have to be somewhat redone anyway. Basically we want to give everything a chance to terminate, and if it doesn't work, we want to stop loading or playback forcefully after a small timeout. We also want to remove the mess with input.c's special handling of "quit" and some other commands (see abort_playback_cb stuff).
| * player: don't even start loading external tracks when aborting loadingwm42018-05-241-1/+1
| | | | | | | | | | | | It seems the ytdl script like to continue loading external tracks even if loading was aborted. Trying to do so will still quickly fail, but not without a load of log noise. So check and error out early.
| * command: make sub-add and audio-add commands asyncwm42018-05-244-7/+24
| | | | | | | | | | | | | | | | | | | | Pretty trivial, since commands can be async now, and the common code even provides convenience like running commands on a worker thread. The only ugly thing is that mp_add_external_file() needs an extra flag for locking. This is because there's still some code which calls this synchronously from the main thread, and unlocking the core makes no sense there.
| * command: add infrastructure for async commandswm42018-05-2410-47/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
| * thread_pool: make it slightly less dumbwm42018-05-243-43/+142
| | | | | | | | | | | | | | | | | | | | | | | | The existing thread pool code is the most primitive thread pool possible. That's fine, but one annoying thing was that it used a static number of threads. Make it dynamic, so we don't need to "waste" idle threads. This tries to add threads as needed. If threads are idle for some time, destroy them again until a minimum number of threads is reached. Also change the license to ISC.
| * client: merge can_terminate() functionwm42018-05-241-15/+12
| | | | | | | | | | | | | | | | | | | | | | This has some tricky interactions. In particular, it requires the core to be locked due to reading outstanding_async, which is documented on the only caller only. It's probably better to merge it with its only caller. The new code should be strictly equivalent, other than the fact that it doesn't temporarily unlock+lock when entering the loop for the first time (which doesn't matter here).
| * misc: add a synchronization helperwm42018-05-243-0/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is almost like rendezvous(), except it allows async wakeup, and does not require global state. It will be used by a later commit. struct mp_waiter is intended to be allocated on the stack, and uses an initializer including PTHREAD_MUTEX_INITIALIZER. This is the first case in mpv that it uses PTHREAD_MUTEX_INITIALIZER for stack-allocated mutexes. It seems POSIX still does not allow this formally, but since POSIX is worth less than used toilet paper, I don't really care. Modern OSes use futexes, which means you can make _every_ memory location a lock, and this code tries to make use of it, without using OS specific code. The name of the source file is rather generic, because I intend to dump further small helpers there (or maybe move mp_rendezvous() to it).
| * input: move an enum back to its correct placewm42018-05-242-13/+13
| | | | | | | | This was accidentally moved together with the cmd stuff.
| * command: handle list commands like normal commandswm42018-05-242-11/+11
| | | | | | | | Pretty annoying.
| * dispatch: add an assert()wm42018-05-241-0/+1
| |
| * client API: some doxygen fixes/additionswm42018-05-243-6/+28
| |
* | spirv: remove --spirv-compiler=nvidiaNiklas Haas2018-12-016-70/+12
| | | | | | | | | | | | | | | | | | | | | | | | This option has been deprecated upstream for a long time, probably doesn't even work anymore, and won't work moving forwards as we replace the vulkan code by libplacebo wrappers. I haven't removed the option completely yet since in theory we could still add support for e.g. a native glslang wrapper in the future. But most likely the future of this code is deletion. As an aside, fix an issue where the man page didn't mention d3d11.
* | drm: rename plane options to better, invariant, namesAnton Kindestam2018-12-0114-147/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
* | drm_atomic: Add general primary/overlay plane optionAnton Kindestam2018-12-015-31/+52
| | | | | | | | | | | | | | | | | | | | Add general primary/overlay plane option to drm-osd-plane-id and drm-video-plane-id, so that the user can just request any usable primary or overlay plane for either of these two options. This should be somewhat more user-friendly (especially as neither of these two options currently have a useful help function), as usually you would only be interested in the type of the plane, and not exactly which plane gets picked.
* | man: fix --watch-later-directory formattingTheAMM2018-11-281-1/+0
| | | | | | | | | | Extra line prevents the sub-title formatting. Removing it, the option is formatted like the others.
* | gpu: prefer wayland context on autodetectdudemanguy2018-11-191-3/+3
| |
* | vulkan: slightly improve vsync jitter measurementsNiklas Haas2018-11-191-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By design, some vulkan implementations block until vsync during vkAcquireNextImageKHR. Since mpv only considers the time that `swap_buffers` spent blocking as constituting part of the vsync, we can help it out a bit by pre-emptively calling this function here in order to improve the accuracy of vsync jitter measurements on vulkan. (If it fails, we just ignore the error and have the user call it a second time later - maybe it will work then) On my system this drops vsync-jitter from ~0.030 to ~0.007, an accuracy of +/- 100μs. (Which *might* have something to do with the fact that this is the polling interval for command polling)
* | vo_gpu: vulkan: only rotate the queues on swapNiklas Haas2018-11-192-12/+9
| | | | | | | | | | | | | | | | Makes performance slightly better when using multiple queues by avoiding unnecessary semaphores due to bad queue selection. Also remove an aeons-old workaround for an nvidia bug that only ever existed in the earliest beta vulkan drivers anyway.
* | wayland: remove KDE server-decoration supportemersion2018-11-194-146/+12
| |
* | wayland: use xdg-decoration if availableemersion2018-11-194-14/+53
| |
* | filters: Add cuda/nvdec deinterlacing auto-filter using vf_yadif_cudaPhilip Langdale2018-11-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | Historically, there's been no way to offer deinterlacing with nvdec, and for cuviddec, it required a command line flag, with no way to toggle while playing. Now that we have a cuda deinterlacing filter in ffmpeg, we can hook it up hook it up as the cuda auto-deinterlacer. In practice, this isn't going to be present very often, due to the licensing mess with the cuda sdk, but we can support it when it is there.
* | vo_gpu: hwdec_cuda: Guard GL and Vulkan headers properlyPhilip Langdale2018-11-181-0/+5
| | | | | | | | | | | | | | | | We are currently unnecessarily including vulkan headers even when not building with vulkan support. I also guarded the GL header inclusion even though this doesn't appear to break anything today. Fixes #6330.
* | w32_common: use the screen working area when resizing the windowpavelxdd2018-11-181-74/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the default fit on screen, autofit and window-scale changing behavior to use the screen working area, instead of the whole screen area. As a result mpv window doesn't cover the taskbar now when opening videos with size larger than the screen size. The actual behavior now is the same as expected behavior for usecases 1-4 from #4363. This commit also removes the screenrc from w32 struct. The screen rect can now be retrieved via `get_screen_area` function, which was renamed from `update_screen_rect`. On a multi-monitor system, if the user moved the window between monitors, this function will return the current screen area under the window, and not the screen area from monitor specified by `--screen` option. The `--screen` option sets the initial monitor the mpv window is displayed on.
* | vo_x11: fix return value in resize() error pathsRikard Falkeborn2018-11-171-2/+2
| | | | | | | | | | | | Returning -1 in a function with return type bool is the same as returning true. In the error paths, false should be returned to indicate that something went wrong.
* | vo_gpu: opengl: disable compute shaders for old GLSLNiklas Haas2018-11-171-0/+6
| | | | | | | | Fixes #6272.
* | cocoa: fix drawing on macOS 10.14Akemi2018-11-131-0/+6
| |
* | cocoa-cb: add logging for CGL pixel format attributesAkemi2018-11-131-0/+19
| | | | | | | | | | | | | | | | depending on the capabilities of the system and testing of various attributes the resulting CGL pixel format can change. due to that probing it can be helpful to know which pixel format is used to create the CGL context. added some verbose logging that outputs final pixel format.
* | vo_libmpv: support render performance dataAkemi2018-11-133-0/+25
| |
* | cocoa-cb: use libmpv's advanced rendering control and timingAkemi2018-11-134-33/+41
| | | | | | | | | | | | | | | | this adds support for GPU rendered screenshots, DR (theoretically) and possible other advanced functions in the future that need to be executed from the rendering thread. additionally frames that would be off screen or not be displayed when on screen are being dropped now.
* | build: add a version requirement for vulkan pkg-config checkJan Ekström2018-11-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | `vkGetPhysicalDeviceProperties2KHR` was added in Vulkan 1.0.39, but 1.0.61 from Ubuntu Xenial (16.04) was the lowest anyone tried to build mpv with as of late, so we are marking that as the minimum required version. This fixes issues arising during build time from having too old version of vulkan available on a system, instead of causing a failure to build.
* | vo_gpu: vulkan: Always use KHR suffix types and definesPhilip Langdale2018-11-033-9/+9
| | | | | | | | | | | | | | | | | | I was inconsistent about this originally, as the functionality was moved into the core spec in 1.1 and so both suffixed and unsuffixed versions of everything exist and can be mixed together. There's no reason to fail to build with 1.0.39+ so I'm fixing the names.
* | ipc-unix: don't blow up on readonly fd://Niklas Haas2018-10-311-1/+1
| | | | | | | | | | | | On my system, when trying to use mpv with a read-only fd created by python 3.7, `send` triggers ENOTSOCK, not EBADF. Extend the logic to detect non-writable fds by this `errno`.
* | audio: increase a buffer sizeBen Boeckel2018-10-311-1/+1
| | | | | | | | | | | | The buffer is written to in `audio_config_to_str_buf` using `snprintf` with a `%s` formatting of a 128-byte buffer. This can overflow the target buffer of 80 causing a truncated output.
* | ipc-unix: leave room for a NUL terminatorBen Boeckel2018-10-311-1/+1
| | | | | | | | | | | | | | The `strncpy` function will not always place a terminating `NUL` if the source is longer than the destination buffer. Instead, let `strncpy` truncate as it normally would, but leave the last byte alone (it is zero-initialized when declared).
* | vo_gpu: hwdec_cuda: Clean up init() error handlingPhilip Langdale2018-10-311-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | Currently, the error paths in init() are a bit confusing, and we can end up trying to pop the current context when there is no context, which leads to distracting error messages. I also added an explicit path to return early if the GPU backend is not OpenGL or Vulkan. It's pointless to do any other cuda init after that point. (Of course, someone could write more interops.) Fixes #6256
* | ad_spdif: cosmetic alignmentJan Ekström2018-10-301-1/+1
| |
* | ad_spdif: fix DTS-HD HRA handlingJan Ekström2018-10-301-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | Apparently, for bit streaming DTS-HD MA is specified to be handled as an eight channel (7.1) bit stream, while DTS-HD HRA is specified to be handled as a stereo bit stream. Define a variable for this, and utilize it to set the correct values for both the DTS-HD bit streaming rate, as well as the channel count for the SPDIF encoder. Fixes #6148
* | build: pass include paths as a list instead of a string in cocoa checkAkemi2018-10-281-1/+1
| | | | | | | | | | | | when passed as a string check_cc tries to split that string, since it assumes that several include paths can be passed to it. instead we just use a list to make it unambiguous.
* | build: don't hardcode swift module nameAkemi2018-10-281-1/+2
| |
* | build: use an argument list for the Swift build argsAkemi2018-10-283-15/+26
| | | | | | | | | | | | that way we don't need to quote or escape anything. Fixes #6220
* | hwdec_drmprime_drm: Missing NULL-check on drm_atomic_context video_planeAnton Kindestam2018-10-251-0/+3
| | | | | | | | | | | | | | | | | | Since 810acf32d6cf0dfbad66c602689ef1218fc0a6e3 video_plane can be NULL under some circumstances. While there is a check in init, init treats this as an error condition and would call uninit, which in turn calls disable_video_plane, which would then segfault. Fix this by including a NULL check inside disable_video_plane, so that it doesn't try to disable what isnt' there.
* | stream_smb: make sure the string is NULL-terminated after strncpypavelxdd2018-10-251-0/+1
| | | | | | | | strncpy does not guarantee that the string will be NULL-terminated.
* | vo_gpu: vulkan: hwdec_cuda: Add support for Vulkan interopPhilip Langdale2018-10-223-65/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Despite their place in the tree, hwdecs can be loaded and used just fine by the vulkan GPU backend. In this change we add Vulkan interop support to the cuda/nvdec hwdec. The overall process is mostly straight forward, so the main observation here is that I had to implement it using an intermediate Vulkan buffer because the direct VkImage usage is blocked by a bug in the nvidia driver. When that gets fixed, I will revist this. Nevertheless, the intermediate buffer copy is very cheap as it's all device memory from start to finish. Overall CPU utilisiation is pretty much the same as with the OpenGL GPU backend. Note that we cannot use a single intermediate buffer - rather there is a pool of them. This is done because the cuda memcpys are not explicitly synchronised with the texture uploads. In the basic case, this doesn't matter because the hwdec is not asked to map and copy the next frame until after the previous one is rendered. In the interpolation case, we need extra future frames available immediately, so we'll be asked to map/copy those frames and vulkan will be asked to render them. So far, harmless right? No. All the vulkan rendering, including the upload steps, are batched together and end up running very asynchronously from the CUDA copies. The end result is that all the copies happen one after another, and only then do the uploads happen, which means all textures are uploaded the same, final, frame data. Whoops. Unsurprisingly this results in the jerky motion because every 3/4 frames are identical. The buffer pool ensures that we do not overwrite a buffer that is still waiting to be uploaded. The ra_buf_pool implementation automatically checks if existing buffers are available for use and only creates a new one if it really has to. It's hard to say for sure what the maximum number of buffers might be but we believe it won't be so large as to make this strategy unusable. The highest I've seen is 12 when using interpolation with tscale=bicubic. A future optimisation here is to synchronise the CUDA copies with respect to the vulkan uploads. This can be done with shared semaphores that would ensure the copy of the second frames only happens after the upload of the first frame, and so on. This isn't trivial to implement as I'd have to first adjust the hwdec code to use asynchronous cuda; without that, there's no way to use the semaphore for synchronisation. This should result in fewer intermediate buffers being required.
* | vo_gpu: vulkan: Add a function to get the device UUIDPhilip Langdale2018-10-222-0/+25
| | | | | | | | We need this to do device matching for the cuda interop.
* | vo_gpu: vulkan: Add arbitrary user data for an ra_vk_bufPhilip Langdale2018-10-222-0/+18
| | | | | | | | | | | | | | | | | | This is arguably a little contrived, but in the case of CUDA interop, we have to track additional state on the cuda side for each exported buffer. If we want to be able to manage buffers with an ra_buf_pool, we need some way to keep that CUDA state associated with each created buffer. The easiest way to do that is to attach it directly to the buffers.
* | vo_gpu: vulkan: Add support for exporting buffer memoryPhilip Langdale2018-10-228-6/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CUDA/Vulkan interop works on the basis of memory being exported from Vulkan and then imported by CUDA. To enable this, we add a way to declare a buffer as being intended for export, and then add a function to do the export. For now, we support the fd and Handle based exports on Linux and Windows respectively. There are others, which we can support when a need arises. Also note that this is just for exporting buffers, rather than textures (VkImages). Image import on the CUDA side is supposed to work, but it is currently buggy and waiting for a new driver release. Finally, at least with my nvidia hardware and drivers, everything seems to work even if we don't initialise the buffer with the right exportability options. Nevertheless I'm enforcing it so that we're following the spec.
* | build: more reliable way of getting the Swift version from a stringAkemi2018-10-221-1/+4
| | | | | | | | Fixes #6212
* | vo_gpu: vulkan: suppress bogus error message on --vulkan-deviceNiklas Haas2018-10-211-5/+5
| | | | | | | | | | | | Since the code just broke out of the loop on a match rather than jumping straight to the end of the function body, it ended up hitting the code path for when the end of the list was reached.
* | cocoa-cb: fix double clicking the title barAkemi2018-10-211-1/+29
| | | | | | | | | | | | | | | | | | since we draw our own title bar we lose the standard functionality of the system provided title bar. because of that we have to reimplement the functionality of double clicking the title bar. depending on the system preferences we want to minimize, zoom or do nothing. Fixes #6223
* | vo_gpu: vulkan: fix strncpy truncation in spirv_compiler_initBtbN2018-10-211-1/+1
| | | | | | | | | | | | Fixes GCC8 warning ../video/out/gpu/spirv.c: In function 'spirv_compiler_init': ../video/out/gpu/spirv.c:68:9: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
* | x11: fix icc profile when the window goes near off screenslatchurie2018-10-211-1/+1
| | | | | | | | | | | | | | | | On a multi monitor setup, when the center of the window was going off screen, the icc profile would always switch to the profile of the first screen. This fixes the issue by defaulting the value to the current screen.
* | vo_gpu: vulkan: fix the buffer size on partial uploadNiklas Haas2018-10-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | This was pased on the texture height, which was a mistake. In some cases it could exceed the actual size of the buffer, leading to a vulkan API error. This didn't seem to cause any problems in practice, since a too-large synchronization is just bad for performance and shouldn't do any harm internally, but either way, it was still undefined behavior to submit a barrier outside of the buffer size. Fix the calculation, thus fixing this issue.
* | vo_gpu: split --linear-scaling into two separate optionsNiklas Haas2018-10-195-31/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since linear downscaling makes sense to handle independently from linear/sigmoid upscaling, we split this option up. Now, linear-downscaling is its own option that only controls linearization when downscaling and nothing more. Likewise, linear-upscaling / sigmoid-upscaling are two mutually exclusive options (the latter overriding the former) that apply only to upscaling and no longer implicitly enable linear light downscaling as well. The old behavior was very confusing, as evidenced by issues such as #6213. The current behavior should make much more sense, and only minimally breaks backwards compatibility (since using linear-scaling directly was very uncommon - most users got this for free as part of gpu-hq and relied only on that). Closes #6213.
* | x11_common: replace atoi with strtoulNicolas F2018-10-191-1/+2
| | | | | | | | | | | | Using strtol and strtoul is allegedly better practice, and I'm going for strtoul here because I'm pretty sure X11 displays cannot be in the negative.
* | vo_gpu: opengl: fix segfault when gl->DeleteSync is unavailableNiklas Haas2018-10-161-1/+3
| | | | | | | | | | | | | | This deinit code was never checked, so this line would always crash on implementations without support for sync objects. Fixes #6197.
* | man: mention stats in interactive controlNicolas F2018-10-141-0/+5
| | | | | | | | | | | | | | Someone on IRC pointed out that the default stats bindings weren't documented in the interactive control section of the manual, so let's add them with a short mention and a reference to the STATS section of the manual.
* | cocoa-cb: fix side by side Split ViewAkemi2018-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | when entering a Split View a windowDidEnterFullScreen event happens without a previous toggleFullScreen call. in that case it tries to stop an animation that was never initiated by us and basically breaks the system initiated fullscreen, or in this case the Split View. immediately after entering the fullscreen it tries top stop the animation and resizes the window, which causes the window to exit fullscreen. only try to stop an animation that was initiated by us and is safe to stop.
* | {mac,cocoa}: trim trailing null out of macosx_icon when loading itRodger Combs2018-10-022-2/+5
| | | | | | | | | | | | This prevents crashes when loading the application icon image. Suggested-by: Akemi <der.richter@gmx.de>
* | mac: fix crash if we can't get an event tapRodger Combs2018-10-021-9/+12
| | | | | | | | | | | | | | | | without assistive-device permissions the event tap can't be create on 10.14 any more which lead to an assertion. System Preferences > Security & Privacy > Privacy > Accessibility and add mpv or your terminal App to the list.
* | encode: simplify encode_lavc_add_packetJan Ekström2018-10-011-2/+0
| | | | | | | | | | We're doing the same thing as the primary path - just that we log and set 'failed' to true.
* | encode: fix AVPacket deinitialization logicNiklas Haas2018-10-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | Since this function is called with packets on the stack, trying to free them makes no sense. Instead, it should unref (which is what `av_interleaved_write_frame` does anyway, rather than freeing). Also, the calling code tried unreffing the packet a second time, even after it was "freed" by the callee in the failure case - and after ownership was taken over by `av_interleaved_write_frame` in the successful case. Both of these cases were wrong.
* | stats: show file formatwm42018-10-011-0/+2
| | | | | | | | Useful in particular with ytdl, where you never know what you get.
* | demux_lavf: hack-fix EDL mp4 DASH hackwm42018-10-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I encountered a stream that fails with "Could not demux init fragment.". It turns out this is a regression from the recent change to that code. The assumption was that demux_lavf.c would treat this as concatenated stream - which it does, but not for probing. Doing this transparently is hard without doing it properly. Doing it properly would mean creating some sort of stream_concat (reminiscent of that FFmpeg security bug). I probably don't want to go there, and I think libavformat should just support this directly, so whatever. Hack-fix this with the knowledge that the init segment will always contain the headers.
* | stream_libarchive: fix hangs when demuxer does out of bound seekswm42018-10-011-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This happened with a .flac file inside an archive. It tried to seek beyond the end of the archive entry in a format where seeking isn't supported. stream_libarchive handles these situations by skipping data. But when the end of the archive is reached, archive_read_data() returns 0. While libarchive didn't bother to fucking document this, they do say it's supposed to work like read(), so I guess a return value of 0 really means EOF. So change the "< 0" to "<= 0". Also add some error logging. The same file actually worked without out of bounds reads when extracted, so there still might be something very wrong.
* | rendezvous: fix a typowm42018-10-011-1/+1
| |
* | demux: allow cache sizes > 2GBwm42018-10-011-4/+9
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
* | demux_lavf: v4l streams are not seekablewm42018-10-011-0/+2
| | | | | | | | | | | | | | FFmpeg is retarded enough not to give us any indication whether it is (unless we query fields not in the ABI/API). I bet FFmpeg developers love it when library users have to litter their code with duplicated information.
* | ao_audiounit: rename pause function to resetJosh Lehman2018-09-301-1/+1
| | | | | | | | | | AudioUnit output driver uses the pull based api so it should have a reset function instead of a pause function.
* | cocoa-cb: add Apple Software Renderer supportAkemi2018-09-305-3/+42
| | | | | | | | | | | | by default the pixel format creation falls back to software renderer when everything fails. this is mostly needed for VMs. additionally one can directly request an sw renderer or exclude it entirely.
* | cocoa-cb: move macOS option retrieval to the earliest point possibleAkemi2018-09-302-6/+6
| | | | | | | | | | | | | | moved the retrieval of the macOS specific options from the backend initialisation to the initialisation of the CocoaCB class, the earliest point possible. this way macOS specific options can be used for the opengl context creation for example.
* | add swift as main dependency so all dependencies can be disabled easilyAkemi2018-09-302-2/+9
| |
* | build: check for Swift version and disable dependencies if neededAkemi2018-09-303-4/+11
| |
* | Improve readme aesthetics.Aman2018-09-301-7/+5
| | | | | | | | | | This fixes the line under the header, creates a title header, and slightly improves list formatting.
* | drm_atomic: Allow to create atomic context w/o drmprime video planeAnton Kindestam2018-09-302-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is to improve the experience when running with default settings on a driver that doesn't have any overlay planes (or indeed only one plane), but still supports DRM atomic. Since the drmprime video plane is set to pick an overlay plane by default it would fail on these drivers due to not being able to create any atomic context. Users with such cards had to specify --drm-video-plane-id manually to some bogus value (it's not used after all). The "video" plane is only ever used by the drmprime-drm hwdec interop, which is not used at all in the typical usecase where everything is actually rendered on to the "OSD" plane using EGL, so having an atomic context without the "video" plane should be fine most of the time.
* | manpage: minor fix to --drm-formatAnton Kindestam2018-09-301-1/+1
| | | | | | | | Looking at other examples, a bar should be used when listing OPT_CHOICE options.
* | demux/packet: fix demux_packet_shortenTom Yan2018-09-301-2/+2
| | | | | | | | for the rawaudio demuxer to do the expected gapless playback
* | travis: enable CI for release branchesJan Ekström2018-09-291-0/+1
| |
* | vo_gpu: fix vec3 packing in UBOs/push_constantsNiklas Haas2018-09-291-11/+13
| | | | | | | | | | | | | | | | | | | | | | For vec3, the alignment and size differ. The current code will pack a struct like { vec3; float; vec2 } into 8 machine words, whereas the spec would only use 6. This actually fixes a real bug: The only place in the code I could find where it was conceivably possible that a vec3 is followed by a float was when using --gpu-dumb-mode in combination with --gamma-factor, and only when --gpu-api=vulkan. So it's no surprised nobody ran into it yet.
* | vo_gpu: use explicit offsets for push constantsNiklas Haas2018-09-291-2/+1
| | | | | | | | | | | | | | | | | | These used to be unsupported long ago, but it seems glslang added support in the meantime. (I don't know which version, but I'm guessing it was long enough ago that we don't have to add a feature check) Should hopefully help make push constant layouts more robust against possible bugs either in our code or in the driver.
* | ao_alsa: log the ALSA state if we get a non-XRUN errorJan Ekström2018-09-291-2/+4
| | | | | | | | | | The ALSA state generally can tell us more information in case we get an unexpected error.
* | ao_alsa: handle XRUNs separately from other errorsJan Ekström2018-09-291-2/+7
| | | | | | | | | | | | | | | | | | According to ALSA doxy, EPIPE is a synonym to SND_PCM_STATE_XRUN, and that is a state that we should attempt to automatically recover from. In case recovery fails, log an error and return zero. A warning message will still be output for each XRUN since those are not something we should generally be receiving.
* | ao_alsa: early exit get_space if paused or ALSA is not readyJan Ekström2018-09-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | This has been way too long coming, and for me to notice that a whole lot of ao_alsa functions do an early return if the AO is paused. For the STATE_SETUP case, I had this reproduced once, and never since. Still, seems like we can start calling this function before the ALSA device has been fully initialized so we might as well early exit in that case.
* | man/options: emphasize ytdl_hook's script optionsRicardo Constantino2018-09-261-6/+5
| |
* | vo_gpu: adjust PRNG variant used by GL shaderssfan52018-09-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | Certain low-end Mali GPUs have a rather low precision and overflow during the PRNG calculations, thereby breaking e.g. deband-grain. Modify the permute() to avoid this, this does not impact the quality of PRNG output (noticeably). This problem was observed on: GL_VENDOR='ARM', GL_RENDERER='Mali-T720' GL_VERSION='OpenGL ES 3.1 v1.r15p0-00rel0.bdd9e62cdc8c88e0610a16b5901161e9'
* | ytdl_hook: fix audio not being picked up for some sitesRicardo Constantino2018-09-261-2/+2
| |
* | ao_jack: only auto-connect to audio portsNiklas Haas2018-09-261-1/+2
| | | | | | | | | | This prevents ao_jack from auto-connecting to MIDI ports (or other, hypothetical future port types).
* | encode: fix expected streams when using --lavfi-complexTSaaristo2018-09-261-8/+8
| | | | | | | | | | | | | | | | | | mpctx->current_track[0][STREAM_VIDEO] (and STREAM_AUDIO) are empty when using --lavfi-complex. Moving the muxer stream hinting after audio/video chain initialization and checking if the chains exist fixes encoding with --lavfi-complex. Previously, the output audio/video streams did not get prepared and the encode would fail due to unexpected stream addition.
* | ci: explicitly call waf with python3Martin Herkt2018-09-112-4/+4
| | | | | | | | | | | | Python 2 may not be present in the CI images in the future, but waf’s shebang line still uses its executable name. Explicitly call the right major version of the interpreter.
* | mp_image: strip all HDR peak information from SDR clipsNiklas Haas2018-09-051-0/+6
| | | | | | | | | | | | | | By overriding it with 1.0 (aka SDR). This prevents blowing up on mistagged clips. Fixes #6111
* | vo_gpu: switch to optimization level performanceNiklas Haas2018-09-011-1/+1
| | | | | | | | | | | | Upstream has this now. Didn't really make any different for me (except making the polar compute shader 2%-3% faster), but maybe it does for somebody else.
* | ao_pulse: fix tlength calculationTom Yan2018-09-013-17/+3
| | | | | | | | also remove the now unused non-sensical af_fmt_seconds_to_bytes.
* | Revert "ao_openal: enable building on OSX"Michael Hoang2018-08-263-27/+2
| | | | | | | | | | | | This reverts commit af6126adbe61fb2b6cc780025246d33df93072e6. Apple's OpenAL support is ridiculously out of date, revert back to just using OpenAL Soft on macOS (fixes #4645).
* | vo_gpu: avoid overwriting compute shader block sizesNiklas Haas2018-08-261-4/+10
| | | | | | | | | | | | | | | | | | | | When using multiple compute shaders as part of the same pass, there can be a conflict in the block sizes. In the problematic case, the HDR detection shader can collide with the polar sampling shader. In this case, the solution is clear - the passes that can handle any size should "give in" and not overwrite the block sizes. Fixes #6083.
* | af_rubberband: reset delay to 0 on resetHector Martin2018-08-251-0/+2
| | | | | | | | This fixes A-V drift on seeking
* | osdep: make use of HAVE_ANDROIDTom Yan2018-08-203-4/+8
| |
* | wscript: split egl-android from androidTom Yan2018-08-204-9/+11
| |
* | manpage: fix reference to --tone-mapping by old option nameAnton Kindestam2018-08-181-1/+1
| |
* | ytdl_hook: always load ytdl:// links with ytdl_hook firstRicardo Constantino2018-08-171-7/+23
| | | | | | | | Suggested in IRC by sfan5.
* | ao_opensles: set numBuffers to 8Tom Yan2018-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently some Android builds/forks require this for Bluetooth audio to work as they unexpectedly accept fast flag for it. Shouldn't cause any side-effect (e.g. buffer requirement increased when on wired audio). It's a hardcoded default in the upstream AAudio implementation anyway. Ref.: https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaaudio/src/legacy/AudioStreamTrack.cpp#109 https://android.googlesource.com/platform/frameworks/wilhelm/+/android-8.0.0_r1/src/android/AudioPlayer_to_android.cpp#1680 https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaudioclient/AudioTrack.cpp#488
* | demux_edl: add title option to override title of chapterssfan52018-08-132-1/+22
| |
* | player: expose hearing/visual impaired flags on audio tracksAman Gupta2018-08-135-0/+12
| | | | | | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* | build: add --no-download option to bootstrap.pyPhilip Sequeira2018-08-131-0/+4
| | | | | | | | | | | | | | With this option, the script will check that the expected waf version is present, but will simply fail if it's not, rather than trying to download it. This allows a package build script to avoid compile-time network access but still ensure it's using the right waf version.
* | osx: Fix initialization and access of service menuMichael Hoang2018-08-111-2/+2
| | | | | | | | | | Replace dot syntax with accessor syntax so that clang no longer errors out due to not finding the property servicesMenu on NSApp.
* | cocoa-cb: fix crash on macOS 10.10Akemi2018-08-111-1/+3
| | | | | | | | | | | | the colorspace of the layer is only available on 10.11 and upwards. Fixes #6041
* | cocoa-cb: fix crash when no screen is availableAkemi2018-08-111-1/+1
| | | | | | | | | | | | | | | | instead of force unwrapping and chaining the optional vars in our containsMouseLocation function, safely unwrap and guard the resulting var. Fixes #6062
* | audio/format: decouple af_fmt_is_planar from af_fmt_to_planarTom Yan2018-08-111-16/+15
| | | | | | | | | | so that af_fmt_to_planar (and hence af_fmt_from_planar) can just return the input when it is not an interleaved (planar) format.
* | manpage: Correct show-text duration default valuejaseg2018-08-051-1/+1
| | | | | | duration is parsed as an integer, and the default value is used if ```-1``` is passed. Passing ```-``` as described here causes a parameter value error.
* | manpage: fix --vf exclamation mark descriptionpavelxdd2018-08-051-1/+1
| | | | | | | | | | An exclamation mark disables the filter by default instead of enabling it.
* | ao_opensles: update interface-changesTom Yan2018-08-051-0/+9
| |
* | ao_opensles: rework the heuristic of buffer/enqueue size settingTom Yan2018-08-051-18/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ao->device_buffer will only affect the enqueue size if the latter is not specified. In other word, its intended purpose will solely be setting/guarding the soft buffer size. This guarantees that the soft buffer size will be consistent no matter a specific enqueue size is set or not. (In the past it would drop to the default of the generic audio-buffer option.) opensles-frames-per-buffer has been renamed to opensles-frames-per -enqueue, as it was never purposed to set the soft buffer size. It will only make sure the size is never smaller than itself, just as before. opensles-buffer-size-in-ms is introduced to allow easy tuning of the relative (i.e. in time) soft buffer size (and enqueue size, unless the aforementioned option is set). As "device buffer" never really made sense in this AO, this option OVERRIDES audio-buffer whenever its value (including the default) is larger than 0. Setting opensl-buffer-size-in-ms to 1 allows you to equate the soft buffer size to the absolute enqueue size set with opensl-frames-per -enqueue conveniently (unless it is less than 1ms). When both are set to 0, audio-buffer will be the ultimate fallback. If audio-buffer is also 0, the AO errors out.
* | ao_opensles: allow s32 and float outputTom Yan2018-08-051-27/+15
| | | | | | | | | | OpenSLES (and its AudioTrack backend) in Android can take 32-bit fixed and floating point input since Android L (API 21).
* | audio/format: minor fix for af_fmt_from_planarTom Yan2018-08-051-2/+4
| | | | | | | | See af_fmt_to_planar.
* | stream_smb/stream_file: fix `write_buffer`Yclept Nemo2018-07-292-16/+16
| | | | | | | | | | | | | | Functions `write` and `smbc_write` are given a diminishing buffer of incorrect constant size. After partial writes, the code would do another write of the full original length, failing to subtract the amount already written.
* | stream_smb: locking to bypass libsmbclient issuesYclept Nemo2018-07-291-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thread-unsafe libsmbclient is likely to crash when used simultaneously across threads. For example, by: mpv "smb://...mkv" --sub-file "smb://...srt" Work around this by locking all calls to this library under a single global mutex. This is a temporary solution. When the libsmbclient bug [1] is fixed, switch to the code from branch [2] which uses a new api to create per-thread smb contexts. Fixes [3]. [1] https://bugzilla.samba.org/show_bug.cgi?id=11413 [2] https://github.com/orbisvicis/mpv/tree/smbclient_threaded_api [3] https://github.com/mpv-player/mpv/issues/5936
* | ci: do bootstrap outside the docker containerJan Ekström2018-07-293-2/+1
| | | | | | | | | | | | | | This way the docker container in itself does no networking. It seems like travis disabled network access from the actual docker containers.
* | manpage: fixup mistaken show playlist/track-list shortcutsDaniel M. Capella2018-07-231-2/+2
| | | | | | | | | | This was mistaken in 496b13227b7f4b47a660bbf4e314f9a55b7e8867 and not noticed in review.
* | Update VERSIONMartin Herkt2018-07-221-1/+1
| |
* | Release 0.29.0v0.29.0Martin Herkt2018-07-222-116/+95
| |
* | wscript_build: apply project-wide CFLAGS/LDFLAGS to mpv.comStephen Hutchinson2018-07-191-2/+2
| | | | | | | | | | | | | | mpv.com fails to build when cross-compiling with a multilib version of GCC, because the -m32 flags aren't getting passed to the build process for osdep/win32-console-wrapper.c or the link phase for mpv.com itself.
* | build: if libdir is not set, set it to EXEC_PREFIX/libJan Ekström2018-07-191-0/+13
| | | | | | | | | | This way the behavior of default libdir stays consistent before and after switching to gnu_dirs from waf itself.
* | build: bump waf to 2.0.9Akemi2018-07-121-2/+2
| | | | | | | | Among other things, fixes compatibility with python 3.7.x.
* | build: utilize built-in gnu_dirs module for installation directoriesAkemi2018-07-122-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This started breaking with newer (2.0.x) waf versions, and it was noticed that a built-in waf module was providing very similar functionality. APPNAME definition was required to have `gnu_dirs`' PACKAGE variable to be defined in order to have f.ex. documentation installed to the correct directory. Currently unused options added by `gnu_dirs` were removed to clean up the output of the help command. Effective changes to behavior: - `gnu_dirs` will attempt to figure out if it needs to use lib64 instead of lib within your installation prefix. If you would like it to not do that, set `--libdir` during configuration. The way it tries to figure lib/lib64 out is if there's a `/usr/lib64` and no `/usr/lib32`. - `--incdir` is now `--includedir` as per standard `gnu_dirs` behavior.
* | build: explicitly delay adding of object files to linkingAkemi2018-07-121-0/+1
| | | | | | | | | | | | | | | | | | | | Before, `do_the_symbol_stuff` would implicitly come before `handle_add_object`, which adds object files to the linking task. With newer (2.0.x) versions of waf, the ordering seems to get more optimized, and thus we have to declare that the function that creates the linking task should come before the task that adds object files to the task.
* | hwdec_vaegl: Fix VAAPI EGL interop used with gpu-context=drmAnton Kindestam2018-07-093-6/+29
| | | | | | | | | | | | | | | | Add another parameter to mpv_opengl_drm_params to hold the FD to the render node, so that the fd can be passed to hwdec_vaegl. The render node is opened in context_drm_egl and inferred from the primary device fd using drmGetRenderDeviceNameFromFd.
* | context_drm_egl: Fix CRTC setup and release code when using atomicAnton Kindestam2018-07-096-41/+217
| | | | | | | | | | | | | | | | | | | | The previous code did not save enough information about the old state, and could end up changing what plane the fbcon:s FB got attached to, or in worse case causing a blank screen (observed in some multi-screen setups on Sandy Bridge). In addition refactor the handling of drmModeModeInfo property blobs to not leak, as well as enable reuse of already created blobs.
* | context_drm_egl: Fix some memory leaks on error exitAnton Kindestam2018-07-091-63/+66
| | | | | | | | | | Fix some memory leaks on error exit in crtc_setup_atomic and crtc_release_atomic.
* | gpu: prefer 16bit floating point FBO formats to 16bit integer onesJan Ekström2018-07-082-4/+7
| | | | | | | | | | | | According to earlier discussions, this can improve visual quality. This only changes the preferred order of the formats, not the formats themselves.
* | build: fix linking libmpv when swift features are buildAkemi2018-07-081-7/+14
| | | | | | | | | | | | | | | | this was caused by commit 2e7a4f7. the LAST_LINKFLAGS were not added to the linking of libmpv and that caused a linking error. manually add the link flags the same way it's done when linking mpv. Fixes #5968
* | wscript_build: fixup swift include parameter to point to source rootJan Ekström2018-07-081-2/+2
| | | | | | | | | | | | Fixes compilation of the swift components with `--variant="random_string"`, in which case "." is not the source directory.
* | ci: add mingw64 targetsMartin Herkt2018-07-052-1/+38
| |
* | ci: switch to cirno.systems docker registryMartin Herkt2018-07-051-4/+4
| | | | | | | | Much faster build cycles and more consistent download bandwidth.
* | ci: enable libsmbclientMartin Herkt2018-07-051-5/+6
| |
* | ci: switch Travis env language to genericMartin Herkt2018-06-251-1/+1
| | | | | | | | This way it doesn’t override CC.
* | ci: add more build targetsMartin Herkt2018-06-251-2/+5
| | | | | | | | | | Travis now builds with Clang and containers with git snapshots of some dependencies.
* | ci: Use custom container for Travis buildsMartin Herkt2018-06-252-22/+26
| | | | | | | | | | | | | | | | Temporary solution. For now, this builds using a container image based on openSUSE Tumbleweed with the current FFmpeg release. More containers will be added (at least with git snapshots of FFmpeg and libass), and Travis will eventually be replaced with something we have more control over.
* | TOOLS/autoload: Fixed broken "disabled" optionAndreas Wennerberg2018-06-231-0/+1
| | | | | | | | `--script-opts=autoload-disabled=yes` now properly stops the script from running.
* | demux_mkv: add A_MLP to mkv_audio_tagsNicolas F2018-06-221-0/+1
| | | | | | | | Fixes #5923
* | build: add static libraries to libmpv.pcMartin Herkt2018-06-201-4/+8
| |
* | cocoa-cb: fix building with Swift 4.2coverity_scanAkemi2018-06-122-7/+7
| | | | | | | | | | | | | | | | | | init is a reserved keyword and Swift 4.2 got a bit stricter about using it. this could be fixed by adding apostrophes around init but makes the code uglier. hence i just renamed init to initialized and for consistency uninit to uninitialized. Fixes #5899
* | build: manually add standard library search paths for linkingAkemi2018-06-122-8/+11
| | | | | | | | | | | | | | | | | | | | | | this reverts commit a174566 since the actually reason for failing has been found. the isysroot flag overwrites the framework and library search paths. though we only need to overwrite the former and there is no way to just overwrite that one. we manually add the standard library search paths to the very end of the linking command, so it won't interfere with the search paths extracted by waf. Fixes #5791
* | cocoa-cb: remove pre-allocation of window, view and layerAkemi2018-06-129-140/+158
| | | | | | | | | | | | | | | | | | | | | | the pre-allocation was needed because the layer allocated a opengl context async itself and we couldn't influence that. so we had to start the core after the context was actually allocated. furthermore a window, view and layer hierarchy had to be created so the layer would create a context. now, instead of relying on the layer to create a context we do this manually and re-use that context later when the layer wants to create one async itself.
* | vo_libmpv: pass vo struct to the control callbackAkemi2018-06-123-11/+13
| |
* | options.c: display additional metadata tags during video playbackStephen Hutchinson2018-06-111-2/+3
| | | | | | | | | | | | | | | | The currently-displayed tags make sense for music files, but similar information for video is more commonly - or at least should be - put under other tags, while the audio-related tags are often used for other information on video files (particularly with youtube-dl's output).
* | stats: remove superfluous line breaksJulian2018-06-091-1/+1
| | | | | | | | | | Those accidentally slipped in with 9975835bdeec3f2b04b136ef40c70b02487bb0e6 due to bad copy & paste.
* | hwdec_drmprime_drm: Do not show error message during probingAnton Kindestam2018-06-081-1/+1
| | | | | | | | | | Change the log-level of an error message that would sometimes show up during hwdec probing, and could be misleading.
* | stream_file: enable cache for FUSE filesystems on OpenBSD and FreeBSDgall0ws2018-06-051-1/+1
| |
* | osc: fix accidentally skipping files when seeking with sliderfatalis2018-06-041-0/+2
| | | | | | | | | | | | | | When seeking near the end of the file and the next file loads, seeking continues on the next file at the same position and then immediately the file after that. This patch stops slider seeking when a new file is loaded, which is the standard behavior of many other players.
* | ao_alsa: simplify get_space()Jan Ekström2018-06-041-6/+10
| |
* | ao_alsa: replace snd_pcm_status() with snd_pcm_avail() in get_space()Muhammad Faiz2018-06-041-5/+4
| | | | | | | | | | | | | | | | | | | | Fixes a bug with alsa dmix on Fedora 29. After several minutes, audio suddenly becomes bad and muted. Actually, I don't know what causes this. Probably this is a bug in alsa. In any case, as snd_pcm_status() returns not only 'avail', but also other fields such as tstamp, htstamp, etc, this could be considered a good simplification, as only avail is required for this function.
* | vo_sdl: add support for screensaver VOCTRL'ssfan52018-06-021-3/+24
| | | | | | | | | | Previously vo_sdl would unconditonally disable the screensaver, ignoring the `stop-screensaver` option.
* | vo_gpu: desaturate after peak detectionNiklas Haas2018-05-311-12/+12
| | | | | | | | | | | | | | | | | | | | This sacrifices some dynamic range for well-behaved sources, but prevents catastrophic desaturation on badly mastered / too bright sources. I think that's the better trade-off. This makes the desaturation algorithm much "safer" to deploy by default, as well. One could even argue going up to strength 1.0, which works better for some sources but worse for others. But I think the current strength is the best trade-off even after this change.
* | player: fix coding stylewm42018-05-311-3/+3
| | | | | | | | | | I'm also not sure whether this condition doesn't subtly break a lot of things.
* | demux_lavf: drop obscure genpts optionwm42018-05-312-11/+0
| | | | | | | | | | This code shouldn't even exist in libavformat. If you still need it, you can enable it via --demuxer-lavf-o.
* | options: add --http-proxywm42018-05-312-0/+11
| | | | | | | | Often requested, trivial.
* | player: remove deprecated vo/ao auto profileswm42018-05-312-9/+2
| | | | | | | | | | These were deprecated almost 2 years ago. Now they happen to be in the way.
* | m_config: remove outdated commentwm42018-05-311-1/+0
| |
* | m_config: check for int16_t offset overflowwm42018-05-311-1/+3
| | | | | | | | | | | | | | | | For some reason shadow_offset is a int16_t variable (to save some space or something), which means the static part of the entire option list must be below 32KB. This is fine, but still add a check against overflows. (Currently it's 3.6KB. This does not include dynamic allocations like strings.)
* | m_config: remove an unused functionwm42018-05-312-15/+0
| |
* | m_option: remove an unused fieldwm42018-05-312-13/+0
| |
* | m_config: cosmetics: fix 2 typoswm42018-05-311-2/+2
| |
* | manpage: update --demuxer-thread optionwm42018-05-311-3/+6
| | | | | | | | Be a bit more detailed, and discourage disabling it.
* | player: simplify edition switchingwm42018-05-314-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The player fully restarts playback when the edition or disk title is changed. Before this, the player tried to reinitialized playback partially. For example, it did not print a new "Playing: <file>" message, and did not send playback end to libmpv users (scripts or applications). This playback restart code was a bit messy and could have unforeseen interactions with various state. There have been bugs before. Since it's a mostly cosmetic thing for an obscure feature, just change it to a full restart. This works well, though since it may have consequences for scripts or client API users, mention it in interface-changes.rst.
* | cmd: do not use a random value for MP_CMD_OPT_ARGwm42018-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | This flag is used only by the command parser. Its value overlapped with some of the existing m_option flags, but only flags that did not matter for the command parser (i.e. the flag bits used had mostly private uses in each component). It's still a bit unclean and dangerous to use an essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it. Since M_OPT_OPTIONAL_PARAM has a slightly longer name than MP_CMD_OPT_ARG, I'm going to keep the old name.
* | player: use canonical playback time for video refresheswm42018-05-251-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When changing video filters during initialization, there was a small time window where video was initialized, but playback restart was not complete yet. In this time window, playback_pts is not set. But since issue_refresh_seek() was using this, it could lead to no refresh being done _if_ the "video" had only 1 frame (such as cover art). Fix this by using get_current_time() instead, which is the current time with corner cases such as ongoing loading or seeks taken into account. See also the previous commit. Without that, get_current_time() could return NOPTS during init. Fixes #5831.
* | manpage: mention that fd:// file descriptors may be modifiedwm42018-05-251-0/+2
| | | | | | | | | | For example, we call setmode() to switch a FD from text to binary mode on garbage OSes.
* | stream_file: properly detect stdin as pipewm42018-05-251-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | There is some code that checks a FD for whether it is a regular file or not. If it's not a regular file, it e.g. enables use of poll() to avoid blocking forever. But this was done only for FDs that were open()ed by us, not from stdin special handling or fd://. Consequently, " | mpv -" could block the player. Fix this by moving the code and running for it on all FDs. Also, set p->regular_file even on mingw.
* | manpage: remove a reference to a removed optionwm42018-05-251-2/+1
| |
* | demux: fix/improve aspects of EOF signalingwm42018-05-251-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current packet queue was completely empty, and EOF was reached, the queue->is_eof flag was not correctly set to true. Change this by reading ds->eof to check whether the stream is considered EOF. We also need to make sure update_seek_ranges() is called in this case, so change the code to simply call it when queue->is_eof changes. Also, read_packet() needs to call adjust_seek_range_on_packet() if ds->eof changes. In that case, the decoder also needs to be notified about EOF. So both of these should be called when ds->eof changes to true. (Other code outside of this function deals with the case when ds->eof is changed to false.) In addition, this code was kind of shoddy about calling wakeup_ds() correctly. It looks like there was an inverted condition, and sent a wakeup to the decoder only when ds->eof was already true, which is obviously bogus. The final EOF case tried to be somehow clever about checking in->last_eof for notifying the codec, which is sort of OK, but seems to be strictly worse than just checking whether ds->eof changed. Fix these things.
* | ipc: cosmetic: switch a negated if/elsewm42018-05-251-3/+3
| |
* | ipc: alias set_property_string to set_propertywm42018-05-252-28/+4
| | | | | | | | | | | | | | | | | | The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
* | video: trust container FPS early on if possiblewm42018-05-251-1/+2
| | | | | | | | | | If the container FPS is correct, this can help getting ideal mix factors for vo_gpu interpolation mode. Otherwise, it doesn't matter.
* | manpage: mention that --no-correct-pts can break seeking toowm42018-05-251-2/+2
| |
* | dispatch: add an assert()wm42018-05-251-0/+1
| |
* | input: move an enum back to its correct placewm42018-05-252-13/+13
| | | | | | | | This was accidentally moved together with the cmd stuff.
* | demux_lavf: remove ffm blacklist entrywm42018-05-251-2/+0
| | | | | | | | ffm (ffserver) was removed from ffmpeg.
* | input: add a define for the number of mouse buttons and use itwm42018-05-253-1/+7
| | | | | | | | (Why the fuck are there up to 20 mouse buttons?)
* | vd_lavc: minor simplification for get_format fallbackwm42018-05-251-7/+1
| | | | | | | | | | | | | | | | | | | | | | The default get_format does exactly do this, so we don't need to duplicate it. The only potential problem with this is that the logic doesn't entirely prevent that the avcodec_default_get_format hw_device_ctx path is triggered, which would probably work, but has unknown consequences and interactions. But the way the logic currently works it can't happen, provided the hwaccel metadata libavcodec provides is correct.
* | terminal-unix: stop trying to read when terminal disappearswm42018-05-251-2/+4
| | | | | | | | | | | | | | | | Avoids 100% CPU usage due to terminal code retrying read(). Seems like this was "forgotten" (or there was somehow the assumption poll() would not signal POLLIN anymore). Fixes #5842.
* | x11: support Shift+TABNiklas Haas2018-05-241-1/+1
|/ | | | | | | | | | | | | | For some reason, the X default modifier map binds shift+tab to ISO_Left_Tab instead of the regular Tab. So to get Shift+TAB recognized by mpv, we also need to accept ISO_Left_Tab. This patch matches what other programs like e.g. Qt do, which treat Tab and ISO_Left_Tab as the same thing. God only knows why the distinction exists, and why X decides to mix up its bindings like that. Fixes #5849
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-246-5/+36
| | | | | | | | | | | | | | | Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux_lavf: co-locate disposition checksAman Gupta2018-05-241-2/+2
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* waf: require wayland-protocols >= 1.14Rostislav Pehlivanov2018-05-201-1/+1
| | | | Needed for the new xdg-wm tiling enums.
* wayland_common: require wl_compositor of version 3Rostislav Pehlivanov2018-05-201-3/+2
| | | | | We already did require it, in order to call set_buffer_scale. This just makes it error out more gracefully.
* wayland_common: fix maximized stateRostislav Pehlivanov2018-05-202-13/+22
| | | | Window size should not change if the window has been maximized or tiled.
* vo_gpu: allow higher icc-contrast and improve loggingNiklas Haas2018-05-172-3/+4
| | | | | | | | | | With the advent of actual HDR devices, my real measured ICC profile has an "infinite" contrast, since the display is completely off on pure black inputs. 100k:1 might not be enough, so let's just bump it up to 1m:1 to be safe. Also, improve the logging in the case that the detected contrast is too high by default.
* stats: show sample format of audio tracksfan52018-05-171-0/+1
|
* waftools: update clang_compilation_databaseBin Jin2018-05-171-13/+33
| | | | | The old copy is broken with waf-1.9.8, update to the latest commit (waf-project/waf@5e4b86b81df3b9819738d757eb8d2c8646ef0ede) instead.
* manpage: fix typoNiklas Haas2018-05-171-1/+1
|
* manpage: clarify target-prim/trc=auto behaviorNiklas Haas2018-05-171-2/+6
| | | | | | | This logic has been changed throughout the years, notably in 38ac5d5 and 3bdbf6. Update the documentation to reflect the current state. Closes #5834.
* m_option: fix duplicate flag valuePhilip Sequeira2018-05-131-2/+2
|
* wscript: Remove code check for cuda hwaccelPhilip Langdale2018-05-102-17/+1
| | | | | | This was there originally to detect too-old versions of ffmpeg. We now only support >= 4.0, so it's not relevant. We just need the dependencies to be present.
* drm_atomic: Fix memory leaks in drm_atomic_createAnton Kindestam2018-05-081-34/+33
| | | | | | | | | First fix a memory leak when skipping cursor planes by inverting the check and putting everything, but the free, in the body. Then fix a missed drmModeFreePlane by simply copying the fields of the drmModePlane we are interested in and freeing the drmModePlane struct early.
* ytdl_hook: try to set video track first if availableRicardo Constantino2018-05-031-4/+4
| | | | | | | Fixes `--ytdl-format="dash-fastly_skyfire-video-363357330+dash-fastly_skyfire_sep-audio-363357330" https://vimeo.com/108650530` This happened because the video track also had audio available and after adding it expecting an audio-only track, there were no more tracks with video.
* player: add more logging around buffering stateAman Gupta2018-05-031-2/+7
|
* command: fix condition for failure when parsing cycle-value paramswm42018-05-031-1/+1
| | | | | | Could make it behave differently (and leak memory) in certain cases. Basically, m_option_parse() randomly returns 0 or 1, but most time 1, with the difference due to legacy reasons that don't matter anymore.
* command: simplify option property initwm42018-05-031-22/+13
| | | | | | | The "if (prop.name)" check is redundant, because an assert above it implies that it never can be NULL. Deduplicate some code for initializing the "prop" variable.
* input: rename weirdly named functionwm42018-05-033-4/+5
|
* input: move some more cmd definitions to cmd.hwm42018-05-032-64/+64
| | | | | | Now both command "descriptions" and runtime command instances are in cmd.h, which makes sense to me. input.h is now for the actual input context.
* input: merge cmd_list.c with cmd.cwm42018-05-037-146/+88
| | | | | | It doesn't really make sense to keep a separate cmd_list.c file, which does _not_ contain a command list, but only a few minor helper functions.
* input: rename cmd_parse.c to cmd.cwm42018-05-032-1/+1
| | | | | Done separately from the cmd.h rename to avoid issues with git being bad at tracking mixed content and filename changes.
* input: rename cmd_parse.h to cmd.hwm42018-05-035-5/+3
|
* command: split big command handler switch into separate functionswm42018-05-034-866/+1018
| | | | | | | | | | | | | | | | | | | This gets rid of run_command() and its big switch statement, which was an idiotically big function of almost 1000 lines. The switch is replaced with a callback per command, and each command is now implemented in its own function. Command IDs are not needed anymore, so the mp_command_type enum disappears. There should be no functional changes, but since this refactors 64 commands, regressions are possible. The handler() parameter is void*, because in theory the input code is supposed to be independent of the player core code. For example, you should be able to reuse the command parser code for some other part of mpv. In practice, the variable containing command list is defined in the player core anyway, so you could say this doesn't work. But I'm still trying to hold onto this idea, so I went with void*.
* input: remove some explicit uses of command IDswm42018-05-036-31/+37
| | | | | | | | | | The plan is to remove the command ID enum. This will happen by replacing the big switch statement in command.c with dispatching to per-command callbacks. As preparation, remove uses of the command IDs outside of the actual dispatching mechanism. Also remove some instances of checking cmd->def for NULL. We now require this always to be set.
* input: remove legacy command handlingwm42018-05-033-84/+0
| | | | | | | | These are old MPlayer commands that were redundant since 2007 or so. In 2013, mpv explicitly deprecated them (actually removed them, but left this wrapper, which translated them to modern commands). The list was not extended since 2013, and mpv always warned on the terminal when a legacy command was used. So it's time to remove it.
* input: move command list to command.cwm42018-05-032-215/+216
| | | | Preparation for more changes.
* encode: remove removed encode options from presetsTheAMM2018-05-031-13/+4
|
* build: make encoding mode non-optionalwm42018-05-0310-40/+9
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: get rid of the output packet queuewm42018-05-0313-79/+147
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* vo_lavc: explicitly skip redraw and repeated frameswm42018-05-032-8/+11
| | | | | | | | | | | The user won't want to have those in the video (I think). The core can sporadically issue redraws, which is what you want for actual playback, but not in encode mode. vo_lavc can explicitly detect those and skip them. It only requires switching to a more advanced internal VO API. The comments in vo.h are because vo_lavc draws to one of the images in order to render OSD. This is OK, but might come as a surprise to whoever calls draw_frame, so document it. (Current callers are OK with it.)
* video: actually wait for last frame being rendered on EOFwm42018-05-031-1/+5
| | | | | | | | | | | | | | | | | | | The video timing code could just decide that EOF was reached before it was displayed. This is not really a problem for normal playback (if you use something like --keep-open it'd show the last frame anyway, otherwise it'd at best flash it on screen before destroying the window). But in encode mode, it really matters, and makes the difference between having one frame more or less in the output file. Fix this by waiting for the VO before starting the real EOF. vo_is_ready_for_frame() is normally used to determine when the VO frame queue has enough space to send a new frame. Since the VO frame queue is currently at most 1 frame, it being signaled means the remaining frame was consumed and thus sent to the VO driver. If it returns false, it will wake up the playloop as soon as the state changes. I also considered using vo_still_displaying(), but it's not reliable, because it checks the realtime of the frame end display time.
* encode: remove old timestamp handlingwm42018-05-037-291/+57
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* encode: restore 2-pass modewm42018-05-031-2/+7
| | | | | | | | | | While I'm not sure whether it really works, at least it writes the pass1 log correctly now. How 2-pass stat output is supposed to interact with the new decode API is rather fishy. ffmpeg.c does the same, and before this change, the log was not written on EOF (when at least libvpx actually outputs its stats).
* manpage: -pre, -del etc. does not work on some options anymorewm42018-05-031-25/+4
| | | | | | With the internal change from stringlist to keyvaluelist, these sub-options stop working. I don't really care enough to bring them back. (Order doesn't matter, -del always seemed annoying.)
* docs/vo: fixup some minor typos a la "planed" instead of "plane"Jan Ekström2018-05-011-3/+3
|
* drm_atomic: Disallow selecting cursor planes using the optionsAnton Kindestam2018-05-011-0/+3
|
* drm_common: Be smarter when deciding on which CRTC and Encoder to useAnton Kindestam2018-05-011-1/+27
| | | | | | | | | | | | | | | | | Inspired by kmscube, first try to pick the Encoder and CRTC already associated with the selected Connector, if any. Otherwise try to find the first matching encoder & CRTC like before. The previous behavior had problems when using atomic modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that was currently being used by the fbcon together with another Encoder. drmModeSetCrtc was able to "steal" the CRTC in this case, but using atomic modesetting we do not seem to get this behavior automatically. This should also improve behavior somewhat when run on a multi screen setup with regards to deinit and VT switching (still sometimes you end up with a blank screen where you previously had a cloned display of your fbcon)
* context_drm_egl: fix some comments and log messages that had not been ↵Anton Kindestam2018-05-011-6/+5
| | | | updated since the plane rename commit
* drm/atomic: Fix crtc_setup_atomic and crtc_release_atomicAnton Kindestam2018-05-011-25/+33
| | | | | | | | | | | Add some properties which where forgotten in crtc_setup_atomic. In both change to not use DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK flags. This should make it more similar to the drmSetCrtc which it aims to replace (take effect directly, and blocking call). This also saves us the trouble of having to set up a poll to wait for pageflip, which would've been neccesary with DRM_MODE_PAGE_FLIP_EVENT, in both crtc_setup_atomic and crtc_release_atomic.
* drm/atomic: disable video plane when unused.LongChair2018-05-011-0/+28
| | | | | | | | | | This patch will make sure that the video plane is hidden when unused. When using high resolution modes, typically UHD, and embedding mpv, having the video plane sitting in the back when you don't play any video is eating a lot of memory bandwidth for compositing. That patch makes sure that the video layer is just disabled before and after playback.
* drm/atomic: add atomic modesetting.LongChair2018-05-011-11/+104
| | | | | | | This commit allows to add atomic modesetting when using the atomic renderer. This is actually needed when using and osd with a smaller size than screen resolution. It will also make the drm atomic path more consistent
* drm/atomic: refactor planes namesLongChair2018-05-018-55/+103
| | | | | | | | We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video. This commit is doing two things : - replace the primary / overlay planes members with osd and video planes member without the assumption - Add two more options to determine which one of the primary / overlay is associated to osd / video. - It will default osd to overlay and video to primary if unspecified
* drm/atomic: add connector to atomic contextLongChair2018-05-016-4/+38
| | | | | | | | | | This patch adds - DRM connector object to atomic context. - fd property to the drm atomic object as well as a method to read blob type properties. This allows to ensure that the proper connector is picked up, especially when specifying it from the commandline, and also allows to make sure we're using the right one when embedding with interop into an application.
* drm/atomic: refactor hwdec_drmprime_drm with native resourcesLongChair2018-05-018-35/+113
| | | | | | | | | | | | | | | | | That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
* vo_gpu/video: disable compute shaders if an FBO format was not availableJan Ekström2018-05-011-0/+5
| | | | | This is actually more generic and better than just lazily plastering peak calculation together with dumb mode.
* vo_gpu/video: add improved logging when a user-specified FBO failsJan Ekström2018-05-011-2/+13
| | | | | I don't know if we can just return from this function, so for now just adding this piece of logging.
* manpage: remove 4 previously removed optionswm42018-05-011-24/+0
| | | | The manpage parts were forgotten when removing the options.
* manpage: --demuxer-seekable-cache is not experimental anymorewm42018-05-011-2/+1
| | | | | This seems to work surprisingly well, and it's enabled by default (unlike the old text claims).
* common: add missing %f time formatwm42018-05-011-0/+1
| | | | | | | | It was documented for --screenshot-template, but apparently never implemented. This value is not explicitly rounded, other than for printf() %f default formatting (which rounds to 6 digits).
* common: round all integer times to millisecondswm42018-05-011-2/+6
| | | | | | | | | This means that a time of 4.5678 is displayed as "00:00:04.568" when the format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as "00:01:00.000". Before this change, the sub-ms times were just truncated. Requested by TheAMM.
* cocoa: change deprecation warning from opengl-cb to libmpvAkemi2018-04-292-3/+3
|
* build: bump wayland-protocols requirement to 1.12+Jan Ekström2018-04-291-1/+1
| | | | The stable xdg-shell protocol is only available from this version.
* wayland_common: update to stable xdg-shellEmmanuel Gil Peyrot2018-04-293-52/+52
| | | | | This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
* gpu/video: make HDR peak computing work without work group countNiklas Haas2018-04-291-4/+5
| | | | | | | | | | Define a hard-coded value for gl_NumWorkGroups if it is not available. This adds an additional requirement of needing a shader recompile for all window size changes. This was considered a worthwhile compromise as currently f.ex. d3d11 completely lacked any peak computation - this is a major quality of life upgrade.
* gpu/video: improve HDR peak computation feature check loggingJan Ekström2018-04-291-1/+4
| | | | | Now that the feature depends on multiple features, log all of their states in the message.
* command: change cycle-value command behaviorwm42018-04-294-87/+97
| | | | | | | | | | | | | | | | | | | | Instead of using an internal counter to keep track of the value that was set last, attempt to find the current value of the property/option in the value list, and then set the next value in the list. There are some potential problems. If a property refuses to accept a specific value, the cycle-values command will fail, and start from the same position again. It can't know that it's supposed to skip the next value. The same can happen to properties which behave "strangely", such as the "aspect" property, which will return the current aspect if you write "-1" to it. As a consequence, cycle-values can appear to get "stuck". I still think the new behavior is what users expect more, and which is generally more useful. We won't restore the ability to get the old behavior, unless we decide to revert this commit entirely. Fixes #5772, and hopefully other complaints.
* command: make track properties cycle through no/auto if uninitializedwm42018-04-291-9/+18
| | | | | | | | | | | | | If playback has not been initialized yet (decoders not initialized etc.), or if in idle mode, let the track properties cycle through "no" and "auto". This should be slightly more helpful than making it simply exit. Depending on the stage of loading, more could be done. For example, if youtube-dl loads additional subtitle files, it can happen that these get added before the main file, and this could be cycled through to an extent. This is probably too clever, and also sort of dangerous (unintended interactions with messy in-loading state), so don't do it.
* command: fix coding stylewm42018-04-291-5/+6
| | | | Add {...}, change if(!a) to if(a) and swap its if/else body.
* vd_lavc: enable dr by defaultwm42018-04-292-7/+5
| | | | | I had this enabled for quite a while and experienced no issues. I'm not aware of other issues either.
* vf_vapoursynth: correctly signal error on script init failurewm42018-04-291-0/+1
| | | | Otherwise it will do nothing, waiting on nothing forever.
* f_lavfi: support setting common filter options like "threads"wm42018-04-293-3/+12
| | | | | | | | | AVFilterContext instances support some additional AVOptions over the actual filter. This includes useful options like "threads". We didn't support setting those for the "direct" wrapper (--vf=yadif:threads=1 failed). Change this. It requires setting options on the AVFilterContext directly, except the code for positional parameters still needs to access the actual filter's AVOptions.
* client API: some doxygen clarificationswm42018-04-291-0/+11
| | | | | | | Strictly speaking redundant, but probably helpful. In particular I want to push MPV_RENDER_PARAM_ADVANCED_CONTROL. Not enabling this parameter is actually not very sane.
* egl_helpers: change minimum framebuffer size to 8 bit per componentwm42018-04-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is for working around bugs in certain Android devices. At least one device fails to sort EGLConfigs by size, so eglChooseConfig() ends up choosing a config with 5/6/5 bits per r/g/b component. The other attributes in the affected EGLConfigs did not look like they should affect the sorting process as specified by the EGL 1.4 standard. The device was reported as: Sony Xperia Z3 Tablet Compact Firmware 6.0.1 build number 23.5.A.1.291 GL_VERSION='OpenGL ES 3.0 V@140.0 AU@ (GIT@I741a3d36ca)' GL_VENDOR='Qualcomm' GL_RENDERER='Adreno (TM) 330' Other Qualcom/Adreno devices have been reported as unaffected by this (including some with same GL_RENDERER string). "Fix" this by always requiring at least 8 bit. This means it would fail on devices which cannot provide this. We're fine with this. mpv-android/mpv-android#112
* encode: do not clear video PTS on VOCTRL_RESETwm42018-04-291-8/+0
| | | | | | | | | | | | | | This was supposed to be a replacement for encode_lavc_discontinuity() (so we don't need to store last_video_in_pts in a way which requires synchronization). Unfortunately, VOCTRL_RESET is also called before termination, and even though it shouldn't matter as far as the VO API is concerned, it does. It's because vo_lavc.c buffers a frame to compute the frame duration. Drop this code. The consequence is that it appears to encode 2 frames with the same PTS if multiple files are encoded into one. Before this, it merely dropped a frame (maybe the first of every subsequent file, not sure).
* egl_helpers: log certain EGL attributeswm42018-04-291-0/+38
| | | | Might be helpful with broken EGL implementations.
* player: don't wait for last video frame in encode modewm42018-04-291-0/+3
| | | | | This code makes the player wait using real time, which makes sense for normal playback, but not encode mode.
* TOOLS/matroska.py: ignore some unused elementswm42018-04-291-1/+3
| | | | So that demux_mkv doesn't log them as unknown.