1

I ve tried using mplayer. It was running HQ(720p) videos in slow motion so i tried splitting the memory in favor of the gpu,I went till 50/50 however that didn t solve the problem. Someone came up and told me that mplayer doesn t use the graphical acceleration of the rpi , so i ended up giving up on that and turned my intrest towards omxplayer wich was saied to support that. After long hours of smashing my head on the keyboard trying to make it work on fedora i realize i can t afford to spend more time on that since i havent get anyfar. Basically I want to know if u guys can help me out with any suggestions because it is my first time doing this. **

mplayer :

mplayer -vo fbdev /home/user/Adele\ -\ Hello\ -\ YouTube.MKV -xy 1280

I get this :

Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
[swscaler @ 0x766d0030]bicubic scaler, from yuv420p to rgb565le using C
[swscaler @ 0x766d0030]No accelerated colorspace conversion found from yuv420p to rgb565le.
[swscaler @ 0x766d0030]using unscaled yuv420p -> rgb565le special converter
VO: [fbdev] 854x480 => 1280x720 BGR 16-bit
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
[swscaler @ 0x766d0030]No accelerated colorspace conversion found from yuv420p to rgb565le.
VO: [fbdev] 854x480 => 1280x720 BGR 16-bit
A:   0.2 V:   0.0 A-V:  0.194 ct:  0.000   0/  0 ??% ??% ??,?% 0 0
[VD_FFMPEG] DRI failure.
A:   3.5 V:   2.5 A-V:  0.993 ct:  0.043   0/  0 76% 54%  8.9% 50 0

The video starts running but it s kind of too slow, i get this output after a fex seconds:

  ************************************************
   **** Your system is too SLOW to play this!  ****
   ************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
    e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html

omxplayer :

here is what i get when i do make

/home/dc4/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian//bin/arm-linux-gnueabihf-g++ --sysroot=/opt/bcm-rootfs -isystem/include -pipe -mfloat-abi=hard -mcpu=arm1176jzf-s -fomit-frame-pointer -mabi=aapcs-linux -mtune=arm1176jzf-s -mfpu=vfp -Wno-psabi -mno-apcs-stack-check -g -mstructure-size-boundary=32 -mno-sched-prolog -std=c++0x -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -DTARGET_LINUX -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CMAKE_CONFIG -D__VIDEOCORE4__ -U_FORTIFY_SOURCE -Wall -DHAVE_OMXLIB -DUSE_EXTERNAL_FFMPEG  -DHAVE_LIBAVCODEC_AVCODEC_H -DHAVE_LIBAVUTIL_OPT_H -DHAVE_LIBAVUTIL_MEM_H -DHAVE_LIBAVUTIL_AVUTIL_H -DHAVE_LIBAVFORMAT_AVFORMAT_H -DHAVE_LIBAVFILTER_AVFILTER_H -DHAVE_LIBSWRESAMPLE_SWRESAMPLE_H -DOMX -DOMX_SKIP64BIT -ftree-vectorize -DUSE_EXTERNAL_OMX -DTARGET_RASPBERRY_PI -DUSE_EXTERNAL_LIBBCM_HOST -isystem/opt/bcm-rootfs/opt/vc/include -isystem/opt/bcm-rootfs/usr/include -isystem/opt/bcm-rootfs/opt/vc/include/interface/vcos/pthreads -Ipcre/build -Iboost-trunk -Ifreetype2/include -I./ -Ilinux -Iffmpeg_compiled/usr/local/include/ -I /usr/include/dbus-1.0 -I /usr/lib/arm-linux-gnueabihf/dbus-1.0/include -c linux/XMemUtils.cpp -o linux/XMemUtils.o -Wno-deprecated-declarations

/home/dc4/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian//bin/arm-linux-gnueabihf-g++: /home/dc4/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian//bin/arm-linux-gnueabihf-g++: cannot execute binary file

