aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
...
* vf_lavfi: switch to AVBufferSrcParametersGravatar wm42017-01-16
| | | | | | Instead of using the awful older "API" that passed the parameters formatted as string. AVBufferSrcParameters is also a prerequisite for hardware frame filtering support.
* vo_opengl: hwdec_cuda: add yuv420p supportGravatar wm42017-01-16
| | | | | | | | | Because it allows easier testing of filters + hwdec. Make the texture setup code a bit more generic so it doesn't get too much of a mess. We also use the GL renderer utility function gl_find_unorm_format(), which saves us additional work with OpenGL's semi-redundant format specifiers.
* cuda: fix AVHWFramesContext initializationGravatar wm42017-01-16
| | | | This was partially done. Strangely it worked anyway.
* vo_opengl: hwdec_cuda: export AVHWDeviceContextGravatar wm42017-01-16
| | | | So we can use it for filtering later.
* hwdec: add a AVBufferRef(AVHWDeviceContext) fieldGravatar wm42017-01-16
| | | | This makes "generic" interaction with libav* components easier.
* lua: allow unregistration of idle handlersGravatar Olivier Perret2017-01-15
|
* manpage: define stricter rules for C plugin return valuesGravatar wm42017-01-14
| | | | Just in case.
* scripting: don't call dlclose() on C pluginsGravatar wm42017-01-14
| | | | | | | | Can break things quite badly. Example: reloading a plugin linked against GTK 3.x can cause a segfault if you call dlclose() on it. According to GTK developers, unloading the GTK library is unsupported.
* scripting: minor logging improvementsGravatar wm42017-01-14
| | | | | | | | Give scripting backends a proper name, instead of calling everything "scripts". Log client exit directly in client.c, as that is more general (doesn't change actual output).
* vd_lavc: demote software decoding message to verbose log levelGravatar wm42017-01-13
| | | | | | | | | | | If hardware decoding is enabled (via --hwdec anything), the player was printing an informational message that software decdoing is used. Basically, this confuses users, because they think there is a problem or such. Just disable the message, it's semi-useless anyway. This was suggested on IRC, after yet another user was asking why this message was shown (with a follow up discussion which CPUs can decode what kind of video codecs).
* vf_lavfi: remove pixel format whitelistGravatar wm42017-01-13
| | | | Pointless now.
* vo_opengl: hwdec_vaegl: add a lie for compatibilityGravatar wm42017-01-13
| | | | | | | EGL rendering + new decode API didn't work due to a certain libva bug with sort-of legacy API use hitting again. It will report the wrong vaapi pixel format. It's old code and always nv12 anyway, so stop worrying about it.
* vo_opengl, vaapi: properly probe 10 bit rendering supportGravatar wm42017-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are going to be users who have a Mesa installation which do not support 10 bit, but a GPU which can decode to 10 bit. So it's probably better not to hardcode whether it is supported. Introduce a more general way to signal supported formats from renderer to decoder. Obviously this is imperfect, because it still isn't part of proper format negotation (for example, what if there's a vavpp filter, which accepts anything). Still slightly better than before. I don't know any way to probe for vaapi dmabuf/EGL dmabuf support properly (in particular testing specific formats, not just general availability). So we stay with the current approach and try to create and map dummy surfaces on init to probe for support. Overdo it and check all formats that AVHWFramesConstraints reports, instead of only NV12 and P010 surfaces. Since we can support unknown formats now, add explicitly checks to the EGL/dmabuf mapper code to reject unsupported formats. I also noticed that libavutil signals support for RGB0/BGR0, but couldn't get it to work. Remove the DRM formats that are unused/didn't work the way I tried to use them. With this, 10 bit decoding + rendering should work, provided you have a capable CPU and a patched Mesa. The required Mesa patch adds support for the R16 and GR32 formats. It was sent by a Kodi developer to the Mesa developer mailing list and was not accepted yet.
* vaapi: always create AVHWDeviceContext on initGravatar wm42017-01-13
| | | | | | For convenience. Since we still have code that works even if creating a AVHWDeviceContext fails, failure is ignored. (Although currently, it succeeds creation even with the stale/abandoned vdpau wrapper driver.)
* config: do not resolve default profile during "include" processingGravatar wm42017-01-13
| | | | | | | | | | | | | | | | Application of options in the default section is "delayed" until the whole config file is read in order to allow profile forward references. This was run at the end of parsing a config file - but because of "include" options, this means it's not always called at the end of the main config file. Use the recursion counter to prevent it from being processed after each "include" option. This also gets rid of the resulting unintended infinite recursion (which eventually stopped and failed loading the config file) due to m_config_finish_default_profile() processing the "include" option again. Fixes #4024.
* vo_opengl: hwdec_vaegl: remove redundant vaapi surface format checkGravatar wm42017-01-13
| | | | | | | | | | | | | | | | | For surfaces allocated by libavutil, we assume that the sw_format (i.e. in hw_subfmt in mp_image_params) is always correct. The API guarantees that it explicitly sets the equivalent vaapi format on surface allocation. For surfaces allocated by mpv's old vaapi code, we explicitly retrieve the format right after decoding. Unless the driver magically changes the format asynchronously, it will still be correct once the surface reaches the renderer. In both cases, checking the format again is obviously redundant. In addition, it doesn't require us to maintain a libva fourcc <-> mpfmt table and the va_fourcc_to_imgfmt() function. This also unbreaks 10 bit rendering support (still disabled by default).
* vo_opengl: hwdec_vaegl: fix terminology in commentGravatar wm42017-01-13
| | | | Bad idea to call a component "pixel" - that's true only for the Y plane.
* vo_opengl: hwdec_vaegl: DRM_FORMAT_GR16 was renamed to DRM_FORMAT_GR32Gravatar Mark Thompson2017-01-13
| | | | Signed-off-by: wm4 <wm4@nowhere>
* manpage: fix a typoGravatar wm42017-01-13
|
* player: add experimental C plugin interfaceGravatar wm42017-01-12
| | | | | | | | | | | | | | | | | 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_initializeGravatar wm42017-01-12
| | | | | | | | | 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 typoGravatar wm42017-01-12
|
* mp_image_pool: fix build on LibavGravatar wm42017-01-12
| | | | | Mismatches between header file symbol visibility in FFmpeg and Libav. Again.
* vo_opengl: hwdec_vaegl: add experimental P010 supportGravatar wm42017-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 modeGravatar wm42017-01-12
| | | | | | | | 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 codeGravatar wm42017-01-12
| | | | | | | | | | | | | | 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 memoryGravatar wm42017-01-12
| | | | | | | | 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 memoryGravatar wm42017-01-12
| | | | | | | | | 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_imageGravatar wm42017-01-12
| | | | | | | | | 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 APIGravatar wm42017-01-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 AVHWDeviceContextGravatar wm42017-01-12
| | | | | | 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 APIGravatar wm42017-01-12
| | | | | 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 experimentGravatar wm42017-01-11
| | | | | | | | | | | 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 includeGravatar wm42017-01-11
| | | | | | | | | 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 APIGravatar wm42017-01-11
| | | | | | | | | | | | | | | | | 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 libavutilGravatar wm42017-01-11
| | | | | | | | | | | 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 codeGravatar wm42017-01-11
| | | | Preparation for the following commits.
* vaapi: rename vaapi.c to vaapi_old.cGravatar wm42017-01-11
| | | | | vaapi.c will be reintroduced with the new code using the new libavcodec vaapi API.
* video: share hwdec extra surface count between backendsGravatar wm42017-01-11
| | | | It's a quite important and fragile magic number.
* cocoa: don't change Space on quit in fullscreenGravatar Akemi2017-01-11
| | | | | | | circumvent undefined behavior when quitting in fullscreen. Fixes #3957
* cocoa: rate limit video outputGravatar Akemi2017-01-11
| | | | | | | | | | | | 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 cyclingGravatar Akemi2017-01-11
| | | | Fixes #2430
* cocoa: fix handling of geometry optionGravatar Akemi2017-01-11
| | | | | | | | | | | | | | 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 loopGravatar wm42017-01-11
| | | | | | | 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 functionGravatar wm42017-01-11
| | | | | 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 explicitGravatar wm42017-01-11
| | | | | | | | | | | | | | | 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 fallbackGravatar wm42017-01-11
| | | | Wasn't a problem in most normal scenarios.
* vd_lavc: move end-of-probing code out of user notification if conditionGravatar wm42017-01-11
| | | | | | 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 callbackGravatar wm42017-01-11
| | | | -1 is essentially random and usually the same as AVERROR(EPERM).
* vd_lavc: complicated improved fallback behavior for --hwdec=cudaGravatar wm42017-01-10
| | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 01:11:49 +0000