Raspberry PI & omxplayer from Squeak

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Raspberry PI & omxplayer from Squeak

Jon Hylands

Hi,

I've been playing around with Squeak 5.0 on a pi 2 (with the 7" LCD touchscreen), and one of the things I'd like to be able to do is run (and control) omxplayer from within Squeak.

I did the same thing with Python, using this library: https://github.com/willprice/python-omxplayer-wrapper/tree/develop/omxplayer

However, I don't really need all the fancy controls - what I really want is a way to launch it, and then a way to kill it. I'll be streaming live MJPEG video from a webcam, so there is no concept of pause/stop/etc. I need to kill it because I want the ability to choose one of a couple different video streams.

I tried using OSProcess, but it gives me the pid of the shell script that launches the application, and not the application itself. I could certainly hack something using ps and grep, but I would prefer if there were a better way to do it.

Any ideas?

Thanks,
Jon



Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

Eliot Miranda-2
Hi Jon,

   The primitive primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir: directly calls execute, so if you invoke it with the name of the program it will fork and exec that program and answer its pid.  Not sure where the substitution of the shell is.  Is omxplayer perhaps a shell script that wraps the actual program?

I suggest you step though execution from your launch command all the way to the send of primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir: and see what its being invoked with, and you check what the omxplayer file is in the rip filesystem.

(I could be completely confused but see UnixOSProcessPlugin>>#forkAndExecInDirectory: in the VMConstruction-Plugins-OSProcessPlugin package at http://www.squeaksource.com/OSProcessPlugin and I think you'll agree with me that the primitive does not interpose a shell). 

HTH

On Wed, Nov 18, 2015 at 6:12 PM, Jon Hylands <[hidden email]> wrote:

Hi,

I've been playing around with Squeak 5.0 on a pi 2 (with the 7" LCD touchscreen), and one of the things I'd like to be able to do is run (and control) omxplayer from within Squeak.

I did the same thing with Python, using this library: https://github.com/willprice/python-omxplayer-wrapper/tree/develop/omxplayer

However, I don't really need all the fancy controls - what I really want is a way to launch it, and then a way to kill it. I'll be streaming live MJPEG video from a webcam, so there is no concept of pause/stop/etc. I need to kill it because I want the ability to choose one of a couple different video streams.

I tried using OSProcess, but it gives me the pid of the shell script that launches the application, and not the application itself. I could certainly hack something using ps and grep, but I would prefer if there were a better way to do it.

Any ideas?

Thanks,
Jon







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

David T. Lewis
In reply to this post by Jon Hylands
On Wed, Nov 18, 2015 at 09:12:51PM -0500, Jon Hylands wrote:

> Hi,
>
> I've been playing around with Squeak 5.0 on a pi 2 (with the 7" LCD
> touchscreen), and one of the things I'd like to be able to do is run (and
> control) omxplayer from within Squeak.
>
> I did the same thing with Python, using this library:
> https://github.com/willprice/python-omxplayer-wrapper/tree/develop/omxplayer
>
> However, I don't really need all the fancy controls - what I really want is
> a way to launch it, and then a way to kill it. I'll be streaming live MJPEG
> video from a webcam, so there is no concept of pause/stop/etc. I need to
> kill it because I want the ability to choose one of a couple different
> video streams.
>
> I tried using OSProcess, but it gives me the pid of the shell script that
> launches the application, and not the application itself. I could certainly
> hack something using ps and grep, but I would prefer if there were a better
> way to do it.
>
> Any ideas?

Hi Jon,

If you are trying to interact with an external process, you probably want
CommandShell, which is a companion package meant to be used with OSProcess.
The base OSProcess package has various utility methods (quite ill-advised
with the benefit of hindsight) that run external programs under a unix
shell. I originally intended that as a convenience, but it turns out to
be more confusing than it is helpful.

What you probably really want to do is run a program and interact with
it directly by talking to its standard input stream and listening to its
standard output and standard error streams. In most cases, the class
PipeableOSProcess will do what you want. At a slightly higher level, if
you need the very loose equivalent of unix shell parsing, ProxyPipeline
may be a better fit. Slightly higher level, the class CommandShell
provides all of the above with the option of opening a view on the command
processing (much like a unix terminal window).

So, if you want to interact directly with an external program, do not
use OSProcess by itself. Load CommandShell and use one of the higher
level classes that does not try to "help" you by running your program
under /bin/sh.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

