summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* audio: add support for AV_SAMPLE_FMT_S64*wm42019-09-273-0/+8
| | | | | | | | | | What an idiotic format. It makes no sense, and should have been converted to S32 in the demuxer, rather than plague everyone with another extremely obscure nonsense format. Why doesn't ffmpeg add S24 instead? That's an actually useful format. May cause compilation failure with old FFmpeg or Libav libs, but I don't care.
* context_drm_egl: define EGL_PLATFORM_GBM_MESA, EGL_PLATFORM_GBM_KHR if not ↵Anton Kindestam2019-09-271-0/+8
| | | | | | | in system headers To account for oddball setups where EGL_PLATFORM_GBM_MESA or EGL_PLATFORM_GBM_KHR might not be defined for whatever reason.
* wscript: check tvOS define's value to be nonzeroJan Ekström2019-09-271-1/+4
| | | | | | TARGET_OS_TV seems to always be defined, but set according to the build configuration. This fixes all Apple configurations being mis-identified as tvOS.
* video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.Wessel Dankers2019-09-276-0/+36
|
* ci: remove --enable-zsh-compPhilip Sequeira2019-09-271-2/+1
| | | | | This option no longer exists, as zsh completion is installed unconditionally now.
* zsh completion: move generation to runtime and improvePhilip Sequeira2019-09-275-307/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-273-10/+10
|
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-272-1/+15
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* hwdec_vaapi_gl: add missing compatibility defineswm42019-09-271-0/+6
| | | | | | | | | | | At first, this code used only 1 plane, so the compatibility stuff was sufficient. But then use of planes 1 and 2 was added, without extending the compatibility stuff. I think I've seen a case recently where this broke the build and caused users to apply invalid fixes, but I don't remember where. It's possible that I didn't get all defines that are needed.
* stream_cb: fix a typo in a commentwm42019-09-271-1/+1
|
* ao_pulse: add the newly added mappings for TrueHD/DTS-HD formatsJan Ekström2019-09-271-6/+11
| | | | | Originally DTS-HD was mapped to PA_ENCODING_DTS_IEC61937 which I'm actually not sure if it ever worked.
* vo_gpu: vulkan: add Android contextsfan52019-09-273-0/+99
|
* context_android: move common code to a separate filesfan52019-09-275-52/+153
| | | | | | In preparation for a Vulkan Android context. This also replaces querying for EGL_WIDTH and EGL_HEIGHT with equivalent ANativeWindow calls.
* DOCS: don't lie about the keybind commanddudemanguy2019-09-261-2/+1
| | | | | It turns out you can actually bind keybind to another keybind. Just be careful with all the quotes.
* wscript: detect tvOS and disable posix-spawn usageAman Gupta2019-09-261-1/+5
| | | | | | cc #5331 Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: d3d11: don't reset frame stats after pauseJames Ross-Gowan2019-09-261-9/+0
| | | | | | | | | | | | | | | | | | | | | | I think I was wrong about having to reset the stats when mpv stops producing frames, eg. when it's paused. As long as the swapchain doesn't underflow, last_queue_display_time will still be accurate, because the next frame produced should still be presented one vsync after the last one in the swapchain. If the swapchain underflows (which is the common case for when mpv is paused for more than 150ms,) the next predicted frame time should be in the past. It should be fine to leave last_queue_display_time unset in this case, since vo.c will use the current time instead, which is a decent guess (though it doesn't take vsync phase into account.) last_sync_refresh_count and last_sync_qpc_time should be kept on swapchain underflow as well. Assuming the display refresh rate doesn't change while mpv is paused, they'll only provide a more accurate guess of the vsync duration when mpv starts playing again. Also, vsync_duration_qpc never needs to get reset. It will get overwritten immediately in most cases, and when it doesn't, it's still a better guess of the vsync duration than nothing.
* player: document FFmpeg ABI rules we intentionally violatewm42019-09-261-0/+2
| | | | | | | | | | That's just a single one. It used to be more, when FFmpeg still required using pointless accessors for tons of fields, which historically broke compatibility with Libav. (I think I wrote the patch to deprecate that crap and to allow direct access myself.) There may be more exceptions, but I forgot about them. Another point is that we don't really trust FFmpeg ABI stability, though.
* audio: make playback end with --end and --audio-spdifwm42019-09-261-0/+3
| | | | | | | | | | | | | In spdif mode, there are hacks that try to cut audio on frame boundaries (blame spdif, which is a hack in itself). The "alignment" is used in a bunch of places, but --end does not respect it. This leads to some audio that can't be pushed because the alignment is off (I don't know why, not do I care), which puts audio into an underrun state forever. Fix this by discarding unusable extra samples if no new data can be expected. Fixes: #6935
* DOCS/contribute.md: talk about non-standard and C11 language featureswm42019-09-261-3/+4
| | | | | | | | | | | The C11 situation is complicated. For example, MinGW doesn't seem to have a full C11 implementation, but we pretty much rely on C11 atomics. Regarding "#pragma once": they say it's not standard because of unsolved (admittedly valid) issues. Btu still, fuck writing include guards, I just can't be bothered with this crap. (Does anyone even read this document?)
* client API: be explicit about usage rules and deadlocks some morewm42019-09-262-0/+9
| | | | | | | I think a popular libmpv application did exactly this: enabling advanced control, and then receiving deadlocks. I didn't confirm it, though. In any case, the API docs should avoid tricking users into making this easy mistake.
* client API: fix potential deadlock problems by throwing more shit at itwm42019-09-267-32/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not).
* command: fix bitrate rounding errorStefan Pöschel2019-09-261-2/+2
| | | | | | | | | | | | | When the (float) bitrate is returned, it is implicitely converted to an int64 value, merely discarding the fractional part. However the bitrate of a CBR track can vary a bit due to timestamp precision loss after clock conversion (this can affect MPEG-TS audio tracks). So a bitrate like 191999.999... results in 191999 when being returned - instead of 192000. To fix this, apply proper rounding, as already done for the "old" case. Hereby refactoring the "old" case to also use `llrint`.
* cocoa-cb: add support for 10bit opengl renderingder richter2019-09-266-20/+65
| | | | | | | this will request a 16bit half-float framebuffer instead if a 8bit integer framebuffer. Fixes #3613
* sub: make font provider user-selectablewm42019-09-254-3/+30
| | | | | | | | | | | | | | | | | | | | libass had an API to configure this since 2013. mpv always used ASS_FONTPROVIDER_AUTODETECT, because usually there's little reason to use anything else. The intention of the now added option is to allow users to disable use of system fonts. I didn't consider it worth the trouble to add the coretext and directwrite enum items from ASS_DefaultFontProvider. The "auto" choice will have the same effect if they're available. Also, the part of the code which defines the option does not necessarily have libass available (it's still optional!), so defining all enum items as choices is icky. I still added fontconfig, since that may be nice to emulate a nostalgic 2010 feeling of mpv freezing on fontconfig. The option for OSD is even less useful. (But you get it for free, and why pass up a chance to add yet another useless option?) This is not quite what was requested in #6947, but as close as it gets.
* drm_common: add missing zero-initialization of struct vt_mode variableAnton Kindestam2019-09-241-1/+1
| | | | | Some fields were being left uninitialized. This could be a problem particularly on non-Linux OS:s with vt_mode (see PR #6976).
* demux: force reading packets again after seekswm42019-09-241-1/+1
| | | | | | | | | | | | | | | | in->eof is used as an indicator whether reading packets still makes sense. (Without this, the prefetcher would obviously burn CPU by retrying reading even though everything has been read.) This was not reset properly after seeks were performed. It led to getting stuck in at least one corner case: when enabling a track, the demuxer would seek backwards to get new packets from the current playback position ("refresh seeks"). But if playback was paused, and EOF was previously reached, it would not try to read packers again due to in->eof being false. There was not anything else that would make it retry reading, so it was stuck in a weird underrun/buffering state. Fixes: #6986
* demux: remove redundant seek range updateGunnar Marten2019-09-241-2/+0
| | | | | This was a leftover from commit b2752321 which fixed #6522 but after the recent demux refactoring this fix is superseded by commit 0f6cda4ab. Remove the redundant update call.
* cocoa-cb: fix title bar button state on start upder richter2019-09-231-0/+2
| | | | | on start up it was possible to click the hidden buttons. hide the buttons ons tart up to make the state consistent with the visible state.
* mac: add Open Playlist menu bar itemAkemi2019-09-231-0/+17
|
* context_drm_egl: Don't get stuck forever if drmHandleEvent failsAnton Kindestam2019-09-221-1/+3
|
* demux_lavf: fix seeking in ogg audio streamswm42019-09-221-0/+3
| | | | | | | | | | | | | | | | | This detected the first packet demuxed after a seek as timestamp discontinuity. Obviously this is non-sense. Since the OGG radio streams for which this feature was introduced are normally unseekable, it's simple to fix this: simply disable it (if in auto mode, the default) as soon as a seek is performed. This code is never called if the stream is considered unseekable, unless the user forced it. There's still a chance this linearization is performed before a seek happens. This will be a bit awkward, but no worse than without this feature, since seeking with timestamp resets is inherently broken in both mpv and libavformat. Fixes: #6974 Fixes: 27fcd4d
* travis: use macOS 10.14 image with xcode 11 instead of xcode 10.2der richter2019-09-221-1/+1
|
* build: optimise adding additional objects for linkingder richter2019-09-222-6/+6
| | | | | splitting the string by spaces isn't the best idea, so we use a proper list instead now.
* osxbundle: remove rpath definitions towards dev toolsder richter2019-09-221-1/+22
| | | | | | | | since the loading order of rpaths is system wide lib path, dev tool path and then bundle lib path it's possible for the xcode swift libs to be incompatible with the libs the bundle was build with. this leads to possible segfaults. if we distribute the bundle we don't want to load the libs from the dev tools anyway.
* build: fix swift linking with upcoming xcode 11der richter2019-09-222-0/+9
| | | | | | | in xcode 11 the dynamic swift libraries were moved to a separated versioned swift folder, which can't be used for linking and only for distribution. additional to the std dynamic swift lib folder the system wide folder is needed for linking too.
* draw_bmp: Fix for GBRP formats GBRP9 and upAnton Kindestam2019-09-221-5/+10
| | | | | | | | | | | | | | | | | | | First we shift the values up to the actual amount of bits in draw_ass, so that they will be drawn correctly when using formats with more than 8 bpc. (draw_rgba is already correct w.r.t. RGB formats with 9 or more bpc) Then, in scale_sb_rgba, by setting the amount of bits per channel used for planar RGB formats (formats are always planar at this point in draw_bmp) to be the same as the source from 9 to 16 bpc (in effect all the various GBRP formats) we manage to fit the special case that does not require any conversion in chroma_up and chroma_down when handling these formats (as long as the source itself is a planar format), instead writing directly to the combined dst/src buffer. This in turn works around a bug (incorrect colors) in libswscale when scaling between GBRP formats with 9 or more bpc. Additionally this should be more efficient, since we skip up- and down-conversion and temporary buffers.
* vo_drm: 30bpp supportAnton Kindestam2019-09-223-13/+58
|
* manpage: update requirements for vdpau hwdec useNicolas F2019-09-221-1/+2
| | | | | | | | | | We default to EGL instead of GLX now, which means vdpau only works if we explicitly specify that we want a GLX context, as vdpau lacks interop for EGL. Update the hwdec documentation to reflect this. Concerns #6980.
* vo_gpu: d3d11: add support for presentation feedbackJames Ross-Gowan2019-09-221-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds vsync reporting to the D3D11 backend using the presentation feedback provided by DXGI, which is pretty similar to what's provided by GLX_OML_sync_control in the GLX backend. In DirectX, PresentCount is the SBC, PresentRefreshCount and SyncRefreshCount are kind of like the MSC and SyncQPCTime is the UST. Unlike GLX, the DXGI API makes it possible for PresentCount and SyncQPCTime to refer to different physical vsyncs, in which case PresentRefreshCount and SyncRefreshCount will be different. The code supports this possibility, even though it's not clear whether it can happen when using flip-model presentation. The docs say for flip-model apps, PresentRefreshCount is equal to SyncRefreshCount "when the app presents on every vsync," but on my hardware, they're always equal, even when mpv misses a vsync. They can definitely be different in exclusive fullscreen bitblt mode, though, which mpv doesn't support now, but might support in future. Another difference to GLX is that, at least on my hardware, PresentRefreshCount and SyncRefreshCount always refer to the last physical vsync on which mpv presented a frame, but glxGetSyncValues can apparently return a MSC and UST from the most recent physical vsync, even if mpv didn't present a new frame on it. This might result in different behaviour between the two backends after dropped frames or brief pauses. Also note, the docs for the DXGI presentation feedback APIs are pretty awful, even by Microsoft standards. In particular the docs for DXGI_FRAME_STATISTICS are misleading (PresentCount really is the number of times Present() has been called for that frame, not "the running total count of times that an image was presented to the monitor since the computer booted.") For good documentation, try these: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-flip-model https://docs.microsoft.com/en-us/windows/win32/direct3d9/d3dpresentstats https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmthk/ns-d3dkmthk-_d3dkmt_present_stats (Yeah, the docs for the D3D9Ex and even the kernel-mode version of this structure are better than the DXGI ones. It seems possible that they're all rewordings of the same internal Microsoft docs, but whoever wrote the DXGI one didn't really understand it.)
* command: add expand-path to expand mpv pathsNicolas F2019-09-222-0/+24
| | | | | | | The question came up on how a client would figure out where screenshot-directory saved its screenshots if it contained mpv-specific expansions. This command should remedy the situation by providing a way for the client to ask mpv to do an expansion.
* build: actually detect supported warning optionsAvi Halachmi (:avih)2019-09-221-2/+2
| | | | | | | | | | | | | Previously the options were tested by compiling a test program with the option, and support was "detected" if the compilation didn't fail. However, both gcc and clang only issue a warning on unknown warning option, hence it never failed and all the warn options were detected as supported. Now the tested option is used together with -Werror, which makes it fail if it warns that the warning option is unknown. Fixes clang unknown option warnings -Wno-format-truncation since 4a6b56f .
* command: add sub-start & sub-end propertiesStefano Pigozzi2019-09-228-7/+140
| | | | | These properties contain the current subtitle's start and end times. Can be useful to cut sample audio through the scripting interface.
* wayland: create current_output in wayland_reconfigdudemanguy2019-09-221-5/+6
| | | | | | | | Certain mpv config options require wl->current_output to be created before the video can actually start rendering. Just always create it here if the current_output doesn't exist (the one exception being the --fs option with no --fs-screen flag). Incidentally, this also fixes --fs-screen not working on wayland.
* wscript: Fix test for ffmpeg drmprime supportPhilip Langdale2019-09-221-2/+9
| | | | | | | This test requires libavutil headers but there is no avutil dependency for it to use. So let's add one, and also reorder the ffmpeg tests ahead of the video tests so that the avutil dependency can be used.
* vf_fingerprint: remove extraneous single quote from descriptionJan Ekström2019-09-211-1/+1
| | | | | | This happened to break ZSH completion and seemed to be extraneous. Reported by LaserEyess on IRC.
* test/linked_list: silence nonsense warningswm42019-09-211-6/+12
| | | | | | | | | | ../misc/linked_list.h:71:34: warning: the address of ‘e6’ will always evaluate as ‘true’ [-Waddress] No shit, e6 is on the stack. But the macro argument is also allowed to be NULL. Add some dumb nonsense to shut up the useless warning. (It's probably useful in other contexts though, so don't disable it completely.)
* test: fix cmocka assert_float_equal shadowing warningswm42019-09-213-9/+6
| | | | | | | | | Just use cmocka's function. It takes an epsilon argument, which we now provide directly. There's no assert_double_equal() in cmocka (and the float variant actually forces a conversion to the float type), but fortunately we didn't use it.
* stream_dvb: remove unused variablewm42019-09-211-1/+0
| | | | | | (At first I left this intentionally, because the temporarily disabled stream ctrl code used it, but there's actually no reason to annoy everyone with the warning.)
* waf: fix wayland-scanner deprecation warningdudemanguy2019-09-212-3/+3
| | | | | | Use `private-code` instead of `code` here. Also this bumps up the required wayland-client/wayland-cursor version to 1.15 which is still pretty old anyway.
* audio: fix use-after-free with fuzzed filewm42019-09-211-0/+2
| | | | | | | | | reinit_audio_filters_and_output() can fully shutdown the audio chain on failure. Specifically, it will deallocate mpctx->ao_chain. The value of that field was cached in ao_c. The code after the call did not account that the audio chain can be shutdown, and used the stale ao_c value. Fixes: #6808
* sub/lavc_conv: skip ReadOrder reset when subtitle decoder gets flushedJan Ekström2019-09-211-0/+1
| | | | | | | | | | | During initial testing with US closed captions, ARIB captions, timed text in MP4 or the specific external SRT files I tested with there were no hints that this flag would be needed for seeking to work. Unfortunately, that result seems to have been incorrect. Fixes #6970
* dec_sub: remove unused declarationwm42019-09-211-1/+0
|
* input: add keybind commandDudemanguy9112019-09-214-0/+65
|
* playloop: don't read playback pos from byte streamDudemanguy911