mpv - a free, open source, and cross-platform media player

	Commit message (Collapse)	Author	Age	Files	Lines
*	vaapi: try dealing with Intel's braindamaged shit drivers	wm4	2014-08-21	1	-0/+6
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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: make mp_image use mp_image_params directly	wm4	2014-04-21	1	-1/+1
\| \| \| \| \|	Minor cleanup, so that we can stuff more information into mp_image_params later.
*	vaapi: make struct va_surface private	wm4	2014-03-17	1	-1/+1
\| \| \| \| \| \|	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: mp_msg conversions	wm4	2013-12-21	1	-4/+6
\| \| \| \| \| \|	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.
*	gl_hwdec: use a imgfmt field instead of a query_format callback	wm4	2013-11-29	1	-6/+1
\| \| \| \| \|	Now that vdpau always uses a single image format, this can be simplified.
*	video: move struct mp_hwdec_info into its own header file	wm4	2013-11-23	1	-1/+1
\| \| \| \| \| \| \| \|	This means most code accessing this struct must now include hwdec.h instead of dec_video.h. I just put it into dec_video.h at first because I thought a separate file would be a waste, but it's more proper to do it this way, as there are too many files which include dec_video.h only to get the mp_hwdec_info definition.
*	vo_opengl: redo aspects of initialization, change hwdec API	wm4	2013-11-05	1	-7/+7
\| \| \| \| \| \| \| \| \| \| \|	Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
*	vo_opengl/vaapi: use IMGFMT_RGB0	wm4	2013-11-05	1	-1/+1
\| \| \| \| \|	More correct, might make things slightly faster (probably insignificant).
*	vo_opengl: add support for VA-API OpenGL interop	wm4	2013-11-04	1	-0/+140
	VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower.