summaryrefslogtreecommitdiffstats
path: root/video/vaapi.h
Commit message (Collapse)AuthorAgeFilesLines
* vaapi: replace error macro implementationwm42017-09-301-3/+3
| | | | | | | | | | The current check_va_status() function could probably be argued to be derived from the original VAAPI's patch check_status() function, thus GPL-only. While I have my doubts that it applies to an idiom on this level, it's better to replace it. Similar idea, different expression equals no copyright association. An earlier commit message promised this, but it was forgotten.
* vaapi: change license to LGPLwm42017-09-291-7/+7
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* vaapi: move legacy code to vo_vaapi.cwm42017-09-291-21/+0
| | | | | | Done for license reasons. vo_vaapi.c is turned into some kind of dumpster fire, and we'll remove it as soon as I'm mentally ready for unkind users to complain about removal of this old POS.
* vf_vavpp: use libavutil hw frames API for frame pool and uploadwm42017-09-291-3/+0
| | | | | Another step to get rid of the legacy crap in vaapi.c. (Most is still kept, because it's in use by vo_vaapi.c.)
* vd_lavc, vaapi: move hw device creation to generic codewm42017-02-201-1/+3
| | | | | | | | hw_vaapi.c didn't do much interesting anymore. Other than the function to create a device for decoding with vaapi-copy, everything can be done by generic code. Other libavcodec hwaccels are planned to provide the same API as vaapi. It will be possible to drop the other hw_ files in the future. They will use this generic code instead.
* vaapi: remove central lock around vaapi API callswm42017-01-281-4/+0
| | | | | | | | The lock was disabled recently. This commit gets rid of the dummied out calls. The main reason for removing it is that there is no apparent need for it anymore, and the new FFmpeg vaapi code does not use or provide such a lock (there are some places which we cannot control and which do vaapi API calls, like frame destructors).
* vaapi: always create AVHWDeviceContext on initwm42017-01-131-0/+1
| | | | | | 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.)
* 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: move standalone display creation code to common codewm42017-01-111-0/+5
| | | | Preparation for the following commits.
* vaapi: determine surface format in decoder, not in rendererwm42016-04-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, we have made the assumption that a driver will use only 1 hardware surface format. the format is dictated by the driver (you don't create surfaces with a specific format - you just pass a rt_format and get a surface that will be in a specific driver-chosen format). In particular, the renderer created a dummy surface to probe the format, and hoped the decoder would produce the same format. Due to a driver bug this required a workaround to actually get the same format as the driver did. Change this so that the format is determined in the decoder. The format is then passed down as hw_subfmt, which allows the renderer to configure itself with the correct format. If the hardware surface changes its format midstream, the renderer can be reconfigured using the normal mechanisms. This calls va_surface_init_subformat() each time after the decoder returns a surface. Since libavcodec/AVFrame has no concept of sub- formats, this is unavoidable. It creates and destroys a derived VAImage, but this shouldn't have any bad performance effects (at least I didn't notice any measurable effects). Note that vaDeriveImage() failures are silently ignored as some drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL interop. In addition, we still probe whether we can map an image in the EGL interop code. This is important as it's the only way to determine whether EGL interop is supported at all. With respect to the driver bug mentioned above, it doesn't matter which format the test surface has. In vf_vavpp, also remove the rt_format guessing business. I think the existing logic was a bit meaningless anyway. It's not even a given that vavpp produces the same rt_format for output.
* vaapi: replace VA_STR_FOURCCwm42016-01-111-3/+0
|
* vaapi: drop non-existing FourCCwm42015-10-171-4/+0
| | | | | | | This VA_FOURCC isn't even defined by latest drivers, so I'm just assuming it doesn't exist and never existed. For planar 4:2:0, VA_FOURCC_YV12 is normally preferred, and there's even a VA_FOURCC_IYUV for 4:2:0 with unswapped planes.
* build: bump required libva versionwm42015-10-171-6/+0
| | | | | | | | 0.34 and 0.35 don't have the buffer API, such as vaAcquireBufferHandle. This is only needed for the EGL interop, but why bother staying compatible for such old things (0.36 was released over a year ago). We also can drop some minor compatibility ifdeffery.
* vaapi: remove dependency on X11wm42015-09-271-1/+0
| | | | | | | | | | | | | 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).
* vaapi: use GPU memcpy for reading back from HW surfacewm42015-09-251-0/+1
| | | | | | | | | 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.
* vf_vavpp: allocate output surfaces with the same size as inputwm42015-09-231-0/+2
| | | | | | | | | | | | | This can happen if the hw decoder allocates padded surfaces (e.g. mod16), but the VPP output surface was allocated with the exact size. Apparently VPP requires matching input and output sizes, or it will add artifacts. In this case, it added mirrored pixels to the bottom few pixels. Note that the previous commit should have fixed this. But it didn't work, while this commit does. Fixes #2320.
* vaapi: drop compatibility crap and vo_vaapi deinterlacerwm42015-07-081-51/+0
| | | | | | | | | | | Drop libva versions below 0.34.0. These are ancient, so I don't care. Drop the vo_vaapi deinterlacer as well. With 0.34.0, VPP is always available, and deinterlacing is done with vf_vavpp. The vaCreateSurfaces() function changes its signature - actually it did in 0.34.0 or so, and the <va/va_compat.h> defined a macro to make it use the old signature.
* video: reduce error message when loading hwdec backend failswm42015-06-201-1/+1
| | | | | | | | | | | | | | | | | When using --hwdec=auto, about half of all systems will print: "[vdpau] Error when calling vdp_device_create_x11: 1" this happens because usually mpv will be linked against both vdpau and vaapi libs, but the drivers are not necessarily available. Then trying to load a driver will fail. This is a normal part of probing, but the error messages were printed anyway. Silence them by explicitly distinguishing probing. This pretty much goes through all the layers. We actually consider loading hw backends for vo_opengl always "auto probed", even if a hw backend is explicitly requested. In this case vd_lavc will print a warning message anyway (adjust this message a bit).
* vaapi: add missing license headerwm42015-06-081-0/+17
| | | | | | Absence of license header implies LGPL, as mentioned in the "Copyright" file. But vaapi.h contains some code taken from the mplayer-vaapi patch, which was under the typical MPlayer license.
* video: have a generic context struct for hwdec backendswm42015-01-221-0/+2
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* vaapi: minor simplificationwm42015-01-211-3/+1
|
* vaapi: try dealing with Intel's braindamaged shit driverswm42014-08-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | So talking to a certain Intel dev, it sounded like modern VA-API drivers are reasonable thread-safe. But apparently that is not the case. Not at all. So add approximate locking around all vaapi API calls. The problem appeared once we moved decoding and display to different threads. That means the "vaapi-copy" mode was unaffected, but decoding with vo_vaapi or vo_opengl lead to random crashes. Untested on real Intel hardware. With the vdpau emulation, it seems to work fine - but actually it worked fine even before this commit, because vdpau was written and designed not by morons, but competent people (vdpau is guaranteed to be fully thread-safe). There is some probability that this commit doesn't fix things entirely. One problem is that locking might not be complete. For one, libavcodec _also_ accesses vaapi, so we have to rely on our own guesses how and when lavc uses vaapi (since we disable multithreading when doing hw decoding, our guess should be relatively good, but it's still a lavc implementation detail). One other reason that this commit might not help is Intel's amazing potential to fuckup anything that is good and holy.
* video: warn if an emulated hwdec API is usedwm42014-05-281-0/+2
| | | | | | | | | | | | | | | | mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each of these has emulation wrappers. The wrappers are usually slower and have fewer features than their native opposites. In particular the libva vdpau driver is practically unmaintained. Check the vendor string and print a warning if emulation is detected. Checking vendor strings is a very stupid thing to do, but I find the thought of people using an emulated API for no reason worse. Also, make --hwdec=auto never use an API that is detected as emulated. This doesn't work quite right yet, because once one API is loaded, vo_opengl doesn't unload it, so no hardware decoding will be used if the first probed API (usually vdpau) is rejected. But good enough.
* vaapi: make struct va_surface privatewm42014-03-171-16/+6
| | | | | | It's not really needed to be public. Other code can just use mp_image. The only disadvantage is that the other code needs to call an accessor to get the VASurfaceID.
* vaapi: replace image pool implementation with mp_image_poolwm42014-03-171-13/+6
| | | | | | | | | | | | Although I at first thought it would be better to have a separate implementation for hwaccels because the difference to software images are too large, it turns out you can actually save some code with it. Note that the old implementation had a small memory management bug. This got painted over in commit 269c1e1, but is hereby solved properly. Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and I hope I didn't accidentally break it.
* vaapi: mp_msg conversionswm42013-12-211-8/+11
| | | | | | This ended up a little bit messy. In order to get a mp_log everywhere, mostly make use of the fact that va_surface already references global state anyway.
* vaapi: check image format in va_surface_upload()wm42013-09-271-1/+1
| | | | Just for robustness. Also print a warning in vo_vaapi if this happens.
* vaapi: potentially make reading surfaces back to system RAM fasterwm42013-09-271-1/+5
| | | | | | | | Don't allocate a VAImage and a mp_image every time. VAImage are cached in the surfaces themselves, and for mp_image an explicit pool is created. The retry loop runs only once for each surface now. This also makes use of vaDeriveImage() if possible.
* vaapi: add vf_vavpp and use it for deinterlacingxylosper2013-09-251-14/+63
| | | | | | | | Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
* vaapi: fix typowm42013-08-141-2/+2
|
* video: add vaapi decode and output supportwm42013-08-121-0/+73
This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)