Makefile:46: recipe for target 'linux/XMemUtils.o' failed

make: *** [linux/XMemUtils.o] Error 126
Ezwig
  • 123
  • 9
  • 1
    You are likely to have a much easier time doing this if you run Raspbian. Is there a reason you need fedora? Please edit your question and define HQ video and what problem you are having with omxplayer. – Steve Robillard Aug 26 '16 at 09:52
  • right now the reason is that i don t want to redo the work i ve already done, other than the video display – Ezwig Aug 26 '16 at 09:56

1 Answers1

2

It looks like you are trying to cross-compile oxmplayer. That's not necessary. What's more, it looks like you are trying to do it with the cross-compiler intended for the ARMv6 single core Pis (A/B/+/0). This will probably be okay on Fedora ARM, which is ARMv7 -- hence can't be used on those models, but is backward compatible with the software created for them, as we shall see -- but is also a totally unnecessary hassle. You should just use the stock arm-gnueabi cross compiler that most distros package. It's no good for the ARMv6 models but it is intended for v7+.

I have a Fedora 23 card I use in the Pi 2 and 3 with omxplayer installed. I didn't compile it at all however (I may have tried, I don't recall), I just used the Raspbian binary. I'll step through how you can do that. The explanation here is longer than .configure; make; make install but the process is much shorter and less prone to unpredictable problems. Plus you may get to learn some tedious details about how binary executables are packaged and linked. >_>

I'll break this into steps since it is kind of convoluted.

  1. Download the .deb
  2. Extract the .deb
  3. Check the executable linkage (and install /opt/vc)
  4. Install the omxplayer libs
  5. Install a couple of Debian armhf packages
  6. Install the Fedora libs
  7. Install the OMXPlayer executables
  8. Consider permissions on /dev/vchiq

1) Download the .deb

First you have to download it; this will be in the form of a .deb package, which is what the Raspbian package manager uses. Usually they can be found here, but not omxplayer -- I've never bothered to find out exactly how that system works to track down everything the repo offers via the package manager, but you can download them via apt with a Raspbian system anyway.

In this case you don't even have to do that because a quick search reveals the OMXPlayer Builds page, and note if you check apt show omxplayer on Raspbian, that appears to be exactly what's used there. Download the "Latest build" deb, e.g.:

wget http://omxplayer.sconde.net/builds/omxplayer_0.3.7~git20160713~66f9076_armhf.deb
sha1sum omxplayer_0.3.7~git20160713~66f9076_armhf.deb

The last command is optional and just to verify the integrity of the package. It should output a match to the "SHA1 Hash" shown on the download page.

2) Extract the .deb

You should be working su root for the rest of this, unless you want to just install this in a particular user's $HOME. If so you can extrapolate how yourself.

As explained on wikipedia, a deb file is an ar file mostly wrapping a couple of tar archives. Tools for unpacking them are standard on any GNU/Linux system, including Fedora.

ar x omxplayer_0.3.7~git20160713~66f9076_armhf.deb

You might want to do this in a temporary empty directory because it doesn't create one, and extracts a few different files. The one we are interested in is data.tar.xz. This will unfold into a directory tree -- one which parallels the root filesystem, although in this case it only includes stuff for the /usr directory.

tar -xJf data.tar.xz

