summaryrefslogtreecommitdiffstats
path: root/video/vaapi.c
Commit message (Collapse)AuthorAgeFilesLines
* 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>