Commit Graph

8 Commits

Author SHA1 Message Date
wm4 60cd300558 vaapi: remove unused hw image formats, simplify
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.
2013-11-29 14:19:29 +01:00
wm4 ed9295c250 video/out: always support redrawing VO window at any point
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.
2013-10-02 00:36:26 +02:00
wm4 4e1d65983a vaapi: fix inverted condition
How embarrassing. This could make --hwdec=vaapi-copy as well as
screenshots with vo_vaapi randomly fail. Regression since
commit b8382aa.
2013-09-29 13:45:15 +02:00
wm4 b8382aabb3 vaapi: make vaDeriveImage() less verbose
This can just be not supported, so making it look like a real error
doesn't make much sense.
2013-09-27 18:00:03 +02:00
wm4 0901fc8e0e vaapi: check image format in va_surface_upload()
Just for robustness. Also print a warning in vo_vaapi if this happens.
2013-09-27 18:00:03 +02:00
wm4 4d2f354da6 vaapi: potentially make reading surfaces back to system RAM faster
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.
2013-09-27 17:59:44 +02:00
wm4 200fb7eceb vaapi: fix compilation with Libav
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.)
2013-09-25 22:22:02 +02:00
xylosper 39d1ab82e5 vaapi: add vf_vavpp and use it for deinterlacing
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>
2013-09-25 13:53:42 +02:00