summaryrefslogtreecommitdiff
path: root/package/omxplayer
AgeCommit message (Collapse)Author
2016-06-06package/omxplayer: remove BR2_PACKAGE_BOOST_ARCH_SUPPORTS optionBernd Kuhls
The option was globally removed with https://git.busybox.net/buildroot/commit/package/boost?id=668ce456448d671f30bf98c4d4819a88b0bf9f4e Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-03package/omxplayer: new packageYann E. MORIN
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>