package/omxplayer: new package
OMXplayer uses openMAX on the RPi to play videos with hardware
acceleration.
Compared to using a gstreamer pipe, OMXplayer uses a complete
"tunnel-mode", in which the video is piped (after demuxing) into the
hardware, all the way down to the display, whereas gstreamer composes
the video using the eglgles sink, which uses mem-to-mem copies.
So, when playing a locally-stored 1080p video, OMXplayer averages 20%
(with peaks up to ~30%, depending on the complexity of the video) CPU,
while gstreamer bursts up to 40+% when playing 720p and totally chokes
on a 1080p video; all on an non-overclocked RPi-1.
Note that we have to depend on rpi-userland. rpi-userland is a GLES/EGL
provider, so it can't be selected (as all providers of a virtual package
can't).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: add a depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-02 12:09:58 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# omxplayer
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2017-12-01 18:27:55 +01:00
|
|
|
OMXPLAYER_VERSION = 2ee17b22a6149a043a2e402580504f282c615373
|
package/omxplayer: new package
OMXplayer uses openMAX on the RPi to play videos with hardware
acceleration.
Compared to using a gstreamer pipe, OMXplayer uses a complete
"tunnel-mode", in which the video is piped (after demuxing) into the
hardware, all the way down to the display, whereas gstreamer composes
the video using the eglgles sink, which uses mem-to-mem copies.
So, when playing a locally-stored 1080p video, OMXplayer averages 20%
(with peaks up to ~30%, depending on the complexity of the video) CPU,
while gstreamer bursts up to 40+% when playing 720p and totally chokes
on a 1080p video; all on an non-overclocked RPi-1.
Note that we have to depend on rpi-userland. rpi-userland is a GLES/EGL
provider, so it can't be selected (as all providers of a virtual package
can't).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: add a depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-02 12:09:58 +02:00
|
|
|
OMXPLAYER_SITE = $(call github,popcornmix,omxplayer,$(OMXPLAYER_VERSION))
|
2017-03-30 15:43:32 +02:00
|
|
|
OMXPLAYER_LICENSE = GPL-2.0+
|
package/omxplayer: new package
OMXplayer uses openMAX on the RPi to play videos with hardware
acceleration.
Compared to using a gstreamer pipe, OMXplayer uses a complete
"tunnel-mode", in which the video is piped (after demuxing) into the
hardware, all the way down to the display, whereas gstreamer composes
the video using the eglgles sink, which uses mem-to-mem copies.
So, when playing a locally-stored 1080p video, OMXplayer averages 20%
(with peaks up to ~30%, depending on the complexity of the video) CPU,
while gstreamer bursts up to 40+% when playing 720p and totally chokes
on a 1080p video; all on an non-overclocked RPi-1.
Note that we have to depend on rpi-userland. rpi-userland is a GLES/EGL
provider, so it can't be selected (as all providers of a virtual package
can't).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: add a depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-02 12:09:58 +02:00
|
|
|
OMXPLAYER_LICENSE_FILES = COPYING
|
|
|
|
|
|
|
|
|
|
OMXPLAYER_DEPENDENCIES = \
|
2017-12-04 22:31:03 +01:00
|
|
|
host-pkgconf alsa-lib boost dbus ffmpeg freetype libidn libusb pcre \
|
package/omxplayer: new package
OMXplayer uses openMAX on the RPi to play videos with hardware
acceleration.
Compared to using a gstreamer pipe, OMXplayer uses a complete
"tunnel-mode", in which the video is piped (after demuxing) into the
hardware, all the way down to the display, whereas gstreamer composes
the video using the eglgles sink, which uses mem-to-mem copies.
So, when playing a locally-stored 1080p video, OMXplayer averages 20%
(with peaks up to ~30%, depending on the complexity of the video) CPU,
while gstreamer bursts up to 40+% when playing 720p and totally chokes
on a 1080p video; all on an non-overclocked RPi-1.
Note that we have to depend on rpi-userland. rpi-userland is a GLES/EGL
provider, so it can't be selected (as all providers of a virtual package
can't).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: add a depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-02 12:09:58 +02:00
|
|
|
rpi-userland zlib
|
|
|
|
|
|
|
|
|
|
OMXPLAYER_EXTRA_CFLAGS = \
|
|
|
|
|
-DTARGET_LINUX -DTARGET_POSIX \
|
|
|
|
|
`$(PKG_CONFIG_HOST_BINARY) --cflags bcm_host` \
|
|
|
|
|
`$(PKG_CONFIG_HOST_BINARY) --cflags freetype2` \
|
|
|
|
|
`$(PKG_CONFIG_HOST_BINARY) --cflags dbus-1`
|
|
|
|
|
|
|
|
|
|
# OMXplayer has support for building in Buildroot, but that
|
|
|
|
|
# procedure is, well, tainted. Fix this by forcing the real,
|
|
|
|
|
# correct values.
|
|
|
|
|
OMXPLAYER_MAKE_ENV = \
|
|
|
|
|
SDKSTAGE=$(STAGING_DIR) \
|
|
|
|
|
$(TARGET_CONFIGURE_OPTS) \
|
|
|
|
|
STRIP=true \
|
|
|
|
|
CFLAGS="$(TARGET_CFLAGS) $(OMXPLAYER_EXTRA_CFLAGS)"
|
|
|
|
|
|
|
|
|
|
define OMXPLAYER_BUILD_CMDS
|
|
|
|
|
$(OMXPLAYER_MAKE_ENV) $(MAKE) -C $(@D) omxplayer.bin
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define OMXPLAYER_INSTALL_TARGET_CMDS
|
|
|
|
|
$(INSTALL) -m 0755 -D $(@D)/omxplayer.bin $(TARGET_DIR)/usr/bin/omxplayer
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(eval $(generic-package))
|
