Author Topic: Raspberry Pi omxplayer device  (Read 5320 times)

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Raspberry Pi omxplayer device
« on: July 16, 2012, 01:53:57 pm »
following on from this post in qOrbiter on Pi discussion:
http://forum.linuxmce.org/index.php/topic,12606.msg90675.html#msg90675
lets keep discussions on new player device here.

Details on player http://elinux.org/Omxplayer

-Coley.

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5501
  • DOES work for LinuxMCE.
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #1 on: July 16, 2012, 06:07:10 pm »
Ok, the location of the git tree is described here:

http://wrightrocket.blogspot.com/2012/07/building-omxplayer-for-debian-on.html

Some things to understand about media players in LinuxMCE:

LinuxMCE is all about control. Even the media support in LinuxMCE is nothing more than a consolidation point to figure out where to fire messages and for what reasons. The exception to this is of course the stuff needed to create the various data grids for media, but that's not relevant here.

In the end, you have two devices that must be made:

* a Media Stream plugin, which registers itself for media players of a given device template, and creates a MediaStream object for them (read src/Media_Plugin/MediaStream.h), describing the media playing, and its targets etc. The purpose of the plugin is to figure out where the stream needs to go (the target devices in an entertainment area), and what commands need to be done to make that happen.

* a Media Player, which is literally a target device that accepts commands to go do something (Play, Pause, ff, rew, change subtitles, etc..), and it sends events when something happens (Media is playing, a menu is on screen, etc.). It usually has no user interface of its own.

The commands that are sent from Orbiter, are sent to the Media Plugin, which send them to the Media Plugin providing the MEdia Stream for the target EA, which forwards them to the target player. This is actually done transparently, as long as you change one critical piece of code in ReceivedCommandForChild in the plugin. (instead of INVALID COMMAND, you send back INVALID DEVICE, oddly enough.) ;)

Your task, with omxplayer, is to build a player, which has two threads:

* the DCE thread, which is already made, this is made by DCEGen, and it's literally fill in the blanks.
* the media player thread, this literally, you spawn at some point during initialization (CreateChildren, and GetConfig are good choices here. Look at Xine_Player for this.)

You thread through a pointer to the DCE thread to the player thread, as a callback mechanism, and use that to pass back anything the media player stream needs to send back to DCE.

For communication with the media player thread, you of course pass through a pointer to the media player thread, and you use it...

Code: [Select]
void CMD_Pause(...)
{
    PLUTO_SAFETY_LOCK(mediaPlayerMutex);
    m_pMediaPlayer->CMD_Pause();
}

you will notice the PLUTO_SAFETY_LOCK, this is a macro provided literally as a convenience, passing in a mutex, it literally locks the mutex, until the PLUTO_SAFETY_LOCK falls out of scope. This is needed because of course, the DCE stuff is a separate thread, and commands will be called asynchronously.

The other bits needed of course, the device data for the omx player device will have a device data called Name (look at Xine Player), this is literally a WM_CLASS.WM_NAME tuple, i.e. omxplayer.omxplayer .... use wmctrl -l -x to get this. Your player should explicitly set this, and it should match in the device data, this is so that Orbiter will grab the window appropriately.

Xine_Player does have additional window manager logic. You'll need to decide whether this is appropriate or not.

In the database, you just need to provide a mapping for DeviceTemplate_MediaType, so that your omxplayer player device is provided there, and that it is provided for type 4 and/or type 5 (in the mediatype table, 4 is audio, 5 is video.), and that these match what you're changing in your omxplayer plugin's Register method.

Once this is there, the stuff should at least START to work. Your job after this point is to literally provide something the media player can play, and to ferry back changes in the media player as needed. This is entirely up to you. an absolute file path is passed into MH_Play_Media, and in xine_player's case, this is passed in verbatim in most cases, unless you are of course streaming (sending to multiple EAs,) in which case the plugin starts the source player, and sends a fifo://source_player_address/ to the second player, AGAIN, THIS IS ARBITRARY! This is a URL that xine can understand, it knows how to do this, and the Plugin figures out what it needs to do, and sends the appropriate message to the players.

References:

http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Media_Plugin/MediaStream.h
http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Plugin/Xine_Plugin.cpp
http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Plugin/XineMediaStream.cpp
http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Player/Xine_Player.cpp
http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Player/Xine_Stream.cpp

-Thom
« Last Edit: July 16, 2012, 11:58:42 pm by hari »

locutus

  • Veteran
  • ***
  • Posts: 88
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #2 on: July 18, 2012, 02:27:16 am »
while my pi is still packed away for my move I thought I should share that the new Raspbian image that is optimized to use the floating point hardware has a omxplayer rolled in with the image.

stedaniels

  • Regular Poster
  • **
  • Posts: 30
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #3 on: July 18, 2012, 11:15:28 am »
Just make sure the GPU/RAM memory split is set to something more sensible...

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #4 on: July 18, 2012, 12:27:47 pm »
Just make sure the GPU/RAM memory split is set to something more sensible...
"something more sensible" - what do you mean? what values do you suggest?
If qOrbiter is to run on this too it needs most RAM allocated to the GPU.