David T. Lewis
In reply to this post by Eliot Miranda-2
On Wed, Nov 18, 2015 at 06:36:10PM -0800, Eliot Miranda wrote:

> Hi Jon,
>
>    The
> primitive primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir:
> directly calls execute, so if you invoke it with the name of the program it
> will fork and exec that program and answer its pid.  Not sure where the
> substitution of the shell is.  Is omxplayer perhaps a shell script that
> wraps the actual program?
>
> I suggest you step though execution from your launch command all the way to
> the send of
> primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir:
> and see what its being invoked with, and you check what the omxplayer file
> is in the rip filesystem.
>
> (I could be completely confused but
> see UnixOSProcessPlugin>>#forkAndExecInDirectory: in the
> VMConstruction-Plugins-OSProcessPlugin package at
> http://www.squeaksource.com/OSProcessPlugin and I think you'll agree with
> me that the primitive does not interpose a shell).

Exactly right. The interposed shell is something that I added as a
convenience for some OSProcess class side methods. With the benefit of
hindsight, I never should have done that. I makes it look as though you
are running the program that you intended to run, but the actual process
proxy available in the image is just a proxy on /bin/sh, which is totally
useless.

The more useful classes that let the image interact directly with an
external process are in package CommandShell. CommandShell was originally
part of package OSProcess, and I split it out because I thought at the
time that modularity was a good thing. I still think that modularity is
a good thing, but ... well, it does have its down side ;-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

Jon Hylands
In reply to this post by David T. Lewis
David,

So I've installed CommandShell, and at first it appeared to work.

I could evaluate this:

CommandShell new processCommand: 'galculator'

and it would open the calculator, and the PID held inside the foreground proxies corresponded directly to the running app's pid.

However, when I run omxplayer, using this command line:

CommandShell new processCommand: 'omxplayer -r --live --win ''54 58 400 447'' http://localhost:10088/?action=stream'

I end up with our old friend, the shell pid and another process for omxplayer

I traced it in the debugger, all the way down to where the UnixOSProcessAccessor is sending #primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir:

The first argument to that message is '/usr/bin/omxplayer'

Yet I end up with this:

pi@raspberrypi ~ $ ps -ef | grep omx
pi        3182  3058  0 16:19 ?        00:00:00 /bin/bash /usr/bin/omxplayer -r --live --win 54 58 400 447 http://localhost:10088/?action=stream
pi        3190  3182  9 16:19 ?        00:00:19 /usr/bin/omxplayer.bin -r --live --win 54 58 400 447 http://localhost:10088/?action=stream

Why is this happening, and how can I fix it?

Thanks,
Jon



On Wed, Nov 18, 2015 at 10:56 PM, David T. Lewis <[hidden email]> wrote:
On Wed, Nov 18, 2015 at 09:12:51PM -0500, Jon Hylands wrote:
> Hi,
>
> I've been playing around with Squeak 5.0 on a pi 2 (with the 7" LCD
> touchscreen), and one of the things I'd like to be able to do is run (and
> control) omxplayer from within Squeak.
>
> I did the same thing with Python, using this library:
> https://github.com/willprice/python-omxplayer-wrapper/tree/develop/omxplayer
>
> However, I don't really need all the fancy controls - what I really want is
> a way to launch it, and then a way to kill it. I'll be streaming live MJPEG
> video from a webcam, so there is no concept of pause/stop/etc. I need to
> kill it because I want the ability to choose one of a couple different
> video streams.
>
> I tried using OSProcess, but it gives me the pid of the shell script that
> launches the application, and not the application itself. I could certainly
> hack something using ps and grep, but I would prefer if there were a better
> way to do it.
>
> Any ideas?

Hi Jon,

If you are trying to interact with an external process, you probably want
CommandShell, which is a companion package meant to be used with OSProcess.
The base OSProcess package has various utility methods (quite ill-advised
with the benefit of hindsight) that run external programs under a unix
shell. I originally intended that as a convenience, but it turns out to
be more confusing than it is helpful.

What you probably really want to do is run a program and interact with
it directly by talking to its standard input stream and listening to its
standard output and standard error streams. In most cases, the class
PipeableOSProcess will do what you want. At a slightly higher level, if
you need the very loose equivalent of unix shell parsing, ProxyPipeline
may be a better fit. Slightly higher level, the class CommandShell
provides all of the above with the option of opening a view on the command
processing (much like a unix terminal window).

