summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* player: add experimental C plugin interfacewm42017-01-124-1/+110
| | | | | | | | | | | | | | | | | This basically reuses the scripting infrastructure. Note that this needs to be explicitly enabled at compilation. For one, enabling export for certain symbols from an executable seems to be quite toolchain-specific. It might not work outside of Linux and cause random problems within Linux. If C plugins actually become commonly used and this approach is starting to turn out as a problem, we can build mpv CLI as a wrapper for libmpv, which would remove the requirement that plugins pick up host symbols. I'm being lazy, so implementation/documentation are parked in existing files, even if that stuff doesn't necessarily belong there. Sue me, or better send patches.
* client API: fix freeze when destroying mpv_handle before mpv_initializewm42017-01-121-1/+7
| | | | | | | | | We have to perform some silly acrobatics to make the playback_thread() exit, as the mpv_command() will error out with MPV_ERROR_UNINITIALIZED. Test case: mpv_terminate_destroy(mpv_create()) Reported by a user on IRC.
* vaapi: fix typowm42017-01-121-1/+1
|
* mp_image_pool: fix build on Libavwm42017-01-121-0/+1
| | | | | Mismatches between header file symbol visibility in FFmpeg and Libav. Again.
* vo_opengl: hwdec_vaegl: add experimental P010 supportwm42017-01-121-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | This does not work, because Mesa has no support for the proposed DRM_FORMAT_R16 and DRM_FORMAT_GR16 formats. It's also untested of course. As long as video/decode/vaapi.c doesn't hand down P010 surfaces, this is fine anyway. This can be tested by removing the code that disables P010 output: diff --git a/video/decode/vaapi.c b/video/decode/vaapi.c --- a/video/decode/vaapi.c +++ b/video/decode/vaapi.c @@ -55,13 +55,6 @@ static int init_decoder(struct lavc_ctx *ctx, int w, int h) assert(!ctx->avctx->hw_frames_ctx); - // If we use direct rendering, disallow 10 bit - it's probably not - // implemented yet, and our downstream components can't deal with it. - if (!p->own_ctx && required_sw_format != AV_PIX_FMT_NV12) { - MP_WARN(ctx, "10 bit surfaces are currently supported.\n"); - return -1; - } -
* vaapi: explicitly reject 10 bit surfaces outside of copy modewm42017-01-121-0/+7
| | | | | | | | Rendering support in Mesa probably doesn't exist yet. In theory it might be possible to use VPP to convert the surfaces to 8 bit (like we do it with dxva2/d3d11va as ANGLE doesn't support rendering 10 bit surface either), but that too would require explicit mechanisms. This can't be implemented either until I have a GPU with actual support.
* vaapi: handle image copying for vaapi-copy in common codewm42017-01-123-13/+16
| | | | | | | | | | | | | | Other hwdecs will also be able to use this (as soon as they are switched to use AVHWFramesContext). As an additional feature, failing to copy back the frame counts as hardware decoding failure and can trigger fallback. This can be done easily now, because it needs no way to communicate this from the hwaccel glue code to the common code. The old code is still required for the old decode API, until we either drop or rewrite it. vo_vaapi.c's OSD code (fuck...) also uses these surface functions to a higher degree.
* cuda: use libavutil functions for copying hw surfaces to memorywm42017-01-122-73/+10
| | | | | | | | mp_image_hw_download() is a libavutil wrapper added in the previous commit. We drop our own code completely, as everything is provided by libavutil and our helper wrapper. This breaks the screenshot code, so that has to be adjusted as well.
* vaapi: use libavutil functions for copying hw surfaces to memorywm42017-01-123-22/+66
| | | | | | | | | Makes va_surface_download() call mp_image_hw_download() for libavutil-allocated surfaces, which in turn calls av_hwframe_transfer_data(). mp_image_hw_download() is actually not specific to vaapi, and can be used for any hw surface allocated by libavutil.
* vd_lavc, mp_image: remove code duplication for AVFrame<->mp_imagewm42017-01-122-27/+19
| | | | | | | | | Mostly affects conversion of the colorimetric parameters. Not changing AV_FRAME_DATA_MASTERING_DISPLAY_METADATA handling - that's too messy, as decoders typically output it for keyframes only, and would require weird caching that can't even be done on the level of the frame rewrapping functions.
* vaapi: properly set hw_subfmt field with new decode APIwm42017-01-123-7/+12
| | | | | | | | This fixes direct rendering with hwdec_vaegl.c. The code duplication between update_image_params() and mp_image_copy_fields_from_av_frame() is quite annoying, bit will have to be resolved in another commit.
* vaapi: set our own context in AVHWFramesContext not AVHWDeviceContextwm42017-01-122-7/+7
| | | | | | AVHWDeviceContext.user_opaque is reserved to libavutil under certain circumstances, while AVHWFramesContext.user_opaque is truly free for use by us. It's slightly simpler too.
* wscript: slightly simplify configure check for new vaapi decode APIwm42017-01-121-10/+3
| | | | | We can drop the weird acrobatics with the is_ffmpeg. We can distinguish them directly within the vaapi check, duh.
* vaapi: turn all mpv users into a living experimentwm42017-01-111-2/+2
| | | | | | | | | | | Dummy out the locking around all libva calls, which in theory shouldn't be needed anyway. Two years ago, these were added to prevent crashes with vaapi decoding and direct rendering (vo_opengl/vo_vaapi) active. It's not clear whether these are really needed - theory strongly points towards no. Some developers familiar with vaapi expressed similar thoughts. But past experience says differently. So let's try without the locking for a while and see what happens.
* vaapi: add missing config.h includewm42017-01-111-0/+2
| | | | | | | | | A recent commit added code that checks some HAVE_ symbols in this file. No config.h include was added, so they could be unavailable and break compilation (in practice, just --hwdec=vaapi-copy would break). Not sure how I missed this, maybe waf defined these symbols on the compiler command line for some reason.
* vaapi: support new libavcodec vaapi APIwm42017-01-115-2/+266
| | | | | | | | | | | | | | | | | The old API is deprecated, and libavcodec prints a warning at runtime. The new API is a bit nicer and does many things for you, such as managing the underlying hwaccel decoder. libavutil also provides code for managing surfaces (we use their surface pool). The new code does not contain any code from the original MPlayer VAAPI patch (that was used as base for some of the vaapi code in mpv). Thus the new code is LGPL. The new API actually does not add any visible symbols, so the only way to detect it is a version check. Of course, the versions overlap between FFmpeg and Libav, which requires additional care. The new API did not get merged into FFmpeg yet, so there's no check for FFmpeg.
* vaapi: add hacks to support vaapi surfaces created by libavutilwm42017-01-111-20/+45
| | | | | | | | | | | We usually attach some significant metadata and context to "our" surfaces. Surfaces created by libavutil (such as we plan to do it when using the new vaapi decode API in the following commit) don't have this context, so e.g. copy decoding mode won't work. Add tons of hacks to make this somehow work. Eventually we will use libavutil's mechanisms and drop the hacks.
* vaapi: move standalone display creation code to common codewm42017-01-113-136/+129
| | | | Preparation for the following commits.
* vaapi: rename vaapi.c to vaapi_old.cwm42017-01-112-1/+1
| | | | | vaapi.c will be reintroduced with the new code using the new libavcodec vaapi API.
* video: share hwdec extra surface count between backendswm42017-01-113-2/+9
| | | | It's a quite important and fragile magic number.
* cocoa: don't change Space on quit in fullscreenAkemi2017-01-111-6/+10
| | | | | | | circumvent undefined behavior when quitting in fullscreen. Fixes #3957
* cocoa: rate limit video outputAkemi2017-01-111-14/+51
| | | | | | | | | | | | the display refresh rate can't be estimated correctly in some cases and just increases till it turns off display-resample. cases are off-screen rendering (different space), mpv being completely hidden behind another window or the mission control view. this utilise the unused displaylink callback to limit the refresh rate to the actual display refresh rate.
* cocoa: add border cyclingAkemi2017-01-113-0/+45
| | | | Fixes #2430
* cocoa: fix handling of geometry optionAkemi2017-01-111-7/+27
| | | | | | | | | | | | | | This flips the y-coordinate to be consistent with other platforms and the manual. furthermore it fixes an unwanted behaviour of the cocoa convertRectFromBacking method, where the x- and y-coordinate was divided by the same factor as the width and height instead of placing the new scaled rectangle at the same relative position as the original unscaled rectangle, by manually calculating the new position. Fixes #3867
* audio: restructure decode loopwm42017-01-114-57/+85
| | | | | | | Same deal as with video. Including the EOF handling. (It would be nice if this code were not duplicated, but right now we're not even close to unifying the audio and video code paths.)
* vd_lavc: inline a functionwm42017-01-111-45/+37
| | | | | There's only 1 caller now, so having it as separate function doesn't make too much sense, and makes the code less readable, if anything.
* video: make decoder EOF reporting explicitwm42017-01-113-51/+38
| | | | | | | | | | | | | | | This is simpler and more robust, especially for the hwdec fallback case. The most annoying issue is that C doesn't support multiple return values (or sum types), so the decode call gets all awkward. The hwdec fallback case does not need to try to produce some output after the fallback anymore. Instead, it can use the normal "replay" code path. We invert the "eof" bool that vd_lavc.c used internally. The receive_frame decoder API returns the inverse of EOF, because returning "true" from the decode function if EOF was reached feels awkward.
* vd_lavc: fix some leaks and a discarded frame on hwdec fallbackwm42017-01-111-1/+6
| | | | Wasn't a problem in most normal scenarios.
* vd_lavc: move end-of-probing code out of user notification if conditionwm42017-01-111-1/+3
| | | | | | Usually they happen at the same time, but conflating them is still a bit unclean and could possibly cause problems in the future. It's also really unnecessary.
* vd_lavc: return proper error codes from get_buffer2 callbackwm42017-01-111-2/+2
| | | | -1 is essentially random and usually the same as AVERROR(EPERM).
* vd_lavc: complicated improved fallback behavior for --hwdec=cudawm42017-01-102-16/+65
| | | | | | | | | | | | | The ffmpeg cuda wrappers need more than 1 packet for determining whether hw decoding will work. So do something complicated and keep up to 32 packets when trying to do hw decoding, and replay the packets on the software decoder if it doesn't work. This code was written in a delirious state, testing for regressions and determining whether this is worth the trouble will follow later. All mpv git users are alpha testers as of this moment. Fixes #3914.
* video: restructure decode loopwm42017-01-104-95/+138
| | | | Basically change everything. Why does the code get larger? No idea.
* player: change aspects of cover art handlingwm42017-01-105-24/+40
| | | | | | | | | | | | | | | | | | | | | | | | Cover art handling is a disgusting hack that causes a mess in all components. And this will stay this way. This is the Xth time I've changed cover art handling, and that will probably also continue. But change the code such that cover art is injected into the demux packet stream, instead of having an explicit special case it in the decoder glue code. (This is somewhat more similar to the cover art hack in libavformat.) To avoid that the over art picture is decoded again on each seek, we need some additional "caching" in player/video.c. Decoding it after each seek would work as well, but since cover art pictures can be pretty huge, it's probably ok to invest some lines of code into caching it. One weird thing is that the cover art packet will remain queued after seeks, but that is probably not an issue. In exchange, we can drop the dec_video.c code, which is pretty convenient for one of the following commits. This code duplicates a bunch of lower-level decode calls and does icky messing with this weird state stuff, so I'm glad it goes away.
* demux: rename a functionwm42017-01-101-3/+7
| | | | Also extend the comment on it.
* demux: uninline ds_get_packets()wm42017-01-101-27/+22
| | | | | | It has only 1 caller, and is too far appart within the file. I think it used to have multiple callers, but now it just doesn't make any sense to keep it separate anymore.
* vo_drm: remove 2 redundant include statementswm42017-01-091-2/+0
| | | | They're already pulled in by drm_common.h.
* drm: include <poll.h> instead of <sys/poll.h>wm42017-01-093-3/+3
| | | | | | | I'm not sure what systems have <sys/poll.h> (maybe there are historical reasons why some would), but POSIX defines <poll.h>. Although this code is full of highly OS specific calls (like ioctl()), there's no reason not to use the more standard include path.
* command: remove worthless error handling codewm42017-01-091-6/+5
| | | | | | The property calls will always succeed anyway. On the other hand, the error handling is kind of incomplete (doesn't check setting ab-loop-a when ab-loop-b is also set), so drop this code.
* client API: handle missing MPV_FORMAT_BYTE_ARRAY case in compare_valuewm42017-01-091-0/+6
| | | | | | Since there's no property yet that uses this type, and the code is used for property change detection only. this is dead code. Add it anyway for completeness.
* demux_mkv: ebml: turn an int shift into int64wm42017-01-091-1/+1
| | | | | | | | | This was probably the intention all along. But I honestly have no idea what this code even does. Due to what ebml_read_vlen_int() is used for, this is unlikely to have mattered anyway as it rarely/never reads huge values. Which is probably why this has worked for over a decade.
* audio/out/push: merge if branches with same conditionwm42017-01-091-4/+3
| | | | Cosmetic change.
* cache: remove redundant free()wm42017-01-091-3/+1
| | | | | | This code used to check/free multiple things, so the argument to free() was not always NULL. After the code was simplified, the free() became redundant.
* audio: stop being dumbwm42017-01-081-1/+1
| | | | | | | | | | | | | | | | | Obvious mistake: we entered EOF drain mode if the decoder returned AD_WAIT, which is very wrong. AD_WAIT means we should retry after waiting for a while (or to be precise, until the demuxer/decoder have more data). We should just pass down this status, and not change the audio chain state. This was exposed by a libavfilter EOF handling bug. Feeding a filter chain with af_dynaudnorm, and sending an EOF before a frame is returned makes it stuck and keeps returning EAGAIN, instead of returning the buffered audio. In combination with the bug at hand, which entered EOG drain mode, it could happen that it got stuck due to libavfilter discarding buffered data each time the demuxer ran out of data. Fixes #3997.
* vo_opengl: replace 2 memsetswm42017-01-081-2/+2
| | | | Cosmetic change.
* client API: correct a comment in the API doxygenwm42017-01-081-2/+1
|
* vaapi: set libva message callbackswm42017-01-081-0/+61
| | | | | | | | | | | This is available since the first commit after libva 0.39.4. Since the version wasn't bumped since, we just check some random other symbol that was added since (I'd rather not add a configure check). The libva message callback repeats the endlessly repeated API mistakes of libraries using global message callback handlers. But it's the only way to shut up libva's dumb messages to stderr, so add something complicated and dumb to workaround libva's stupidity.
* ta: remove TA_FREEP NULL checkwm42017-01-081-1/+1
| | | | | | | | | | | The NULL check triggers a gcc warning when passing the address of a variable to it. I was about to silence the warning with some equivalent code (that just happens to shut up gcc), but then I decided to remove the NULL check as I don't see a reason why we should allow this. We don't use it in the existing code anyway (all callers do something like TA_FREEP(&structptr->member), which is always non-NULL). Also fix some of the macro argument "quoting".
* vaapi: rearrange va_initialize() internals and fix double-free on errorwm42017-01-081-17/+13
| | | | | | | | Just some minor refactoring within va_initialize() as preparation for the next commit. Also, do not call vaTerminate(display) on failures. All callers already do this, so this would have led to a double-free.
* build: always run code generators before compilingStefano Pigozzi2017-01-072-17/+3
|
* context_wayland: do not call vo_wayland_request_frame() upon bufferswapRostislav Pehlivanov2017-01-071-3/+0
| | | | | | | | vo_wayland_wait_events() is going to return when its time to swap the buffers anyway, calling request_frame() before makes no sense. Fixes the constant high CPU usage by the compositor when mpv is paused and the window is in view.
* manpage: document x11probe OpenGL backendwm42017-01-061-0/+3
| | | | Fixes #3994.
* waf: don't discard line endings when using file2string.pywm42017-01-051-1/+1
|
* TOOLS/file2string.py: fix standalone invocationwm42017-01-051-1/+1
|
* build: use matroska.py & file2string.py as python modulesStefano Pigozzi2017-01-056-51/+83
|
* win32: fix for wm_syscommandpavelxdd2017-01-051-1/+1
| | | | | | | | According to MSDN, in WM_SYSCOMMAND messages, the four low-order bits of the wParam parameter are used internally by the system. To obtain the correct result when testing the value of wParam, an application must combine the value 0xFFF0 with the wParam value by using the bitwise AND operator.
* player: remove dysfunctional edition switching OSD codewm42017-01-054-10/+2
| | | | | | | | | | | | | Was intended to show a "nice" message on edition switching. In practice, the message was never visible. The OSD code checks whether a demuxer is loaded, and if not, discards the message - meaning if the OSD code happened to run before the demuxer was fully loaded, no message was shown. This is apparently a regression due to extensions to the OSD and the situations in which it can be used. Remove the broken code since it's too annoying to fix. Instead, a default property message will be shown, which is a bit uglier, but actually not too unuseful.
* client API: fix mpv_set_property() return value before initwm42017-01-041-0/+1
| | | | | | Did not return success as success. Fixes #3988.
* af_lavfi, vf_lavfi: work around recent libavfilter EOF bugwm42017-01-022-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | Looks quite like a bug. If you have a filter chain with only the dynaudnorm filter, and send call av_buffersrc_add_frame(s, NULL), then subsequent av_buffersink_get_frame() calls will return EAGAIN instead of EOF. This was apparently caused by a recent change in FFmpeg. Some other circumstances (which I didn't fully analyze and which is due to the playloop's absurd temporary-EOF behavior on seeks) then led the decoder loop to send data again, but since libavfilter was stuck in the EOF state now, it could never recover. It kept sending new input (due to missing output), until the demuxer refused to return more audio packets. Each time a filter error was printed. Fortunately, it's pretty easy to workaround. We just mark the p->eof flag as we send an EOF frame to libavfilter. The p->eof flag is used only to recover from temporary EOF: it resets the filter if new data is available again. We don't care much about av_buffersink_get_frame() returning a broken EAGAIN state in this situation and essentially ignore it, meaning if we get EAGAIN after sending EOF, we assume effectively that EOF was fully reached.
* Update copyright yearwm42017-01-012-2/+2
| | | | What kind of bullshit forces you to do this every year anyway.
* vo_opengl: egl: handle potential eglChooseConfig failureswm42016-12-311-11/+10
| | | | | | | | | | | | | | | This is actually a pretty important fix. eglChooseConfig() might be the first thing that fails when porobing for desktop GL / ES2 / ES3 support, because EGL_RENDERABLE_TYPE is set values specific to the underlying APIs. Not sure how the hell this worked before. EGL 1.4 implementations certainly could fail the call with EGL_BAD_ATTRIBUTE if EGL_RENDERABLE_TYPE has EGL_OPENGL_ES3_BIT set. It's quite possible that many EGL implementations tolerate invalid EGLConfig values steming from uininitialized EGLConfig values (and eglCreateWindowSurface() even is specified to return EGL_BAD_CONFIG error code for "not valid" EGLConfigs).
* vo_opengl: egl: fix depth size parameterwm42016-12-301-1/+0
| | | | | | This was accidentally flipped from 0 to 1 in a