summaryrefslogtreecommitdiffstats
path: root/video/vaapi.c
Commit message (Collapse)AuthorAgeFilesLines
* vaapi: solve potential problem with ambiguous image formatswm42014-03-171-32/+27
| | | | | | | | | | | | | VAAPI has some ambiguous image formats, like VA_FOURCC_I420, VA_FOURCC_IYUV, VA_FOURCC_YV12 (the latter exactly the same as the first two, just with swapped planes). There is potentially a problem when one specific VAAPI format was picked, and converting it to a mpv format and back to a VAAPI FourCC would result in a numerically different format (even if it's actually the same). Then it could e.g. happen that functions like va_surface_upload() reallocate the underlying VAImage, which would be inefficient. Change the code so that this can't happen. (Probably not a problem in practice with the current VAAPI usage.)
* vaapi: simplifywm42014-03-171-67/+60
| | | | Merge va_surface_priv into va_surface.
* vaapi: make struct va_surface privatewm42014-03-171-42/+44
| | | | | | 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-163/+72
| | | | | | | | | | | | 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: fix initialization error code pathwm42013-12-231-1/+2
| | | | "res" can be uninitialized in the error case.
* vaapi: mp_msg conversionswm42013-12-211-39/+43
| | | | | | 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.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* vaapi: remove unused hw image formats, simplifywm42013-11-291-2/+2
| | | | | | | | | | PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not sure why they were even added, and they sound like they are just for compatibility with XvMC-style decoding, which sucks anyway. Now that there's only a single vaapi format, remove the IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was unused.
* video/out: always support redrawing VO window at any pointwm42013-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
* vaapi: fix inverted conditionwm42013-09-291-2/+2
| | | | | | How embarrassing. This could make --hwdec=vaapi-copy as well as screenshots with vo_vaapi randomly fail. Regression since commit b8382aa.
* vaapi: make vaDeriveImage() less verbosewm42013-09-271-1/+1
| | | | | This can just be not supported, so making it look like a real error doesn't make much sense.
* vaapi: check image format in va_surface_upload()wm42013-09-271-2/+5
| | | | 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-30/+53
| | | | | | | | 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: fix compilation with Libavwm42013-09-251-3/+3
| | | | | | | | | | | The code using FFSWAP was moved from vo_vaapi.c to vaapi.c, which didn't include libavutil/common.h anymore, just libavutil/avutil.h. The header avutil.h doesn't include common.h recursively in Libav, so it broke there. Add FFSWAP as MPSWAP in mp_common.h (copy pasted from ffmpeg) to make sure this doesn't happen again. (This kind of stuff happens all too often, so screw libavutil.)
* vaapi: add vf_vavpp and use it for deinterlacingxylosper2013-09-251-0/+520
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 15:43:24 +0000