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 |
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:
_,,,^..^,,,_ best, Eliot |
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 |
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 |
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: |
On 19 November 2015 at 16:25, Jon Hylands <[hidden email]> wrote:
- Peter |
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:
|
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 >> >> >> >> > > |
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 |
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, |
Free forum by Nabble | Edit this page |