summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: x11egl: fix confused error status codeswm42015-10-121-2/+2
| | | | This is all kinds of wonderfully stupid.
* vo_opengl: x11egl: reject nvidia drivers when autoprobingwm42015-10-121-0/+6
| | | | | | | | | Newer nVidia drivers support EGL, but they seem to work badly, apparently don't support some needed features or not in a form we want (such as swap control), and vdpau interop is not available. Disable it by default, because I'm tired of explaining this issue. Can be reverted as soon as nVidia release working drivers.
* vd_lavc: work around libavcodec nonsense causing hwdec init failurewm42015-10-121-0/+3
| | | | | | | | | | | | | | | | The libavcodec h264 decoder contains some idiotic code with unknown purpose (no sample or explanation known that necessitates its existence), that causes the AVCodecContext.get_format callback to be invoked at a time when hwaccels can't be initialized. By definition, the get_format callback is supposed to initialize hwaccels (another idiotic thing now part of the API, but different story). This causes hwdec initialization sometimes to fail (WolfensteinTwitch.mp4): the first get_format callback will mark it as failed, so the second get_format (the "proper" normal one) will not bother restoring the state, and hwdec init fails. While this should be fixed in libavcodec (good luck with that), it's quite easy to workaround.
* vd_lavc: refuse to initialize vaapi with unknown profileswm42015-10-111-3/+1
| | | | | | Bad idea, although I'm not sure how harmful it actually was. Although this is common code, only the vaapi hwaccel still uses it.
* cocoa: set application policy before creating windowwm42015-10-111-5/+4
| | | | | | | | | | | | This fixes a regression since commit f4d62da8. The original code run vo_cocoa_config_window() once without creating the window, which had the effect that the last part of the function was run at least once before the actual window was created. Fix the regression by moving it to before the window is created. The regression itself is hard to describe. One test case: start mpv from a fullscreened terminal window. It should switch to another desktop, with the mpv window visible. This didn't happen anymore.
* vo: log deviation from ideal vsync intervalwm42015-10-081-0/+5
|
* vo_xv: fix crash with --widwm42015-10-071-1/+1
| | | | | | Fixes #2386. Reminder that you should not use this crap-VO.
* video: fix base for --no-correct-ptswm42015-10-062-9/+10
| | | | | | | | | | Use the first encountered packet PTS/DTS as base, instead of the last one. This does not add the amount of frames buffered in the codec to the PTS offset, and thus is better. Also, don't add the frame time if there was no decoded frame yet. The first frame should obviously have the timestamp of the first packet (going by this heuristic).
* video: increase maximum number of buffered AVI pts sampleswm42015-10-061-1/+1
| | | | | | | While b-frame reordering limits the maximum required number to around 16, the number of additionally buffered frames can be much higher. Guess when this actually matters? (For the libavcodec MMAL wrapper.)
* video: don't sort AVI pts sampleswm42015-10-061-14/+10
| | | | | It's obviously not needed, and only an artifact of the old PTS determination code.
* video: remove user-controllable PTS sorting (--pts-association-mode)wm42015-10-062-57/+5
| | | | | | | | | Useless. Sometimes it might be useful to make some extremely broken files work, but on the other hand --no-correct-pts is sufficient for these cases. While we still need some of the code for AVI, the "auto" mode in particular inflated the size of the code.
* video: disable framedrop if avi-style timestamps are usedwm42015-10-061-0/+3
| | | | | | | | | | | | This can't be handled correctly at all. Other cases when the decoder might drop a frame (such as completely failing to decode a frame) will shift timestamps by a frame, and it can't be avoided. While we could maybe find a better way to handle this with libavcodec's main decoders, this seems to be much harder if it should work with certain HW decoders, which don't passthrough the DTS field (such as MMAL). Another problem are .avi files with b-frames. So just leave it as it is.
* video: remove codec delay estimationwm42015-10-033-15/+2
| | | | | | | | | | This was used only by the timestamp sorting code, which is a fallback for avi files (as well as avi-muxed mkv files). This was supposed to prevent accumulating timestamps in case the decoder consumes more packets than it outputs frames (i.e. frames are dropped). This didn't work very well (timestamps could be off by a large amount), the estimation of the delay was fragile, and the interdependencies with the decoder were annoying, so kill it.
* video: cosmetics: remove trailing whitespacewm42015-10-031-1/+1
|
* video/out: remove an unused parameterwm42015-10-0325-43/+40
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* vo: change some defines to enumswm42015-10-021-9/+13
| | | | Why not.
* vo_opengl: drop old backend APIwm42015-10-023-87/+26
|
* vo_opengl: rpi: switch to new internal APIwm42015-10-023-39/+35
|
* win32: cleanup: remove some unneeded thingswm42015-10-024-17/+10
|
* vo_opengl: w32: switch to new internal APIwm42015-10-024-27/+36
|
* vo_opengl: refactor DwmFlush crapwm42015-10-023-42/+45
| | | | | Get it out of the way in the common code. MPGLContext.dwm_flush_opt can be removed as well as soon as the option system gets overhauled.
* vo_opengl: remove leftover variable from vaglx in vaeglEmmanuel Gil Peyrot2015-10-021-1/+0
| | | | This was preventing compilation on systems without X11 headers.
* vo: fix compilation failure when vaapi is enabled and x11 disabledEmmanuel Gil Peyrot2015-10-021-1/+1
| | | | | This was previously trying to use the video_output_vaapi symbol despite vo_vaapi.c being guarded by the vaapi-x11 option.
* vo_opengl: wayland: switch to new internal APIwm42015-10-016-54/+44
|
* vo_opengl: cocoa: switch to new internal APIwm42015-10-016-31/+37
|
* vo_opengl: make sw suboption work without explicit backend selectionwm42015-10-013-2/+3
| | | | | | | You needed to select a GL backend with the backend suboption. This was confusing. Fixes #2361.
* vo_opengl: debanding requires GLSL 1.30wm42015-10-011-0/+4
| | | | | | We have to disable it, or shader compilation will fail. Fixes #2362.
* x11: separate window creation and configurationwm42015-09-308-36/+56
| | | | | | | | | | | | | | | | | | | This gets rid of an old hack, VOFLAG_HIDDEN. Although handling of it has been sane for a while, it used to cause much pain, and is still unintuitive and weird even today. The main reason for this hack is that OpenGL selects a X11 Visual for you, and you're supposed to use this Visual when creating the X window for the OpenGL context. Which means the X window can't be created early in the common X11 init code, but the OpenGL code needs to do something before that. API-wise you need separate functions for X11 init and X11 window creation. The VOFLAG_HIDDEN hack conflated window creation and the entrypoint for resizing on video resolution change into one function, vo_x11_config_vo_window(). This required all platform backends to handle this flag, even if they didn't need this mechanism. Wayland still uses this for minor reasons (alpha support?), so the wayland backend must be changed before the flag can be entirely removed.
* vo_opengl: cosmetics: coding stylewm42015-09-301-46/+45
|
* vo_opengl: do not reset video queue when changing video equalizerwm42015-09-301-1/+0
| | | | | | | If interpolation is enabled, then this causes heavy artifacts if done while unpaused. It's preferable to allow a latency of a few frames for the change to take full effect instead. If this is done paused, the frame is fully redrawn anyway.
* Revert "vo_x11: remove this video output"wm42015-09-302-0/+452
| | | | | | | | | | | | | | | This reverts commit d11184a256ed709a03fa94a4e3940eed1b76d76f. Unfortunately, there was a lot of unexpected resistance. Do note that this is still extremely slow, crappy, etc. Note that vo_x11.c was further edited. Compared to the removed vo_x11.c, an additional ~200 lines of code was removed in order to simplify it. I tried to strip it down as much as possible. In particular, support for odd non-32 bit formats (24, 16, 15, 8 bit) is dropped. Closes #2300.
* video: replace vf_format outputlevels option with global optionwm42015-09-297-21/+6
| | | | | | | | | | | The vf_format suboption is replaced with --video-output-levels (a global option and property). In particular, the parameter is removed from mp_image_params. The mechanism is moved to the "video equalizer", which also handles common video output customization like brightness and contrast controls. The new code is slightly cleaner, and the top-level option is slightly more user-friendly than as vf_format sub-option.
* Revert "vd_lavc: do not abort hardware decoding on errors"wm42015-09-281-0/+1
| | | | | | | | | | This essentially reverts commit 009dfbe3. FFmpeg VideoToolbox support is being wacky, and can cause major issues, such as not being able to decode a single frame. (E.g. by playing a .ts file. This should be fixed in FFmpeg eventually.) This is not a straight revert of the commit; just a functional one. We keep the slightly simpler code structure.
* vo_opengl: videotoolbox: cleanupswm42015-09-281-43/+26
| | | | Get rid of the VDA specifics like naming or ancient pixel formats.
* vo_opengl: rename hwdec_vda.c to hwdec_osx.cwm42015-09-281-0/+0
| | | | | | | It doesn't deal with VDA at all anymore. Rename it to hwdec_osx.c. Not using hwdec_videotoolbox.c, because that would give it the longest source path in this project yet. (Also, this code isn't even VideoToolox-specific, other than the name of the pixel format used.)
* video: remove VDA supportwm42015-09-289-142/+3
| | | | | | | | | VideoToolbox is preferred. Now that FFmpeg released 2.8, there's no reason to support VDA anymore. In fact, we had a bug that made VDA not useable with older FFmpeg versions in some newer mpv releases. VideoToolbox is supported even on slightly older OSX versions, and if not, you still can run mpv without hw decoding.
* vd_lavc: remove some ancient cargo-cultingwm42015-09-281-1/+0
| | | | | | | | Definitely not needed anymore, and fixes a crash in some weird corner- cases. The extradata freeing is apparently still needed, though. (Because a codec context can be opened again, which makes no sense, but ok.)
* vo_opengl: vaapi: add Wayland supportwm42015-09-272-0/+18
| | | | | | Pretty trivial with the new EGL interop. Fixes #478.
* vo_opengl: refactor EGL context information callbackwm42015-09-273-16/+33
| | | | | Move the ugliness from x11egl.c to common.c, so that the ugliness doesn't have to be duplicated in wayland.c.
* vaapi: remove dependency on X11wm42015-09-275-21/+84
| | | | | | | | | | | | | There are at least 2 ways of using VAAPI without X11 (Wayland, DRM). Remove the X11 requirement from the decoder part and the EGL interop. This will be used by a following commit, which adds Wayland support. The worst about this is the decoder part, which includes a bad hack for using the decoder without any VO interop (also known as "vaapi-copy" mode). Separate the X11 parts so that they're self-contained. For the EGL interop code we do something similar (it's kept slightly simpler, because it essentially only has to translate between our silly MPGetNativeDisplay abstraction and the vaGetDisplay...() call).
* vo_opengl: vaapi: provide symbols for missing extensionswm42015-09-271-0/+14
| | | | | We also could just check at build time, but since it's not much, just redefine them inline if not present.
* vo_opengl: vaapi: redo how EGL extensions are loadedwm42015-09-275-60/+35
| | | | | | | It looks like my hope that we can unconditionally include EGL headers in the OpenGL code is not coming true, because OSX does not support EGL at all. So I prefer loading the VAAPI EGL/GL specific extensions manually, because it's less of a mess. Partially reverts commit d47dff3f.
* vo_opengl: rpi: fix EGL commentwm42015-09-271-4/+2
| | | | | | While EGL 1.4 seemed a bit ambiguous about this to me, it actually says quite clearly that core functions are not supported with eglGetProcAddress() in the following paragraph.
* vo_opengl: probe for EGL by defaultwm42015-09-262-5/+6
| | | | | | | | | | | Normally, we prefer GLX on X11. But for the VAAPI EGL interop, we obviously want EGL. Since nvidia does not provide EGL with desktop GL yet, we can leave it to the autoprobing. Just make sure some failure messages don't unnecessarily show up in the nvidia case. This breaks VAAPI GLX interop by default, but I don't care much. If you use --hwdec=auto (which you should if you want hw decoding), this should fallback to vaapi-copy instead.
* vo_opengl: x11egl: cleanup uninit pathwm42015-09-261-30/+26
| | | | Get rid of the config_window_x11_egl() indirection.
* vo_opengl: vaapi: probe the surface formatwm42015-09-261-2/+68
| | | | | | | | | | | | | | | | Probe the surface format, and check whether it's really something we support. This also does a complete check whether the EGL interop works at all (the only way to find this out is actually running this code). Also, support YV12. Under some circumstances, vaapi (with Intel drivers) can be made to use this format. Unfortunately, the Intel drivers show some very weird behavior, which is hopefully a bug. insane_hack() provides a very evil workaround (see comments). A proper solution might be passing the hw format as part of mp_image_params, but as long as hw surfaces appear to be able to change the format on the fly, attempting this is probably not worth the extra complexity and likely fragility. The hack allows us to pretend that there is sane behavior for now.
* vaapi: use GPU memcpy for reading back from HW surfacewm42015-09-252-1/+6
| | | | | | | | | This makes it much faster if the surface is really mapped from GPU memory. It's slightly slower than system memcpy if used on system memory. We don't really know definitely in which type of memory it's located, so we use the GPU memcpy in all cases. Fixes #2317.
* video: refactor GPU memcpy usagewm42015-09-255-82/+86
| | | | | | | | | | | | | | | | | Make the GPU memcpy from the dxva2 code generally useful to other parts of the player. We need to check at configure time whether SSE intrinsics work at all. (At least in this form, they won't work on clang, for example. It also won't work on non-x86.) Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some awkward stuff to share the existing code used by mp_image_copy(). I'm hoping that FFmpeg will sooner or later provide a function like this, so we can remove most of this again. (There is a patch, bit it's stuck in limbo since forever.) All this is used by the following commit.
* vd_lavc: Fix recovery from vdpau preemptionPhilip Langdale2015-09-251-3/+3
| | | | | Flushing buffers, and thereby triggering decoder reinitialisation needs to happen before attempting, and failing, to decode.
* vo_rpi, wayland: fix buildwm42015-09-251-2/+2
| | | | | | Broken by commit d47dff3f. If something is going to include EGL.h, header_fixes.h has to know. This definitely affected vo_rpi, and probably affects wayland builds (with x11egl didabled) as well.
* vo_opengl: vaapi: undo vaAcquireBufferHandle() correctly on errorwm42015-09-251-2/+4
| | | | | | | Checking and resetting the VAImage.buf field is non-sense, even if it happened to work out in the normal case. buf is actually freed when vaDestroyImage() is called (not quite intuitive), and we need an extra field to know whether vaReleaseBufferHandle() has to be called.
* vaapi: cosmetics, minor fixeswm42015-09-251-3/+3
| | | | | | | | | | Printing "Using vaDeriveImage()" every frame is too verbose, so raise the log level. mp_image strides are in int and not unsigned int; fix this. It's not like it actually matters, though. Finish a comment.
* vo_opengl: vaapi: handle YV12 correctlywm42015-09-251-0/+3
| | | | This specific FourCC has its planes swapped compared to FFmpeg yuv420p.
* vo_opengl: vaapi: document DRM fourcc upstream defineswm42015-09-251-3/+4
| | | | | | | | | | | Add the upstream symbolic names as comments. Normally, these should be defined in libdrm's drm_fourcc.h header. But DRM_FORMAT_R8 and DRM_FORMAT_GR88 are not defined anywhere, except in the kernel userland headers of Linux 4.3 (!). We don't want mpv to depend on bleeding-edge Linux kernel headers, so this will have to do. Also, just for completeness, add fourccs for the 3 and 4 channel formats. I didn't manage to test them, though.
* vo_opengl: vaapi: use dummy image to determine plane layoutwm42015-09-251-9/+8
| | | | | | | Reduces the amount of hardcoded assumptions about the layout drastically. (Now adding yuv420 support would be just adjusting an if, if you ignore the other problems, such as determining the hw format at all early enough.)
* vo_opengl: vaapi: remove unnecessary loopwm42015-09-251-2/+1
| | | | Not sure what I was thinking.
* vo_opengl: vaapi: fix cleanupwm42015-09-251-0/+2
| | | | | | | Don't call eglDestroyImageKHR() on the same ID possibly more than once. Clear the image reference on termination, or we would leak up to 1 image per VO recreation.
* vo_opengl: support new VAAPI EGL interopwm42015-09-252-0/+251
| | | | | | | | | | | | | | | | | | | | | | | Should work much better than the old GLX interop code. Requires Mesa 11, and explicitly selecting the X11 EGL backend with: --vo=opengl:backend=x11egl Should it turn out that the new interop works well, we will try to autodetect EGL by default. This code still uses some bad assumptions, like expecting surfaces to be in NV12. (This is probably ok, because virtually all HW will use this format. But we should at least check this on init or so, instead of failing to render an image if our assumption doesn't hold up.) This repo was a lot of help: https://github.com/gbeauchesne/ffvademo The kodi code was also helpful (the magic FourCC it uses for EGL_LINUX_DRM_FOURCC_EXT are nowhere documented, and EGL_IMAGE_INTERNAL_FORMAT_EXT as used in ffvademo does not actually exist). (This is the 3rd VAAPI GL interop that was implemented in this player.)
* vo_opengl: add mechanism to retrieve Display from EGL contextwm42015-09-251-0/+18
| | | | | | | | | | The VAAPI EGL interop code will need access to the X11 Display. While GLX could return it from the current GLX context, EGL has no such mechanism. (At least no standard one supported by all implementations.) So mpv makes up such a mechanism. For internal purposes, this is very rather awkward solution, but it's needed for libmpv anyway.
* vo_opengl: load certain EGL extensions needed for VAAPI EGL interopwm42015-09-254-1/+50
| | | | | | | | | These extensions use a bunch of EGL types, so we need to include the EGL headers in common.h to use our GL function loader with this. In the future, we should probably require presence of the EGL headers to reduce the hacks. This might be not so simple at least with OSX, so for now this has to do.
* vo_opengl: actually set hardware decoder mapped texture formatwm42015-09-244-3/+6
| | | | | | | | | | | Surfaces used by hardware decoding formats can be mapped exactly like a specific software pixel format, e.g. RGBA or NV12. p->image_params is supposed to be set to this format, but it wasn't. (How did this ever work?) Also, setting params->imgfmt in the hwdec interop drivers is pointless and redundant. (Change them to asserts, because why not.)
* client API: rename GL_MP_D3D_interfaceswm42015-09-243-4/+12
| | | | | | | | | | | | | This is a pseudo-OpenGL extension for letting libmpv query native windowing system handles from the API user. (It uses the OpenGL extension mechanism because I'm lazy. In theory it would be nicer to let the user pass them with mpv_opengl_cb_init_gl(), but this would require a more intrusive API change to extend its argument list.) The naming of the extension and associated function was unnecessarily Windows specific (using "D3D"), even though it would work just fine for other platforms. So deprecate the old names and introduce new ones. The old ones still work.
* vo_opengl: remove sharpen scalers, add sharpen sub-optionwm42015-09-234-46/+34