summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-3116-78/+66
| | | | And remove libavutil includes where possible.
* stream_memory: remove trivial ffmpeg dependencywm42019-10-311-3/+1
|
* manpage: document stats page 3wm42019-10-311-0/+3
|
* player: simplify --stream-dump codewm42019-10-311-4/+4
| | | | | Not sure why it was so complicated. It avoided allocation data on the stack and copying it twice, but who cares.
* stream: move stream_read_line to demux_playlist.cwm42019-10-313-72/+72
| | | | | demux_playlist.c is the only remaining user of this. Not sure if it should stay this way, but for now I'll say yes.
* stream: stop accessing buffer internals in stream_read_line()wm42019-10-312-8/+16
| | | | | Getting this out of the way in preparation for reworking stream internals.
* interface-changes: fixup the location of d3d11-output-cspJan Ekström2019-10-301-1/+2
| | | | 0.30.0 is already cut, so +1 it is.
* vo_gpu/opengl: fully initialize FBO when passing it to renderingJan Ekström2019-10-301-2/+4
| | | | | | | Until now, we only properly initialized two values, leaving the rest be garbage. Fixes #7104
* vo_gpu/d3d11: add support for configuring swap chain color spaceJan Ekström2019-10-305-5/+198
| | | | | | | | | | | | | | | | By default utilizes the color space of the desktop on which the swap chain is located. If a specific value is defined, it will be instead be utilized. Enables configuration of the PQ color space (BT.2020 primaries, PQ transfer function) for HDR. Additionally, signals the swap chain color space to the renderer, so that the render looks correct without having to specify target-trc or target-prim manually. Due to all of the APIs being Win10+ only, will only work starting with Windows 10.
* vo_gpu/d3d11: add helpers for getting names for DXGI formats & CSPsJan Ekström2019-10-302-4/+178
| | | | | Additionally, define the few enum values that are currently missing in mingw-w64 headers.
* vo_gpu: add and utilize color space information from ra_fboJan Ekström2019-10-302-8/+40
| | | | | | | | This lets us set primaries, transfer function and the target peak based on what the presenting layer would want us to have. Now that this mechanism is available, warn if the user has overridden values such as primaries or transfer function.
* osc: calculate osc_geo position after aspect correctionJan Janssen2019-10-291-6/+8
| | | Fixes #7098
* vo_caca: Implement VOCTRL_UPDATE_WINDOW_TITLECameron Cawley2019-10-291-2/+4
|
* osc: Unify bottom and topbar codeJan Janssen2019-10-282-181/+33
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* manpage: Update information about default mouse bindingsCameron Cawley2019-10-281-3/+12
|
* vo_sdl: Acknowledge when the mouse enters or leaves the windowCameron Cawley2019-10-281-0/+6
|
* input: Add default bindings for MBTN_BACK and MBTN_FORWARDCameron Cawley2019-10-281-0/+2
|
* vo_sdl: Improve mouse button inputCameron Cawley2019-10-281-6/+28
| | | | SDL_BUTTON_X1 and SDL_BUTTON_X2 are now correctly mapped to MP_MBTN_BACK and MP_MBTN_FORWARD.
* vo_sdl: Support mouse wheel inputCameron Cawley2019-10-281-1/+11
|
* DOCS/release-policy.md: clarify a few detailssfan52019-10-271-3/+7
|
* vo_gpu: log ra_format.storable with the other flagsJames Ross-Gowan2019-10-271-3/+5
| | | | | | This seems to have been missed when the storable flag was added, since all the other flags were logged here. It can be useful to know if an RA format is storable, so log it as well.
* vo_gpu: d3d11: set the ra_format.storable flagJames Ross-Gowan2019-10-271-3/+12
| | | | | This flag was added in e2976e662d92, but it was only set for Vulkan. In D3D11 it can be set from info in D3D11_FEATURE_FORMAT_SUPPORT2.
* vo_gpu: attempt to fix 0bgr formatwm42019-10-261-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | Using e.g. --vf=format=0bgr showed obviously wrong colors with --vo=gpu. The reason is that leading padding wasn't handled correctly. Try to hack fix it. While the code in copy_image() is somewhat reasonable, I can't tell what the fuck is going on with that HOOKED shit. For some reason this HOOKED shit doesn't use copy_image() (???), or uses it incorrectly. It affects debanding. --deband=no works correctly. If it's enabled, the crap in hook_prelude() is needed. I bet there are many more bugs with this. For example, the deband shader will try to deband the alpha channel if the format abgr is used (because the correct component order is only established later). This can be tested by inserting a "color.x = 0;" at the end of the deband shader, and using --vf=format=rgba vs. abgr. I cannot comprehend why it doesn't just store explicitly which components a texture contains, and why it doesn't just read the components always in an uniform way. There's a big chance this fix works only by coincidence. This shouldn't have been so hard either. Time for a complete rewrite?
* mp_image: copy closed captions when copying attributeswm42019-10-251-0/+1
| | | | | | | | | | With hwdec copy modes, mp_image_copy_attributes() is used to transfer metadata other than the image data when copying the image from the hardware surface. It didn't copy the closed caption data. Fix this. This makes closed captions in copy mode work. Fixes: #6376
* mp_image: move buffer ref assigning to a functionwm42019-10-251-7/+10
| | | | | | | Mostly untested, for the next commit. There's another case of this in this file (ref_buffer()), but it's too weird, so ignore it.
* sdl: prevent concurrent use of SDL in different threadswm42019-10-252-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | sdl_gamepad.c and vo_sdl.c both have their own event loops and run in separate threads. They don't know of each other (and shouldn't). Since SDL only has one global event loop (why didn't they fix this in SDL2?), these obviously clash. The actual behavior is relatively subtle, which event being randomly dispatched to either of the threads. This is very regrettable. Very. Work this around. "Fortunately" SDL exposes its global state to some degree. SDL_WasInit() returns whether a "subsystem" was initialized, and you could say the one who initialized it owns it. Both SDL_INIT_VIDEO and SDL_INIT_GAMECONTROLLER implicitly enable SDL_INIT_EVENTS, and the event loop is indeed the resource that cannot be shared. Unfortunately, this is still racy, since SDL_InitSubSystem is a second call, and succeeds if the subsystem is already initialized (increases a refcount I think). But good enough. Blame SDL for everything. (I think I made this commit message too long. Nobody cares even.) Fixes: #7085
* build: make vo_sdl conflict with cocoawm42019-10-251-0/+1
| | | | | | | | | | These are inherently incompatible. As far as I'm aware, SDL must be used from the main thread on OSX. (Technically, this condition is wrong: the problem happens on OSX in general, or more precisely, when SDL uses Cocoa. I didn't find the waf OSX dependency name after 5 second of searching, so I'm just using cocoa, without which mpv is useless on OSX anyway.)
* vo_sdl: put on do not use stampwm42019-10-251-0/+3
| | | | | | | | | It seems some users try to use it (!). This VO was always an experiment, and intended for low power devices. Whether this experiment succeeded or not, it's a rather obscure VO. Recently I've seen a regrettable user, who seemed to use this only because mpv was built without x11 support (!). Add this warning, like other fallback VOs have it. (The message was copied from vo_x11.)
* input: disable gamepad code by defaultwm42019-10-253-5/+1
| | | | | | | Enabling this by default probably causes a number of issues, such as breaking vo_sdl, or reacting to various input devices while the window is not focused. It's also pretty obscure, or at least new. Disable it by default.
* f_decoder_wapper: trust frame return over error codewm42019-10-251-5/+5
| | | | | | | | | | | | | | | | | lavc_process() calls the receive/send callbacks, which mirror libavcodec's send/receive API. The receive API in particular can return both a status code and a frame. Normally, libavcodec is pretty explicit that it can't return both a frame and an error. But the receive callback does more stuff in addition (vd_lavc does hardware decoding fallbacks etc.). The previous commit shows an instance where this happened, and where it leaked a frame in this case. For robustness, check whether the frame is set first, i.e. trust it over the status code. Before this, it checked for an EOF status first. Hopefully is of no consequence otherwise. I made this change after testing everything (can someone implement a test suite which tests this exhaustively).
* vd_lavc: fix draining with hwdec copy modeswm42019-10-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | Commit 5d5fdb77e99 changed details of the decoding control flow, and called it a "high-risk" change. It turns out that this broke with with hwdec copy mode, where there is some sort of delay queue (supposedly increases efficiency, but more likely worthless cargo-cult). It simply used the wrong (basically inverted) condition for the draining case. This was the only case that did not work properly. Other tests, including video/audio decoding errors, software decoding fallbacks, etc., seemed to work well. Might still not be exhaustive, as there are so many corner cases. Also change two error code returns. This don't/shouldn't really matter, though the second error code led it to return both a frame and AVERROR_EOF, which is unexpected, and makes lavc_process() leak a frame. But also see next commit. Fixes: 5d5fdb77e99
* vo_gpu: d3d11: prevent wraparound in queued frames calcJames Ross-Gowan2019-10-261-1/+2
| | | | | | | If expected_sync_pc is greater than submit_count, the unsigned subtraction will wraparound, which breaks playback. This bug was found while experimenting with bit-blt model present, but it might be possible to trigger it with the flip model as well, if there was a dropped frame.
* Update VERSIONsfan52019-10-251-1/+1
|
* Merge branch 'release/0.30'sfan52019-10-252-135/+77
|\
| * Release 0.30.0v0.30.0release/0.30sfan52019-10-252-135/+77
| |
| * manpage: fix --script docswm42019-10-251-3/+3
| | | | | | | | | | | | | | | | This doesn't take a ',' separated list. --script is just an alias for --scripts--append. --scripts accepts a list, but uses the mplayer-inherited platform-dependent path separator. Fixes: #5996
| * command: remove some unused property metadatawm42019-10-251-16/+2
| | | | | | | | Also add an OSD entry for the video aspect.
| * options: set correct range for --video-aspect-overridewm42019-10-251-3/+2
| | | | | | | | | | It appears this option didn't have min/max enabled for quite a while (broken while it was still called --aspect).
| * json: write NaN/Infinity float values as stringswm42019-10-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | JSON doesn't support these for some god-awful reason. (JSON would have been so much better if it weren't based on JavaScript, the plague of this world.) We don't really care whether these specific values "round trip", so we might as well write them in a standard-compliant way. Untested. I was too lazy to even run this, but it probably works. See #6691.
| * vo_gpu, options: don't return NaN through APIwm42019-10-256-19/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* | sdl_gamepad: fix typo in function namewm42019-10-251-2/+2
| | | | | | | | As pointed out by LaserEyess on IRC.
* | sdl_gamepad: fix function signaturewm42019-10-251-1/+1
| | | | | | | | This is semantically different in C.
* | vo_drm: allow use of zimgwm42019-10-251-0/+1
| |
* | client API: copy instead of move old value on async pathwm42019-10-251-4/+1
| | | | | | | | | | | | | | | | In theory, it's better to keep the old value, because that's more consistent with the logic of using change timestamps. With the current code, the old value will probably never be used (instead it will fetch a new value on every change), so this shouldn't make a difference in practice.
* | manpage: fix --script docswm42019-10-251-3/+3
| | | | | | | | | | | | | | | | This doesn't take a ',' separated list. --script is just an alias for --scripts--append. --scripts accepts a list, but uses the mplayer-inherited platform-dependent path separator. Fixes: #5996
* | client API: add async path; fix deadlock for vo_libmpv userswm42019-10-251-9/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 065c307e8e7db, I broke everything. It seemed like a nice idea, but it explicitly broke an assumption vo_libmpv were explicitly allowed to make: that observing properties does not lock the core. The commit did just that and locked the core for property updates. This made for example mpv's own OSX backend freeze (it uses vo_libmpv for convenience to make up for Apple's incredibly broken OpenGL shit). I don't want to revert that commit just because vo_libmpv's design is horrible. So instead add an optional asynchronous path, that is only used if vo_libmpv is in use (best idea ever?). Interestingly, this isn't so hard. It adds about 90 lines of code, which are only run on OSX and libmpv users, so I don't have to care about the crashes and weird behavior this might cause. It even worked on the first try except for a quickly fixed memory leak. The code path can be tested anywhere by just turning the uses_vo_libmpv condition into always true. The atomic is out of laziness. Saves some thinking how to get around the locking order.
* | command: remove some unused property metadatawm42019-10-251-16/+2
| | | | | | | | Also add an OSD entry for the video aspect.
* | options: set correct range for --video-aspect-overridewm42019-10-251-3/+2
| | | | | | | | | | It appears this option didn't have min/max enabled for quite a while (broken while it was still called --aspect).
* | json: write NaN/Infinity float values as stringswm42019-10-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | JSON doesn't support these for some god-awful reason. (JSON would have been so much better if it weren't based on JavaScript, the plague of this world.) We don't really care whether these specific values "round trip", so we might as well write them in a standard-compliant way. Untested. I was too lazy to even run this, but it probably works. See #6691.
* | vo_gpu, options: don't return NaN through APIwm42019-10-256-19/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* | client API: avoid lost wakeupswm42019-10-241-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | The commit linked below added temporary unlocking to update_prop(), which is indirectly called by mpv_wait_event(). If an unlock happens, and no property change event is returned, we must re-poll the event queue. Rechecking the state on unlocks is basically a standard requirement for code using condition variables. Untested beyond a simple test. Fixes: 065c307e8e7dbf
* | ad_lavc, vd_lavc: return full error codes to shared decoder loopwm42019-10-244-56/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ad_lavc and vd_lavc use the lavc_process() helper to translate the FFmpeg push/pull API to the internal filter API (which completely mismatch, even though I'm responsible for both, just fucking kill me). This interface was "slightly" too tight. It returned only a bool indicating "progress", which was not enough to handle some cases (see following commit). While we're at it, move all state into a struct. This is only a single bool, but we get the chance to add more if needed. This fixes mpv falling asleep if decoding returns an error during draining. If decoding fails when we already sent EOF, the state machine stopped making progress. This left mpv just sitting around and doing nothing. A test case can be created with: echo $RANDOM >> image.png This makes libavformat read a proper packet plus a packet of garbage. libavcodec will decode a frame, and then return an error code. The lavc_process() wrapper could not deal with this, because there was no way to differentiate between "retry" and "send new packet". Normally, it would send a new packet, so decoding would make progress anyway. If there was "progress", we couldn't just retry, because it'd retry forever. This is made worse by the fact that it tries to decode at least two frames before starting display, meaning it will "sit around and do nothing" before the picture is displayed. Change it so that on error return, "receiving" a frame is retried. This will make it return the EOF, so everything works properly. This is a high-risk change, because all these funny bullshit exceptions for hardware decoding are in the way, and I didn't retest them. For example, if hardware decoding is enabled, it keeps a list of packets, that are fed into the decoder again if hardware decoding fails, and a software fallback is performed. Another case of horrifying accidental complexity. Fixes: #6618
* | client API: simplify (?) property change notification generationwm42019-10-241-75/+79
|/ | | |