You probably want everything that's there, and it's up to you whether you place it in /usr or /usr/local, which is structured the same way and will work. To do the former, you can just copy data.tar.xz to / and (un)tar it there -- rather than then creating a /usr tree, it will all get extracted into the existing one (in this case I recommend first doing it in the temp directory, because there's some stuff we have to check, and this makes it easier to find).

Here's what the tree in that particular tarchive actually includes:

usr
├── bin
│   ├── omxplayer
│   └── omxplayer.bin
├── lib
│   └── omxplayer
│       ├── libavcodec.so -> libavcodec.so.57.48.101
│       ├── libavcodec.so.57 -> libavcodec.so.57.48.101
│       ├── libavcodec.so.57.48.101
│       ├── libavdevice.so -> libavdevice.so.57.0.101
│       ├── libavdevice.so.57 -> libavdevice.so.57.0.101
│       ├── libavdevice.so.57.0.101
│       ├── libavfilter.so -> libavfilter.so.6.47.100
│       ├── libavfilter.so.6 -> libavfilter.so.6.47.100
│       ├── libavfilter.so.6.47.100
│       ├── libavformat.so -> libavformat.so.57.41.100
│       ├── libavformat.so.57 -> libavformat.so.57.41.100
│       ├── libavformat.so.57.41.100
│       ├── libavutil.so -> libavutil.so.55.28.100
│       ├── libavutil.so.55 -> libavutil.so.55.28.100
│       ├── libavutil.so.55.28.100
│       ├── libswresample.so -> libswresample.so.2.1.100
│       ├── libswresample.so.2 -> libswresample.so.2.1.100
│       ├── libswresample.so.2.1.100
│       ├── libswscale.so -> libswscale.so.4.1.100
│       ├── libswscale.so.4 -> libswscale.so.4.1.100
│       └── libswscale.so.4.1.100
└── share
    ├── doc
    │   └── omxplayer
    │       ├── COPYING
    │       └── README
    └── man
        └── man1
            └── omxplayer.1

8 directories, 26 files

That's output from tree, BTW (dnf install tree on Fedora). The -> indicate some of the files have local symlinks, which is normal for shared libraries. And this is pretty nice: OMXPlayer, true to being a video player created for the pi, includes all those libraries.

3) Check the executable linkage (and install /opt/vc)

That doesn't mean it's guaranteed to work out-of-the-box this way on Fedora ARM. We want to start with the stuff in the bin directory:

omxplayer
omxplayer.bin

The first one is a shell script wrapper on the second one. The second one is the actual executable and links to more shared libraries than it comes with, which is also very normal. We need to check that all they are all available.

ldd omxplayer.bin

There's 40 lines of output. A lot of them will be "=> not found" and that's the stuff we need to figure out.

Critical to omxplayer using hardware acceleration is the presence of the (propretary?) libs included in /opt/vc/lib with Raspbian. If you don't have that stuff on your Fedora system, you should (it may or may not help w/ mplayer, BTW). I have an explanation of how to do that at the bottom here under /opt/vc. If you're using some spin that was intended for the pi you probably already have it. Check.

Since I've already done that, I can verify that this version of omxplayer links to those GPU libs:

> ldd omxplayer.bin | grep /opt/vc/lib
libWFC.so => /opt/vc/lib/libWFC.so (0x76f0d000)
libGLESv2.so => /opt/vc/lib/libGLESv2.so (0x76ee8000)
libEGL.so => /opt/vc/lib/libEGL.so (0x76eaf000)
libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76e88000)
libopenmaxil.so => /opt/vc/lib/libopenmaxil.so (0x76e72000)
libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0x76d9e000)
libvcos.so => /opt/vc/lib/libvcos.so (0x76d84000)
libbrcmGLESv2.so => /opt/vc/lib/libbrcmGLESv2.so (0x7690e000)
libbrcmEGL.so => /opt/vc/lib/libbrcmEGL.so (0x768d4000)

This all has to work out first. Don't bother with the rest until you get to this point (all the /opt/vc/lib links above exist).

4) Install the omxplayer libs

Once that's done, install all the libs that came with omxplayer. Since they're in a particular directory inside the tree unpacked from data.tar.xz, just move it:

mv usr/lib/omxplayer /usr/lib

Now create a file /etc/ld.so.conf.d/omxplayer.conf with two lines:

/usr/lib/omxplayer
/usr/local/lib/arm-linux-gnuabihf

(Note the second of these doesn't exist yet.) Run ldconfig, then check the output of ldd omxplayer.bin again.

5) Install a couple of Debian armhf packages

