aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/out/opengl/hwdec_rpi.c
diff options
context:
space:
mode:
authorGravatar wm4 <wm4@nowhere>2016-09-30 13:48:47 +0200
committerGravatar wm4 <wm4@nowhere>2016-09-30 13:49:49 +0200
commitab07caf39d8c1c04b841498cc878e85546e2f206 (patch)
treee33b2b2cf00cc31f583bb564322a0eea1d2708f6 /video/out/opengl/hwdec_rpi.c
parent2aba6972cf9e07fe2817ff072e5e82756d80d795 (diff)
vo_opengl: rpi: use overlay for yuv420p too
The video code can deal fine with feeding software image formats to hwdec interop drivers. In RPI's case, this is preferable for performance, working around OpenGL bugs (see RPI firmware issue #666), and because OpenGL rendering doesn't bring too many advantages due to RPI supporting GLES 2.0 only. Maybe a way to force the normal video path is needed later. But currently, this can be tested by just not loading the hwdec interop driver. If you run command-line mpv and set --hwdec to something that does not load the RPI interop layer, you'll even have to use --hwdec-preload manually to get it enabled.
Diffstat (limited to 'video/out/opengl/hwdec_rpi.c')
-rw-r--r--video/out/opengl/hwdec_rpi.c7
1 files changed, 6 insertions, 1 deletions
diff --git a/video/out/opengl/hwdec_rpi.c b/video/out/opengl/hwdec_rpi.c
index 92269eab5b..6204f461d1 100644
--- a/video/out/opengl/hwdec_rpi.c
+++ b/video/out/opengl/hwdec_rpi.c
@@ -386,10 +386,15 @@ static int create(struct gl_hwdec *hw)
return 0;
}
+static bool test_format(struct gl_hwdec *hw, int imgfmt)
+{
+ return imgfmt == IMGFMT_MMAL || imgfmt == IMGFMT_420P;
+}
+
const struct gl_hwdec_driver gl_hwdec_rpi_overlay = {
.name = "rpi-overlay",
.api = HWDEC_RPI,
- .imgfmt = IMGFMT_MMAL,
+ .test_format = test_format,
.create = create,
.reinit = reinit,
.overlay_frame = overlay_frame,