-Coley.

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #5 on: July 18, 2012, 03:13:29 pm »
Code: [Select]
coley@VirtualBoxK1204:~/src/rpi_scratch/omxplayer$ file omxplayer.bin
omxplayer.bin: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xa7418aeb2fb380510775c2adc54b2c0fef1c0f9e, stripped

Yay! got my sb2 environment going.
need to go building some pluto libs now ...

-Coley.

phenigma

  • NEEDS to work for LinuxMCE
  • ***
  • Posts: 1002
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #6 on: July 18, 2012, 07:30:00 pm »
Yay! got my sb2 environment going.
need to go building some pluto libs now ...

-Coley.

Did you setup for armel or armhf?  I might be able to provide the pluto armel libs for now if you have any troubles.  I am trying to setup an armhf enironment for raspian now.

J.
« Last Edit: July 18, 2012, 07:45:52 pm by phenigma »

golgoj4

  • NEEDS to work for LinuxMCE
  • ***
  • Posts: 1082
  • hrumpf!
    • View Profile
    • Mah Website
Re: Raspberry Pi omxplayer device
« Reply #7 on: July 18, 2012, 09:08:02 pm »
so jealous...i cant even order one yet!
Official Releases
http://deb.linuxmce.org/QOrbiter-release.apk latest Qt4 android apk  http://deb.linuxmce.org/QOrbiterQt5-release.apk for the Qt5 Android version http://deb.linuxmce.org/QOrbiter-release.dmg for the MacOSX version

Unstable Nightlies
http://langstonball.com/downloads

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #8 on: July 18, 2012, 09:33:44 pm »
Did you setup for armel or armhf?  I might be able to provide the pluto armel libs for now if you have any troubles.  I am trying to setup an armhf enironment for raspian now.

J.
armel for now - AFAIR I need 64bit host for bcom toolchain cross to hfp. I didn't dig too far.
I did download the new rasbian image today so might take that for a whirl.

-Coley.

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #9 on: July 18, 2012, 09:35:37 pm »
so jealous...i cant even order one yet!
Do you order from RS/Farnell in the states too? They have opened up the order pages again, you can even order more than one pp.
They have some neat cases too - but shocking lead times!

-Coley.

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #10 on: July 19, 2012, 02:09:29 am »
armel for now - AFAIR I need 64bit host for bcom toolchain cross to hfp. I didn't dig too far.
I did download the new rasbian image today so might take that for a whirl.

-Coley.
I may go back and stick with armel for now - unless I compile my own qt5 _again_ for hardfp. And I feel that would involve getting dirty with some some qt config options. Although you can pass in Bsquask as a distro option, might be worth investigating... must add to list of things to do.

-Coley.

phenigma

  • NEEDS to work for LinuxMCE
  • ***
  • Posts: 1002
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #11 on: July 20, 2012, 01:54:45 am »
armel for now - AFAIR I need 64bit host for bcom toolchain cross to hfp. I didn't dig too far.
I did download the new rasbian image today so might take that for a whirl.

Ah, yes the pi foundation tools.  You can compile under qemu in a raspian chroot.  I rolled an armel and armhf set for i386 with crosstool-ng.  I'm building armhf in a cross compiled and a qemu compiled version right now to compare any differences afterwards.  I can provide any of the pluto libs you may need for armel or armhf.  It's been easy enough I may try an amd64 cross compile as well.  That could mostly be built with a stock database.

I may go back and stick with armel for now - unless I compile my own qt5 _again_ for hardfp. And I feel that would involve getting dirty with some some qt config options. Although you can pass in Bsquask as a distro option, might be worth investigating... must add to list of things to do.

My list always seems to grow faster than it shrinks.  Let me know if I can be of any assistance.

J.

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #12 on: July 20, 2012, 04:21:05 pm »
can you send me your .config files please, for hard and soft.
I had looked at crosstool and buildroot when I started on this - but when I could just get the bcm toolchain from git I parked it.

thanks,
-Coley.

phenigma

  • NEEDS to work for LinuxMCE
  • ***
  • Posts: 1002
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #13 on: July 22, 2012, 07:15:27 pm »
can you send me your .config files please, for hard and soft.
I had looked at crosstool and buildroot when I started on this - but when I could just get the bcm toolchain from git I parked it.

Sure.  They should be attached.  I'm installing the raspian build on my pi now to see if everything works there or not.  The squeeze build was already tested on the pi so it works.  The squeeze build was done with crosstool-ng 1.13.3 and the raspian build was created with crosstool-1.15.3.

J.

coley

  • Guru
  • ****
  • Posts: 481
    • View Profile
Re: Raspberry Pi omxplayer device
« Reply #14 on: July 23, 2012, 04:55:15 pm »
Thanks for those.
After something you said and hari also in IRC - I dug around and now have a raspbian armhf chroot env set up, this has to be the most straight forward so far!
 - chroot into env
 - svn co ...
 - cd <package of interest>
 - make :)

I'll wiki it once I go over my steps
-Coley.