diff options
| author | wm4 <wm4@nowhere> | 2016-09-30 13:48:47 +0200 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2016-09-30 13:49:49 +0200 |
| commit | ab07caf39d8c1c04b841498cc878e85546e2f206 (patch) | |
| tree | e33b2b2cf00cc31f583bb564322a0eea1d2708f6 /video | |
| parent | 2aba6972cf9e07fe2817ff072e5e82756d80d795 (diff) | |
| download | mpv-ab07caf39d8c1c04b841498cc878e85546e2f206.tar.bz2 mpv-ab07caf39d8c1c04b841498cc878e85546e2f206.tar.xz | |
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')
| -rw-r--r-- | video/out/opengl/hwdec_rpi.c | 7 |
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, |