So, if you want to interact directly with an external program, do not
use OSProcess by itself. Load CommandShell and use one of the higher
level classes that does not try to "help" you by running your program
under /bin/sh.

Dave





Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

Peter Crowther-2
On 19 November 2015 at 16:25, Jon Hylands <[hidden email]> wrote:
pi@raspberrypi ~ $ ps -ef | grep omx
pi        3182  3058  0 16:19 ?        00:00:00 /bin/bash /usr/bin/omxplayer -r --live --win 54 58 400 447 http://localhost:10088/?action=stream
pi        3190  3182  9 16:19 ?        00:00:19 /usr/bin/omxplayer.bin -r --live --win 54 58 400 447 http://localhost:10088/?action=stream

Why is this happening, and how can I fix it?


Bet you /usr/bin/omxplayer is a shell script - take a look.  If it is (i.e. its first line starts with #!/bin/bash) then this is what you'll get; you might wish to invoke omxplayer.bin directly.

- Peter


Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

Jon Hylands
Indeed you are correct.

I'll have to look into it, because it is a fairly complex bash script (107 lines).

Thanks,
Jon


On Thu, Nov 19, 2015 at 11:39 AM, Peter Crowther <[hidden email]> wrote:
On 19 November 2015 at 16:25, Jon Hylands <[hidden email]> wrote:
pi@raspberrypi ~ $ ps -ef | grep omx
pi        3182  3058  0 16:19 ?        00:00:00 /bin/bash /usr/bin/omxplayer -r --live --win 54 58 400 447 http://localhost:10088/?action=stream
pi        3190  3182  9 16:19 ?        00:00:19 /usr/bin/omxplayer.bin -r --live --win 54 58 400 447 http://localhost:10088/?action=stream

Why is this happening, and how can I fix it?


Bet you /usr/bin/omxplayer is a shell script - take a look.  If it is (i.e. its first line starts with #!/bin/bash) then this is what you'll get; you might wish to invoke omxplayer.bin directly.

- Peter






Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

David T. Lewis
It may turn out that interacting directly with that shell script is good
enough anyway, so I'd try that first. Depending on what the script is
doing, it may already be setting things up for you in a workable manner.
It's worth a try.

Dave

> Indeed you are correct.
>
> I'll have to look into it, because it is a fairly complex bash script (107
> lines).
>
> Thanks,
> Jon
>
>
> On Thu, Nov 19, 2015 at 11:39 AM, Peter Crowther <[hidden email]> wrote:
>
>> On 19 November 2015 at 16:25, Jon Hylands <[hidden email]> wrote:
>>
>>> pi@raspberrypi ~ $ ps -ef | grep omx
>>> pi        3182  3058  0 16:19 ?        00:00:00 /bin/bash
>>> /usr/bin/omxplayer -r --live --win 54 58 400 447
>>> http://localhost:10088/?action=stream
>>> pi        3190  3182  9 16:19 ?        00:00:19 /usr/bin/omxplayer.bin
>>> -r
>>> --live --win 54 58 400 447 http://localhost:10088/?action=stream
>>>
>>> Why is this happening, and how can I fix it?
>>>
>>>
>>> Bet you /usr/bin/omxplayer is a shell script - take a look.  If it is
>> (i.e. its first line starts with #!/bin/bash) then this is what you'll
>> get;
>> you might wish to invoke omxplayer.bin directly.
>>
>> - Peter
>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

timrowledge
In reply to this post by Jon Hylands
Hey Jon,
so trying to build a modern equivalent of the MediaPad eh?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: GLV: Ground the Line Voltage



Reply | Threaded
Open this post in threaded view
|

Re: Raspberry PI & omxplayer from Squeak

Jon Hylands
Tim,
Sorta kinda. I'm working on a side project for a group that protects endangered animals on game reserves in South Africa, and they want streaming video from their vehicles (they have wifi in most of the park).

If you guys have another Camp Smalltalk out your way in Jan-Mar next year, I'll probably come.

- Jon


On Thu, Nov 19, 2015 at 2:32 PM, tim Rowledge <[hidden email]> wrote:
Hey Jon,
so trying to build a modern equivalent of the MediaPad eh?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: GLV: Ground the Line Voltage