mpv/video/decode
wm4 f1e78306cb vaapi: try dealing with Intel's braindamaged shit drivers
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.
2014-08-21 22:45:58 +02:00
..
dec_video.c dvd, bluray, cdda: add demux_disc containing all related hacks 2014-07-05 17:07:15 +02:00
dec_video.h video: don't keep multiple pointers to hwdec info struct 2014-08-11 23:09:39 +02:00
lavc.h vaapi: try dealing with Intel's braindamaged shit drivers 2014-08-21 22:45:58 +02:00
vaapi.c vaapi: try dealing with Intel's braindamaged shit drivers 2014-08-21 22:45:58 +02:00
vd.h video: add a "hwdec" property to enable or disable hw decoding at runtime 2014-04-23 01:58:12 +02:00
vd_lavc.c vaapi: try dealing with Intel's braindamaged shit drivers 2014-08-21 22:45:58 +02:00
vda.c vda: only support the new hwaccel 1.2 API (remove old code) 2014-08-01 10:38:18 +02:00
vdpau.c video: warn if an emulated hwdec API is used 2014-05-28 02:08:45 +02:00