| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This parameter has been unused for years (the last flag was removed in
commit d658b115). Get rid of it.
This affects the general VO API, as well as the vo_opengl backend API,
so it touches a lot of files.
The VOFLAGs are still used to control OpenGL context creation, so move
them to the OpenGL backend code.
|
|
|
|
|
|
| |
It's just about loading and cachign small files, not does not
necessarily have anything to do with shaders. Move it to video.c where
it's used.
|
|
|
|
| |
The recent OpenGL refactor commits forgot to update this file.
|
|
|
|
| |
And add an option to enable it.
|
|
|
|
|
| |
This is a cosmetic change, because the value is exactly the same. (The
old code just duplicates the logic, sort of.)
|
|
|
|
|
| |
The OSD overlay wasn't initialized, so it remained solid black until the
first time a subtitle line or an OSD element became visible.
|
|
|
|
|
|
|
|
|
|
|
| |
Since vo_rpi uses MMAL for video output, which is completely
independent from the GLES overlay, we can just not redraw the
GLES screen if subtitles do not change.
(As a furhter optimization, the dispmanx overlay could be removed
if nothing is visible. But I'm not sure if adding and removing the
overlay frequently is a good idea for performance, so this could
just as well go the other way.)
|
|
|
|
|
|
|
|
| |
Slightly faster than using the dispmanx mess (perhaps to a large amount
due to the rather stupid C-only unoptimized ASS->RGBA blending code).
Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI
backend.
|
|
|
|
| |
Can happen in obscure situations and with hw decoding disabled.
|
|
|
|
| |
Apparently this is sufficient.
|
|
|
|
| |
Small bug, much pain.
|
|
|
|
| |
It's unnecessary and slow. Doesn't help too much, though.
|
|
|
|
|
|
|
|
| |
This VO is special because it normally doesn't block on vsync, but can
be made to do so. Supposedly the MMAL video output API merely sets a
"current frame" field when sending an output frame, and the firmware
will pick up whatever frame that field is set to at the time of a
vsync.
|
|
|
|
| |
Reverse engineered from tvservice.c.
|
|
|
|
|
|
|
|
| |
(Not sure why it worked without this when I tested the previous
changes.)
Untested, but should be fine. This is equivalent what is done on e.g.
panscan changes.
|
| |
|
|
|
|
|
|
|
|
| |
Also factor the display size initialization into a separate function.
For some reason this seems to work, although setting the background
color using this 1x1 pixel bitmap does not work. I blame the RPI
beign a terrible piece of hardware with even worse drivers.
|
|
|
|
|
|
|
| |
This is optional, but ensures that linking with -Wl,--as-needed does
not drop the MMAL VC driver. The driver normally "registers" itself
in the library constructor, but since no symbols are explicitly
referenced, the linker could remove it with as-needed enabled.
|
|
|
|
|
|
|
| |
Use variants without alpha.
I skipped vo_sdl, because format selection seems a bit more complicated
here, and nobody cares about vo_sdl anymore.
|
|
This requires FFmpeg git master for accelerated hardware decoding.
Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav
will also work.
Most things work. Screenshots don't work with accelerated/opaque
decoding (except using full window screenshot mode). Subtitles are
very slow - even simple but huge overlays can cause frame drops.
This always uses fullscreen mode. It uses dispmanx and mmal directly,
and there are no window managers or anything on this level.
vo_opengl also kind of works, but is pretty useless and slow. It can't
use opaque hardware decoding (copy back can be used by forcing the
option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend
is preferred over the X11 ones in case you're trying on X11; but X11
is even more useless on RPI.
This doesn't correctly reject extended h264 profiles and thus doesn't
fallback to software decoding. The hw supports only up to the high
profile, and will e.g. return garbage for Hi10P video.
This sets a precedent of enabling hw decoding by default, but only
if RPI support is compiled (which most hopefully it will be disabled
on desktop Linux platforms). While it's more or less required to use
hw decoding on the weak RPI, it causes more problems than it solves
on real platforms (Linux has the Intel GPU problem, OSX still has
some cases with broken decoding.) So I can live with this compromise
of having different defaults depending on the platform.
Raspberry Pi 2 is required. This wasn't tested on the original RPI,
though at least decoding itself seems to work (but full playback was
not tested).
|