summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl_cb: fix a race conditionwm42016-10-301-2/+4
| | | | | | | | | | When pthread_cond_timedwait(), the condition we are checking for could be true or false. This code assumed it was always false. This should be an extremely obscure race condition, since it can happen only if timeout and the condition changing sort of happen at the same time, or the lock is held for a longer time (which it normally isn't). But I could observe it a few times.
* vo_opengl_cb: fix inverted conditionwm42016-10-301-1/+1
| | | | Commit e6291697 got this wrong.
* vo_opengl_cb: update current frame if a frame is droppedwm42016-10-301-1/+2
| | | | | | | Even if a frame is dropped due to the libmpv API user not drawing a frame, it should be set as current frame. This avoids dropping a frame forever in certain circumstances such as cover art of the API user was stuck at initialization or such.
* vo_tct: support also 256 colors outputAvi Halachmi (:avih)2016-10-251-9/+55
|
* vo_tct: optional custom size, support non-posix with 80x25 defaultAvi Halachmi (:avih)2016-10-252-7/+31
| | | | Also, replace the UTF8 half block char at the source code with C escape.
* vo_opengl: context_rpi: fix stdatomic usagewm42016-10-211-1/+1
| | | | | | atomic_bool is not supported with e.g. atomic_fetch_and. Fixes #3699. Untested.
* vo_opengl: partially re-enable glFlush() callswm42016-10-211-2/+7
| | | | | | | | | | | | It turns out the glFlush() call really helps in some cases, though only in audio timing mode (where we render, then wait for a while, then display the frame). Add a --opengl-early-flush=auto mode, which does exactly that. It's unclear whether this is fine on OSX (strange things going on there), but it should be. See #3670.
* vo: vo_tct is now available on non-POSIXwm42016-10-201-0/+2
| | | | Fixes Windows build.
* build: don't rely on "__thread" being always available with GCCDmitrij D. Czarkoff2016-10-201-1/+1
| | | | | | | | | | | | | Thread-local storage in GCC is platform-specific, and some platforms that are otherwise perfectly capable of running mpv may lack TLS support in GCC. This change adds a test for GCC variant of TLS and relies on its result instead of assumption. Provided that LLVM's `__thread` support is similar to GCC, the test is called "GCC/LLVM TLS". Signed-off-by: wm4 <wm4@nowhere>
* opengl: compile against iOS OpenGLES implementationAman Gupta2016-10-202-0/+20
|
* vf_vdpaurb: deprecate this filterwm42016-10-201-0/+3
|
* video: add --hwdec=vdpau-copy modewm42016-10-203-1/+77
| | | | | | | At this point, all other hwaccels provide -copy modes, and vdpau is the exception with not having one. Although there is vf_vdpaurb, it's less convenient in certain situations, and exposes some issues with the filter chain code as well.
* vo_tct: introduce modern caca alternativerr-2016-10-202-0/+236
|
* ad_lavc, vd_lavc: fix a recent libavcodec deprecation warningwm42016-10-171-1/+1
| | | | | | | | | | | | | | Both AVFrame.pts and AVFrame.pkt_pts have existed for a long time. Until now, decoders always returned the pts via the pkt_pts field, while the pts field was used for encoding and libavfilter only. Recently, pkt_pts was deprecated, and pts was switched to always carry the pts. This means we have to be careful not to accidentally use the wrong field, depending on the libavcodec version. We have to explicitly check the version numbers. Of course the version numbers are completely idiotic, because idiotically the pkg-config and library names are the same for FFmpeg and Libav, so we have to deal with this explicitly as well.
* vd_lavc: Add hwdec wrapper for crystalhdPhilip Langdale2016-10-152-0/+8
| | | | This hardware decodes to system memory so it only requires a wrapper.
* vo_drm: change CLI options + refactorsrr-2016-10-074-162/+274
| | | | | | | | | | - Change connector selection to accept human readable names (such as eDP-1, HDMI-A-2) rather than arbitrary numbers. - Change GPU selection to accept GPU number rather than device paths. - Merge connector and GPU selection into one --drm-connector. - Add support for --drm-connector=help. - Add support for --drm-* in EGL backend. - Refactor KMS; reduce state sharing across drm_common.
* vo_drm: fix segfault when using invalid cardrr-2016-10-061-2/+2
|
* cocoa: add glFlush() to cocoa backendAkemi2016-10-062-2/+1
| | | | | | | | | | | | The glFlush() call was made optional recently since it's not needed in most cases. On OSX though this is needed since we removed kCGLPFADoubleBuffer from the context creation, so the glFlush() call was added to the cocoa backend only. The CGLFlushDrawable() call can be safely removed since it only does something when a double buffered context is used. Also fixes a small typo. Fixes #3627.
* vo_opengl: apply --opengl-early-flush in dumb mode toowm42016-10-052-1/+1
| | | | | | | | In "dumb mode" (where most features are disabled and which only performs some basic rendering) we explicitly copy a set of whitelisted options, and leave all the other options at their default values. Add the new --opengl-early-flush option to this whitelist. Also remove an option field accidentally added in the commit adding --opengl-early-flush.
* vo_opengl_cb: don't wait for redrawn frameswm42016-10-052-3/+6
| | | | | | | This also removes some extra waiting if no video is active, at least in theory. Also clarify the vo_frame flag comments for redraw/repeat.
* vo_opengl: disable glFlush() by default, and add an option to enable itwm42016-10-052-1/+5
| | | | | | | | | | | It seems this can cause issues with certain platforms, so better to disable it by default. The original reason for this isn't overly justified, and display-sync mode should get rid of the need for it anyway. The new option is meant for testing, and will probably be removed if nobody comes up and reports that enabling the option actually improves anything.
* vo_opengl: hwdec_rpi: fix NULL pointer deref in certain caseswm42016-10-041-1/+3
| | | | | If a client API user provides the MPGetNativeDisplay callback, but returns NULL for "MPV_RPI_WINDOW", this would crash.
* vo_drm: fix tiny memory leakrr-2016-10-041-3/+8
|
* vo_drm: refactor getting display fpsrr-2016-10-044-10/+8
| | | | | | | | Reduces code duplication between OpenGL backend and DRM VO. (The control() for OpenGL backend isn't sufficiently similar to the VO's control() to consider merging it as a whole - I extracted only the FPS code.)
* vaapi: support drm devices when running in vaapi-copy modeBernhard Frauendienst2016-10-021-0/+53
| | | | | | | | | | | | | | | | When the vaapi decoder is used in copy mode, it creates a dummy display to render to. In theory, this should support hardware decoding on on a separate GPU that is not actually connected to any output (like an iGPU which supports more formats than the external GPU to which the monitor is connected). However, before this change, only X11 displays were supported as dummy displays. This caused some graphics drivers (namely intel-driver) to core dump when they were not actually used as X11 module. This change introduces support for drm libav displays, which allows vaapi-copy to run on such cards which are not actually rendering the X11 output.
* vo_opengl: minor simplificationwm42016-10-011-4/+3
| | | | The extra gl_transform_trans() has no apparent use.
* vo_opengl: attempt to fix chroma offset under rotation and flippingwm42016-10-011-15/+48
| | | | | | Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
* vo_opengl: add debugging options for testing with padded textureswm42016-10-012-4/+10
|
* vo_opengl: partially fix dumb-mode cropping with rotationwm42016-09-301-5/+23
| | | | | | | | | | | | Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
* csputils: add note that mp_invert_cmat() is LGPL toowm42016-09-301-1/+1
| | | | | | | | | | | | | | | Commit aa1047a3 originally added this as: + // this is from the DarkPlaces engine, reduces to 3x3. Original code + // released under GPL2 or any later version. According to Rudolf Polzer, the original author (a certain LH) was actually asked whether it would be ok to put this code under LGPL, and the author gave his agreement. This code is not from id Software either (on which large parts of DarkPlaces is based on), which is the main reason why DarkPlaces is under GPL. So this note is just confusing, and always has been LGPL. Fix it.
* vo_opengl: vaegl: log more debugging infoswm42016-09-301-7/+12
|
* vo_opengl: rpi: remove dumb commentwm42016-09-301-1/+0
| | | | It's not even true anymore.
* vo_opengl: rpi: fix glaring memory leakwm42016-09-301-2/+5
| | | | | This was in previously inactive code (uploading yuv420p), so it did not matter.
* vo_opengl: rpi: use overlay for yuv420p toowm42016-09-301-1/+6
| | | | | | | | | | | | | | | | The video code can deal fine with feeding software image formats to hwdec interop drivers. In RPI's case, this is preferable for performance, working around OpenGL bugs (see RPI firmware issue #666), and because OpenGL rendering doesn't bring too many advantages due to RPI supporting GLES 2.0 only. Maybe a way to force the normal video path is needed later. But currently, this can be tested by just not loading the hwdec interop driver. If you run command-line mpv and set --hwdec to something that does not load the RPI interop layer, you'll even have to use --hwdec-preload manually to get it enabled.
* vo_opengl: allow hwdec interops to support multiple image formatswm42016-09-303-2/+17
|
* vo_opengl: egl: print EGL errors only if not probingwm42016-09-301-6/+9
| | | | | Avoids printing an error when trying to create a GLES 3.x context on a device which can do GLES 2.0 only.
* vo_opengl: rpi: raise the video layerwm42016-09-301-3/+8
| | | | | | Was intended to put the GL layer above the standard console. (But actually that was done already, and the oddness I'm seeing seems to be an unrelated bug.)
* vd_lavc: log if hw decoding selects a different underlying decoderwm42016-09-301-0/+3
| | | | | Less confusing to see what's going on. I think there were more than one users who got tricked by this, including myself.
* rpi: add --hwdec=rpi-copywm42016-09-302-0/+7
| | | | | | This means it can be used with normal video filters. Might help out with #3604.
* mp_image: fix clearing to black with p010 formatwm42016-09-291-1/+1
| | | | | Using vf_expand (which uses mp_image_clear()) with p010 cleared chroma to green instead.
* w32_common: implement VOCTRL_GET_DISPLAY_NAMESJames Ross-Gowan2016-09-291-0/+52
| | | | | | | | This should make display-names usable on Windows. It returns a list of GDI monitor names like "\\.\DISPLAY1". Since it may be useful to get the monitor that Windows considers associated with the window (with MonitorFromWindow,) this will always be returned as the first argument. This monitor is the one used for display-fps and icc-profile-auto.
* cuda: initialize hwframes formatPhilip Langdale2016-09-281-0/+4
| | | | | In retrospect, this seems obvious, but ffmpeg didn't complain until a recent update.
* img_format: remove some unneeded format definitionswm42016-09-282-15/+0
| | | | They're still supported, just that they have no IMGFMT_ alias.
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-289-10/+2
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* vo_opengl: deprecate 'drm-egl' backend and introduce 'drm' insteadwm42016-09-272-1/+21
| | | | Just a name change. Requested.
* vo_drm: provide display fpsrr-2016-09-262-2/+27
|
* cocoa: fix fullscreen regression on 10.11 and newerAkemi2016-09-261-1/+0
| | | | Fixes #3364.
* vo_opengl: hwdec_cuda: get the cuda device from the GL contextPhilip Langdale2016-09-241-3/+3
| | | | | | | | | | Obviously, in the vast majority of cases, there's only one device in the system, but doing this means we're more likely to get a usable device in the multi-device case. cuda would support decoding on one device and displaying on another but the peer memory handling is not transparent and I have no way to test it so I can't really write it.
* vo_opengl: hwdec_cuda: directly map GL textures and skip using PBOsPhilip Langdale2016-09-241-65/+20
| | | | | | | | | | | | | | | | | | | The documentation around this stuff is poor, but I found an nvidia sample that demonstrates how to use the interop API most efficiently. (https://github.com/nvpro-samples/gl_cuda_interop_pingpong_st) Key lessons are: 1) you can register the texture itself and have cuda write to it, thereby skipping an additional copy through the PBO. 2) You don't have to be mapped when you do the copy - once you get a mapped pointer, it remains valid. Magic! This lets us throw out the PBOs as well as much of the explicit alignment and stride handling. CPU usage is slightly (~3%) lower for 4K content in one test case, so it makes a detectable difference, and presumably saves memory.
* vo_opengl: hwdec_rpi: remove copy&paste errorwm42016-09-231-1/+0
|
* vo: log framedropswm42016-09-231-1/+3
| | | | Seems useful. (This was possibly added ages ago and then removed.)
* x11: fix external fullscreen updatewm42016-09-232-13/+10
| | | | | | | | | | | | On x11, you can change the fullscreen via the window manager and without mpv's involvement. In these cases, the internal fullscreen flag has to be updated. The hack used for this didn't really work properly. Change it accordingly. The important thing is that the shadow copy of the option is updated. This is still not really ideal. Fixes #3570.
* aspect: use nominal width instead of actual width for video-unscaledNiklas Haas2016-09-221-3/+3
| | | | | | | | The documentation claims that --video-unscaled will still perform anamorphic adjustments, and it rightfully should. The current reality is that it does not, because the video-unscaled size was based on the wrong set of variables. (encoded width/height instead of nominal display width/height)
* vo: add a unique frame_id to vo_framewm42016-09-222-0/+9
| | | | | We think that this allows simpler logic than using the redraw and repeat fields. Not used yet.
* vo_opengl: apply 90° rotation to chroma texture sizewm42016-09-221-0/+3
| | | | | | | | | When we rotate the inmage by 90° or 270°, chroma width and height need to be swapped. Fixes #3568. But is the chroma sub location correct? Who the hell knows...
* cocoa: fix macOS 10.12 deprecation warningsAkemi2016-09-221-3/+3
|
* command: add a video-dec-params propertywm42016-09-202-1/+8
| | | | | | This is the actual decoder output, with no overrides applied. (Maybe video-params shouldn't contain the overrides in the first place, but damage done.)
* video: handle override video parameters in a better placewm42016-09-202-8/+7
| | | | | | | | This really shouldn't be in vd_lavc.c - move it to dec_video.c, where it also applies aspect overrides. This makes all overrides in one place. The previous commit contains some required changes for resetting the image parameters change detection (i.e. it's not done only on video aspect override changes).
* command: change update handling of some video-related propertieswm42016-09-202-2/+2
| | | | | | | | Use the new mechanism, instead of wrapped properties. As usual, extend the update handling to some options that were forgotten/neglected before. Rename video_reset_aspect() to video_reset_params() to make it more "general" (and we can amazingly include write access to video-aspect as well in this).
* options: slightly better option update mechanismwm42016-09-191-0/+1
| | | | | | | | | | | | | | Extend the flag-based notification mechanism that was used via M_OPT_TERM. Make the vo_opengl update mechanism use this (which, btw., also fixes compilation with OpenGL renderers forcibly disabled). While this adds a 3rd mechanism and just seems to further the chaos, I'd rather have a very simple mechanism now, than actually furthering the mess by mixing old and new update mechanisms. In particular, we'll be able to remove quite some property implementations, and replace them with much simpler update handling. The new update mechanism can also more easily refactored once we have a final mechanism that handles everything in an uniform way.
* displayconfig: treat a refresh rate of 1 as invalidJames Ross-Gowan2016-09-181-2/+8
| | | | Found in Windows 8.1/VirtualBox.
* options: simplify M_OPT_EXITwm42016-09-172-3/+3
| | | | | | | | | | | | | There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
* vo_opengl: don't pass negative height to overlay_adjust()wm42016-09-161-1/+1
| | | | | | Negative height is used to signal a flipped framebuffer. There's absolutely no reason to pass this down to overlay_adjust(), and only requires implementers to deal with an additional special-case.
* player: use better way to wait for input and dispatching commandswm42016-09-161-0/+2
| | | | | | | | | | | | | | | | | | | Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-162-6/+16
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* hwdec_cuda: Rename config variable to be more consistentPhilip Langdale2016-09-163-4