As the mmal modules will require some shared code in the future move them out
of the split directory structure into a hw/mmal subdirectory, like it
is handled with vdpau plugins already.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
If you missed the fact that recursive makefiles are harmful, there is
plenty of documentation online (try "Recursive makefiles considered
harmful"), or ask the libav developers for the more concise version.
This change and the previous ones, are particularly boring though. The
main motivation is to eventually address #9397, after the same change is
applied to codec/, demux/ and possibly a few other subdirectories.
Note that some more simplification between Makefile.am files and
configure.ac is definitely possible - if someone is bored.
This provides a more traditional set of library function calls than the
VDPAU specification defines. Furthermore, this has libvdpau.so as a
conditional run-time linking dependency.
Note that this requires libvdpau 0.6 or later (0.4.1-8 on Debian) at
run-time due to a bug in libvdpau versions 0.4 through 0.5.
Unfortunately, we cannot emit NEON opcodes when NEON is not explicitly
enabled (-mfpu=neon), contrary to MMX & SSE on x86. As a consequence,
this will not work for inline assembler in a non-optimized plugin,
namely the deinterlacer.
There is also a(n hopefully theoretical) bug whereby the compiler would
emit NEON instructions in the descriptor or activation callback of a
NEON plugin. This could then crash if NEON is not supported, even
before the NEON run-time check is reached.
* Generate the plugins cache for the build tree during make all
(if not cross-compiling).
* Generate the plugins cache for the installation during make install
(if not staging with DESTDIR).
Rémi Denis-Courmont
Julian Scheel
Rafaël Carré
Jean-Baptiste Kempf
Srikanth Raju
Rafaël Carré