There will be some => not founds left. To home in on them:

ldd omxplayer.bin | grep "not found"

Most of these can be installed from Fedora, but there are a few I notice I've installed from other Debian packages, possibly because they aren't found in Fedora repos for one reason or another. We'll tackle those first:

libpcre.so.3
libssl.so.1.0.0
libcrypto.so.1.0.0

I used Debian armhf (ARMv7) packages for these, and this is why I created the /usr/local/lib/arm-linux-gnueabihf directory. The packages can be found here:

They both can be opened with ar x and will contain a data.tar.xz that can then be opened with tar -xJd data.tar.xz -- this time definitely do it in a new temporary directory or things will get a little confusing.

The first one, libpcre3, will contain a number of things you can ignore. There are two "arm-linux-gnueabihf" directories in the tree from the tarchive, one in lib and one in usr/lib. Each contains a pair of files, one of which is a symlink to the other. Copy all four files into /usr/local/lib/arm-linux-gnueabihf. Remember, you should be working as root at this point or otherwise making sure the ownerships are root.

The other one, libssl1, contains again mostly stuff you can ignore (note I probably have not used whatever functionality omxplayer requires from this, which is probably related to streaming from HTTPS sources -- however, all the linkage at least works out and there are no failures due to missing symbols, which would be a fatal problem). In the usr/lib directory of the unpacked data.tar.xz there will be a directory and two files:

openssl-1.0.0 
libcrypto.so.1.0.0
libssl.so.1.0.0

The first one is a directory with various shared object files; I don't actually think any of it comes into play (I believe it has to do with a Debian oddity regarding the use of openssl, so shouldn't affect other Fedora software either). However, it's small so copy those three things into /usr/local/lib/arm-linux-gnueabihf too.

There are actually 4 libs there, so one more than the omxplayer.bin linkage needs, but that's fine. However, for whatever reason when extracted as above from the .debs they are not executable, which they need to be, so for each one:

chmod 755 libcrypto.so.1.0.0
chmod 755 libpcreposix.so.3.13.1
chmod 755 libpcre.so.3.13.1
chmod 755 libssl.so.1.0.0

and when you're done, run ldconfig.

If that line was included earlier in the /etc/ld.so.conf.d/omxplayer.conf and you've done all this properly, those three needed links from ldd omxplayer.bin should now be found. You can check the .so with ldd, i.e.:

> ldd /usr/local/lib/arm-linux-gnueabihf/* | grep "not found"
ldd: ./openssl-1.0.0: not regular file

That's the only line of output you should get from that.

6) Install the Fedora libs

For each of the remaining "not found" libraries you're going to have to find the appropriate Fedora package, e.g.:

dnf provides "*/libgnutls.so.30"

Notice the glob pattern with the prefixed "*/". Probably most of these are in a lib directory but they may also be in their own subdirectory so that's what works. Then:

dnf install gnutls-3.4.14-1

After each one, check ldd ... grep "not found" again because some of them may get covered together.

7) Install the OMXPlayer executables

Make sure all the "not founds" are resolved at this point. The from the omxplayer .deb's unpacked data.tar.xz, install the omxplayer binary and wrapper,

