Omxplayer

[tk321]

Thanks for the deb package, it works perfectly for me (but can't test audio). If you get an error like "failed to open vchiq instance" you'll need to "chmod a+rw /dev/vchiq". My compile is binary compatible with your deb (md5sum: 52cbf438b0c3f51828b79d8358ef68cc omxplayer.bin) which is a good sign. Btw, do you think we should try and merge the forks back into the main branch or at least let the main author know?

As for the memory usage by the gpu, I don't know any internals of omxplayer nor the gpu, but from what has been said the gpu requires at least 64MB for video playback, see wikipedia or this thread.

224 MB is for Linux only, with just a 1080p framebuffer; likely to fail for any video or 3D.

[shirro]

Probably the best way to do it is grab the head of the omxplayer repo and do a series of patches against it and have the debian package apply them when it is built. That way there is a clear separation between what has been added to get it running on Raspbian and the upstream source. If the author is willing to accept patches it might be an idea to change the makefiles so they can both cross compile and compile natively on raspbian without patching and submit them.

Some of the issues people have such as wrong permissions on vchiq and having to set LD_LIBRAY_PATH should be dealt with by a debian videocore library package which should be a prerequisite to install things like omxplayer. For the moment people will have to use rpi-update or do things by hand I guess.

[SkG]

Thanks for the deb package, it works perfectly for me (but can't test audio). If you get an error like "failed to open vchiq instance" you'll need to "chmod a+rw /dev/vchiq". My compile is binary compatible with your deb (md5sum: 52cbf438b0c3f51828b79d8358ef68cc omxplayer.bin) which is a good sign.

Is not permission problems because I'm running as root my tests currently, when I finish my tests with RPi I will go from scratch and install Raspbian, but anyway I have a rule.d for vchiq permission.

It start playing, I can hear the audio output without problems but no video, neither X nor pure console.

Btw, do you think we should try and merge the forks back into the main branch or at least let the main author know?

I think we should notify the author because he may be interested on it but first I'm going to do some more Makefile cleanup and I thougth about adding options for compiling softfp and hard and making .deb for the compiled arch. (maybe something like make hard-deb, make soft-deb wich will invoke first make soft or make hard).

As for the memory usage by the gpu, I don't know any internals of omxplayer nor the gpu, but from what has been said the gpu requires at least 64MB for video playback, see wikipedia or this thread.

224 MB is for Linux only, with just a 1080p framebuffer; likely to fail for any video or 3D.

Yeah, I know about it, thats why I'm working always with 192/64 and I tried with 128/128

Probably the best way to do it is grab the head of the omxplayer repo and do a series of patches against it and have the debian package apply them when it is built. That way there is a clear separation between what has been added to get it running on Raspbian and the upstream source.

In fact that's the way that Debian works, they took the source code, make some patches and then apply them and make .deb package. Also they make the src.deb that contains original source code plus debian patchset.

I have not enough knowledge to go this way but I think that hard and softfp should be in the original source, for example implementing it like I said before in this post.

Some of the issues people have such as wrong permissions on vchiq and having to set LD_LIBRAY_PATH should be dealt with by a debian videocore library package which should be a prerequisite to install things like omxplayer. For the moment people will have to use rpi-update or do things by hand I guess.

Debian's package system allows to notify user in the apt-get install process about things he should do, also if there are things like vchiq permissions it can be added to the configure script so when omxplayer get installed the package will automatically run "chmod a+rw /dev/vchiq".

[tk321]

You guys are more experienced with github/debian packaging, so if you want to go ahead with it that'd be great.

Regarding the video out problem, don't know what it could be then. My setup is pisces image changed to 192MB, connected to a monitor (hdmi-dvi) running a resolution like 1600x900 and omxplayer works in console mode as well as in X. Maybe omxplayer.log contains some useful info?

[SkG]

You guys are more experienced with github/debian packaging, so if you want to go ahead with it that'd be great.

Well, I have to refresh my knowledge, atm I just remember how to do what I did but for advanced deb packaging (and should be done in that way) we must follow this: http://www.debian.org/doc/manuals/maint-guide/

At the moment I'm busy but I think I won't be able to have a look until August...

Maybe omxplayer.log contains some useful info?

Will check later, I'm currently at work.

[MarrsAttax]

Hi I can get sound but no video. Could someone explain how to check what my memory split is and how to change it? Thanks

[SkG]

Hi I can get sound but no video. Could someone explain how to check what my memory split is and how to change it? Thanks

Hi! You must change the split modifying the start.elf located at /boot/ but if you are using raspbian you can use:

Code: Select all

rpi-update 128
rpi-update 192
rpi-update 224

Also I want to notify you that some .mkv could fail cause its encoding has high profile or high reference frames (this kind of mkv files can be difficult to play also on Core 2 Duo systems!) and thats was my problem with some mkv that I tried to play on RPi.

[MarrsAttax]

Thanks! Got it working now. Nice and smooth!

[ratherDashing]

but anyway I have a rule.d for vchiq permission.

How did you set that up? I hate having to do the chmod everytime I reboot.

[SkG]

but anyway I have a rule.d for vchiq permission.

How did you set that up? I hate having to do the chmod everytime I reboot.

As root run:

Code: Select all

echo 'SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"' > /etc/udev/rules.d/10-vchiq-permissions.rules

usermod -a -G video YourUnprivilegedUser

[colemickens]

Can anyone share a Github repo and make commands that will allow me to build omxplayer? I checked out skgsergio's fork, but it appears to still be using arm-unknown-linux-gnueabi-g++ and looking in /opt/xbmc-bcm/buildroot/output/host/usr//bin/ no less.

Apologies if it's a simple mistake, I took the post earlier to imply that this Makefile had been tweaked for building for the RPi.

[SkG]

Can anyone share a Github repo and make commands that will allow me to build omxplayer? I checked out skgsergio's fork, but it appears to still be using arm-unknown-linux-gnueabi-g++ and looking in /opt/xbmc-bcm/buildroot/output/host/usr//bin/ no less.

Apologies if it's a simple mistake, I took the post earlier to imply that this Makefile had been tweaked for building for the RPi.

Hi, I abandoned that branch due to the new versions require new libraries that are not in Debian/Raspbian repositories. I'm working on some scripts for DEB creation with the crosscompile version and I'm thinking about setting up a build-bot on my server to have .deb files ready for Raspbian.

If you really want to use my old source, it is not deleted but outdated. You only have to checkout my old master branch instead of my new, and also abandoned until holidays, "huceke-with-deb" branch.

Code: Select all

git clone https://github.com/skgsergio/omxplayer.git
cd omxplayer
git checkout master

[slackhead]

Has anyone managed to route the audio out to an alsa soundcard?

I have a Wolfson card but omxplayer doesn't seem to work with it. -o gives some options but nothing to do with alsa.

[gkreidl]

Has anyone managed to route the audio out to an alsa soundcard?

I have a Wolfson card but omxplayer doesn't seem to work with it. -o gives some options but nothing to do with alsa.

No chance.

You could try a HW accelerated version of VLC. It does the audio decoding in software and should be able to send it to ALSA. I've not tested it, though. I've posted a tutorial about how to compile it.
Only usable for SD and some 720p content, not for HD beyond that.