cp -a usr/bin/* /usr/bin

and for the man page, etc.

cp -a usr/share/* /usr/share

8) Consider permissions on /dev/vchiq

Finally, if you want to use omxplayer as a non-root user, you'll need to grant read/write permissions to /dev/vchiq. You can do that various ways; the easiest is (as root or via sudo if possible), chmod a+x /dev/vchiq. This won't persist across reboots but you can put it in /etc/rc.local on Fedora 23 ARM (if it exists; Fedora has moved away from this practice but it's there on mine -- if it isn't leave a comment). Otherwise you'll get:

failed to open vchiq instance

There are more nuanced ways to do this, such as creating a group, setting permissions just for that group, adding the user to that group, and setting up a udev rule instead of using rc.local, but I've never bothered.

Done!

Since I actually had the previous version (0.3.6) installed, I went through this with the 0.3.7 package to confirm it works, using a couple of .mkv test files from here. The 55 Mbps clip with audio recommended at the bottom as a equivalent to Blu-ray played fullscreen no problems with sound (which I am positive the sounds are not made by jellyfish...), albeit right now that card is in a Pi 3, it shouldn't matter much. Beware omxplayer won't play all .mkv files, just H.264 ones, so if you use those as a test tick that box at the top so you don't waste time downloading the wrong thing.

If you have HD .mkv files that aren't H.264 too bad -- the Pi's hardware won't help with them and it will suck ("Your system is too SLOW to play this!"). There may be tools around to convert them. I believe YouTube is H.264 based (I've used yt-dl with the Pi).

Good luck. If this looks bewildering, just work through it slowly a step at a time, it is all there, pay attention and read carefully. If you have a problem leave a comment.

goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • 1
    Nicely done. Gadzooks. – goobering Aug 26 '16 at 12:50
  • an amazing Response thak you , i ll let you know how it goes once i get time to work on it further, i was reading the part about downloading /opt/vc and i think u don t have to download all the 3.5 GB using [link](http://stackoverflow.com/questions/7106012/download-a-single-folder-or-directory-from-a-github-repo) – Ezwig Aug 27 '16 at 12:02
  • @goldilocks i ve actually hit a wall on this matter , here is a link explaining where am stuck at [link](http://unix.stackexchange.com/questions/306407/how-to-get-the-shared-librarys-in-order-to-make-omxplayer-work) – Ezwig Aug 29 '16 at 12:28
  • Okay, I've updated this with the bit I missed out before -- sorry. There's a now a bunch of things beginning with *"Once that's done, install all the libs that came with omxplayer"* that involve creating a file in `/etc/ld.so.conf.d` and installing a couple more `.debs` (sorry again, lol -- these are much simpler though). I spent hours on this the first time uncertain it was going to work out but it does, so if you have any more problems lemme know. – goldilocks Aug 29 '16 at 13:16
  • Part of the new stuff is after some of the other old stuff so the whole flow makes sense, that begins *"There are a few of these I notice I've installed from other Debian packages..."* further down. – goldilocks Aug 29 '16 at 13:17
  • Okay, I've broken this into steps to make it more readable. The new stuff is in steps 4 & 5. – goldilocks Aug 29 '16 at 13:44
  • Yeah but you do need to make them executable, dunno why they come out of the archive that way -- perhaps there's something in the control files for the `.deb` that makes the normal package manager do it. Anyway, for each of libcrypto.so.1.0.0, libpcreposix.so.3.13.1, libpcre.so.3.13.1, libssl.so.1.0.0 run `chmod 755 ______`. I think one of those four isn't used but it came in the openssl package. Will edit this in too, lol. Obviously I'd forgotten how much was involved...testing the new package didn't really require me to do everything again, it just confirmed it would work. – goldilocks Aug 29 '16 at 14:10
  • 1
    WORKS like a charm ,thank you for helping me learn about depackaging and linking! – Ezwig Aug 29 '16 at 14:19
  • I am so relieved to hear that :) – goldilocks Aug 29 '16 at 14:20
  • @goldilocks btw is it possible to zoom on a video so it occupys all the screen? i mean some are just being displayed in the bottom 3/4 – Ezwig Aug 29 '16 at 15:30
  • Hmm, I guess that's odd -- you should check and see what it says about the resolution of those. Do you mean all the way across the bottom 3/4, or at 3/4 scale of the screen? – goldilocks Aug 29 '16 at 15:33
  • the top 1/4the of the screen is black, video isn t adjusting to run on the totality of the screen – Ezwig Aug 29 '16 at 15:36
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/44635/discussion-between-ezwig-and-goldilocks). – Ezwig Aug 29 '16 at 15:39