Mirrorcam and Draincam

[greengeek]

Sometimes it is handy to view one's own reflection as displayed by the webcam in your laptop - but sometimes it is handy to view an image from a second webcam or even a "draincam" - basically a camera used for remote inspection of drains or roof cavities etc.

This .pet installs two small RoxApps in /root
(You can move them wherever you wish)

(Built for Tahr but likely to work on a number of Pups and a number of machine types)
(Pre-requisite - this requires VLC - other versions to follow)

Mirror displays the output of video0 (inbuilt webcam)
Draincam displays the output of video1 (2nd webcam plugged into usb)

The icon was made up for the draincam function - would be nice to have a better one for the "mirror" one but oh well it will suffice for now.

Mirror.jpg (3.08 KiB) Viewed 1427 times

mirrorcam-0.0.pet

(5.36 KiB) Downloaded 60 times

Also : For systems that have mplayer installed - here is another version.
This version permits two external webcams ("DRAINCAMS") as well as the internal one ("MIRROR")

Mirrorcam_mplay-0.1.pet

(5.64 KiB) Downloaded 40 times

.
LowRes versions : To minimise "greenscreen" issues, or non-display of some cams due to usb bus bandwidth overload - I have made some versions that display a smaller image from the camera. See here

[mikewalsh]

@greengeek :-

Hmm. I've got something like half-a-dozen USB webcams kicking around the place, Ian (and something like a total of a dozen or so USB ports to choose from)! Any reason why this wouldn't work with multiple USB cams?

(The Pavilion desktop doesn't have a built-in cam, naturally......and the recently-acquired Dell Latitude was from a little before the time when Dell started fitting laptop cams OOTB, so USB cams are the order of the day here, too.)

What are you using to display the feeds?

Mike.

[greengeek]

Any reason why this wouldn't work with multiple USB cams?

No - as far as i am aware this will work with multiple cams (with appropriate selection of cam of course..) (ie via selection of /dev/videox inside the script)

The Pavilion desktop doesn't have a built-in cam, naturally......and the recently-acquired Dell Latitude was from a little before the time when Dell started fitting laptop cams OOTB, so USB cams are the order of the day here, too.)

As far as I am aware - inbuilt webcams are nothing more than USB cams "inside the box" - so there is no reason why a "plugged in" webcam should be any different. The key is to choose the correct /dev/video device that is attached to any webcam ("uvc web cam") that is plugged in. Typically the "inside the box" webcam is /dev/video0 as far as I know.

What are you using to display the feeds?

In my Tahr32 6.0.6 I have VLC as the default player so that is what displays the feed from /dev/video0 (or /dev/video1)

I guess (hope) this could be any suitable video player (even MPV??) on other systems.

(But I think I am generations behind what current users have in terms of hardware and software. Most of my systems must be 10+ years old...)

[greengeek]

...and something like a total of a dozen or so USB ports to choose from!

A dozen or so?? What is this? You are connecting to the internet from a Christmas tree???
(Merry Christmas!)

[mikewalsh]

@greengeek :-

Heh. Let me just put it this way; if you add together the multitude of USB ports this Pavilion desktop has, both front AND back.....then add the 7-port, self-powered hub into the mix.....it actually gives me a total of 15 usable ports!

The 7-port hub is a left-over from the old Compaq desktop, but it still functions as well as it ever did, so.....why not? You can never have too many USB ports; in my case, all my dongles plug into this. Keeps 'em tidy, and keeps 'em all together in the same place.

------------------------------------------------------

Anyways, I owe ya one for giving me a metaphorical "kick up the backside", mate. As I said, I have several cams tucked away in drawers & cupboards, here and there. I've been mulling over the concept of a utility to control multiple webcams for a couple of years, but just never seemed to get around to it.

This thread finally prompted me to get off my lazy backside and actually research what was needed to implement it...

-----------------------------------------------------

I don't use VLC that much; mostly in a couple of older 32-bit Slackos I run. Just about every other Pup uses mPlayer, SMPlayer and/or MPV. So; I researched what was needed for mPlayer to deliver the goods, and came across a blog post that gave me the perfect command-line stanza to do just this. And I "borrowed" it...

Essentially, both cams use this same line in their individual scripts:-

Code: Select all

mplayer tv:// -tv driver=v4l2:device=/dev/video0:width=864:height=480:fps=25:outfmt=yuy2

You just modify the /dev/video 'identifier', and the window width and height to match preset resolutions for the individual camera. Experimentation shows that if you try to use a resolution that's NOT supported by the camera, mPlayer complains like a good 'un, and refuses to 'play ball'.

----------------------------------------------------

I've built a wee YAD-based GUI for the thing.....which I call "MultiCam". The launch script checks first to see if your Puppy has yad installed - not everybody does! - and if not, depending on your Pup's architecture a 'generic' 32-bit or 64-bit version of v0.40.0 is temporarily sym-linked into place for the duration of the session. This is removed again at close.

The GUI includes an "Identify" button. When you click on this, a small console window comes up & gives you a list of whatever video devices are found on your system. This helps you to get the correct /dev/video "x" number for each camera's script.

For the "Identify" button to work, you will need to install

Code: Select all

v4l-utils

....from your Pup's PPM. It's a tiny package, so nothing to worry about, but it includes the "v4l2-ctl" binary needed for this. In your case, you probably don't need this bit, because you already know what identifiers work for you.

As-is, it requires mPlayer on the system. For anybody using VLC, there's no reason they can't use the commands in your AppRun scripts. It should work either way.

The usual scripts to be found in my portables will add a Menu entry IF one is wanted. I've also added an AppRun link to the 'LAUNCH' script, so it will function as a ROX-App, too.

--------------------------------------------------

I've got vague plans for using this in a "basic" home security system, so's I can have cams watching both front & back of the house. Just need to figure out the best way of setting the cameras up, and how they need to be wired-in....

Should you, or anyone else be interested, MultiCam-portable can be found at MediaFire, here:-

https://www.mediafire.com/folder/agj8tl2mctt8l/MultiCam

Usual caveats apply:-

• Download

• Unzip

• Put it anywhere you like, though outside the save is best

• Click to run as a ROX-App, or rt-clk->"Look inside" to enter the directory, if you need to access the scripts for editing or whatever

Call it an early Xmas prezzie, Ian. Enjoy!

Mike.

[rockedge]

@mikewalsh Is the xeoma package to heavy for this application? I can hook up and simutaneously view, motion detect on as many web cams as my systems can handle with Zoneminder. Kind of heavy though to install.

Maybe a small utility that uses the VLC libraries or multi instances of ffmpeg to stream multi web cams could be written?

Most of my systems can handle 2 web cams if it needs to do the encoding but not more.

[mikewalsh]

@rockedge :-

Oh, Xeoma's fine, Erik. For me, it's not "heavy" at all.

No, all I'm really after is the ability to set a couple or three cameras up where I need them, and to be able to view whichever I want, whenever I want. I'm not really after recording ability, or motion detection.....this is going to be more of a glorified "remote videocall intercom", if ya like; simply "on-demand" when I want to look at things.

Yes, there's plenty of commercially available offerings out there, but it's more fun if you can develop something to suit yourself.....rather than having to use somebody else's work all the time.

(I've been a member of the Linux.org Forum since August, and I've already discovered some of the staff over there are real stick-in-the-muds. One global mod over there is of the firm opinion that no 'user' should ever try to create their own software; you should ALWAYS use "professionally-created" software coded, compiled & built by somebody else...

????????

We were discussing compiling Nvidia driver .run files. I volunteered about the fact that Shinobar's Get-Nvidia has kind of become the defacto standard among Puppians when it comes to the "official" drivers, and that we always build our own. This mod pooh-poohed that, insisting that it's far safer to install the exact same item that some 'maintainer' has compiled for the official repos......because they know what they're doing! To which I replied that said 'maintainer' would have still had to use that same .run file to create the "official" package, so where was the difference between said 'maintainer' doing it and me doing it myself..?

Well, he really "went off on one"; insisting that users should be JUST that.....a "user", and nothing more. As though being part of the official dev team conferred some kind of magical abilities upon you, and that being a "user" meant you couldn't possibly have any technical abilities at all, and that the only thing any "user" needed to learn was how to install stuff from the official repos.....I gave up & let the matter drop, realising that you can never win against a narrow viewpoint like this. To this kind of individual, the sort of things we do on a daily basis here in Puppyland is nothing but sheerest sacrilege; how DARE we try to do stuff that should only be tackled by those officially sanctioned to do so?)

*Jeez...*

Enough of these "red herrings..! Sorry to drag your thread off-course, Ian. Now; where were we....?

Mike.

[wizard]

@mikewalsh

One last diversion just for laughs.

Mark Twain — 'Never argue with stupid people, they will drag you down to their level and then beat you with experience.'

Thanks
wizard

[rockedge]

I think setting up a yad GUI or gtkdialog version that can synthesize the argument line(s) for FFMPEG or MPV instances that can be used to stream and view have potential. More advanced examples using PERL or Python are around that demo the basics to stream a web cam. I have run across bash script that chains together utilities to do the job and then viewed by a client using VLC libraries or a command line VLC.

Probably some pretty nifty ways of doing somethng simple to get started on the project. Use droidcam and old mobile phones that can connect to wifi

There are examples of simple python programs that use opencv (which I have sucessfully installed and used in Puppy Linux for Darknet and other web cam video) that show how to create client viewer instances.

You might be able to run 2 instances of guvcview and just selecting the correct /dev/vidoe0 and /dev/video1 for each one. Could try the same with multipule instances of VLC maybe......depends if it's possible to start more than 1 instance at a time.

a nice yad box...pick the cams.....see the streams......

[greengeek]

Heh. Let me just put it this way; if you add together the multitude of USB ports this Pavilion desktop has, both front AND back.....then add the 7-port, self-powered hub into the mix.....it actually gives me a total of 15 usable ports!

Nice!

For the "Identify" button to work, you will need to install

Code: Select all

v4l-utils

....from your Pup's PPM. It's a tiny package

Thanks for the tip. Probably something that's small enough to be added to every pup

The usual scripts to be found in my portables will add a Menu entry IF one is wanted. I've also added an AppRun link to the 'LAUNCH' script, so it will function as a ROX-App, too.

For some reason not showing as a Roxapp on my Tahr32 - clicking just opens the directory.

Usual caveats apply:-

• Download

• Unzip

• Put it anywhere you like, though outside the save is best

• Click to run as a ROX-App, or rt-clk->"Look inside" to enter the directory, if you need to access the scripts for editing or whatever

Hmmm, tried clicking LAUNCH to no avail - then used cli and got this:

Code: Select all

root# ./LAUNCH
Unable parse command line: Unknown option --buttons-layout=right

Quite possibly one too many christmas wines so will revisit tomorrow - but do you have any tips?
Cheers!

[greengeek]

I think setting up a yad GUI or gtkdialog version that can synthesize the argument line(s) for FFMPEG or MPV instances that can be used to stream and view have potential.

I use the following syntax to record from webcam via ffmpeg:

Code: Select all

ffmpeg -f v4l2 -framerate 25 -video_size 320x240 -i /dev/video0 output320x240.mkv

- but have not found a way to display webcam feed via ffmpeg. Seems to need some other server software to receive. (In which case VLC and Mplayer seem to be easier methods)

Interesting link:
https://prabuselva.github.io/linux/hack ... streaming/

[rockedge]

@greengeek This will put you in the driver's seat : https://github.com/klaxa/mkvserver_mk2 with a solid solution for streaming a FFMPEG feed.

I used ffserver in the past but it is depreciated and the Dev's of ffmpeg recommend mkvserver_mk2, which I will be trying out also for the first time. This looks better and easier to use than ffserver looking it over.

UPDATE: Successfully compiled the package. I can make it available if there is interest in working with it.

[rockedge]

I got it to work somewhat with the compiled server program and displayed with mpv....needs some refinement on my part.....

Screenshot(1).jpg (66.54 KiB) Viewed 1298 times

Though I tested your command line then only using mpv and no server in between (this will only work locally I think):

Code: Select all

ffmpeg -f v4l2 -framerate 25 -video_size 320x240 -i /dev/video0 output320x240.mkv

with :

Code: Select all

mpv /root/output320x240.mkv

And that seemed to work better with a lot less latency. Further experimenting needed.....

[mikewalsh]

@greengeek :-

No, it's not you, Ian! My architecture detection sub-routine wasn't working the way I thought it was. Trying to be too clever, and trying to run before I could walk....

I've added this sub-routine because some older Puppies - Tahrpup included - still come with a very old version of YAD OOTB. In your case, you've got v0.12.8.....and a couple of the features my wee GUI makes use of require v0.38.0 or newer. So I've included two 'generic' YAD binaries of v.0.40.0.....one 32-bit, one 64-bit.

I was trying to make use of the 'uname -m' command to detect OS architecture, but I couldn't seem to make it work with the "if....then....else" routine. It then occurred to me that there was an even simpler way to detect if Pup is 32-bit or 64-bit.....using something unique to Puppy, the /etc/DISTRO_SPECS file. Every Puppy has one, and 64-bit Puppies all have "64" somewhere in that file. 32-bit Puppies don't. So all that was needed was to add a line to grep for "64" in that file, then "if....then....else" can sym-link the appropriate YAD binary into place after moving the original YAD binary into /tmp just for the duration of the session.

At session close, the original YAD binary will be moved back into /usr/bin. This will work better for you; you don't run with a save-file, so you would otherwise have to re-install a newer version of YAD every time you wanted to use this. This way, you don't need to.

If it won't run as a ROX-app - which it should - just go into the directory and delete the "AppRun" link. Then fire it up via the LAUNCH script as usual. Use 'MenuAdd' to add a Menu entry if you want to keep it.

Re-download the portable from the link I gave. You should now get the re-worked version, which ought to work for you. Don't forget, you'll want to substitute your VLC commands for the mPlayer commands I've used. Let us know how you get on with it, please.

Mike.

[greengeek]

Re-download the portable from the link I gave. You should now get the re-worked version, which ought to work for you. Don't forget, you'll want to substitute your VLC commands for the mPlayer commands I've used.

Thanks - Now working well. (Only tested with Mplayer so far, and just using the inbuilt webcam as all my computing stuff is in a mess at the moment due to a re-roof nightmare that has us living in very cramped quarters).

Couple of comments:
- Yad "about" display is very cool!
- "MenuAdd" is a handy feature.
- I did have a problem with the Detection routine - A terminal screen popped up saying "unable to execute child" (see pic below)

I tried manually running the "Cam_Identify.sh" and got the following result:

Code: Select all

root# ./Cam_Identify.sh
urxvt: "rxvt": malformed option.
urxvt: "ls": malformed option.

Maybe something to do with my urxvt?
.

childfail.jpg (29.1 KiB) Viewed 1261 times

[greengeek]

This will put you in the driver's seat : https://github.com/klaxa/mkvserver_mk2 with a solid solution for streaming a FFMPEG feed.

I used ffserver in the past but it is depreciated and the Dev's of ffmpeg recommend mkvserver_mk2, which I will be trying out also for the first time. This looks better and easier to use than ffserver looking it over.

UPDATE: Successfully compiled the package. I can make it available if there is interest in working with it.

Thanks for the link - just had a look at this but can't decide if it is 32bit capable (I assume 64bit only?). Unzipped the package and it obviously needs compiling (yikes! not my strong point).

Sounds like a project that he has been working on for quite some time so it would be great if this is now a properly functioning mechanism that could enable remote streaming as well as local.

[mikewalsh]

@greengeek :-

- I did have a problem with the Detection routine - A terminal screen popped up saying "unable to execute child" (see pic below)

I tried manually running the "Cam_Identify.sh" and got the following result:

Code: Select all

root# ./Cam_Identify.sh
urxvt: "rxvt": malformed option.
urxvt: "ls": malformed option.

Maybe something to do with my urxvt?
.
childfail.jpg

No, it's a simple 'fix'. The detection routine uses 'v4l2-ctl".....it's part of the wee "v4l-utils" package from the PPM, which I mentioned above. I haven't included a 'generic' version of this, because I don't know if it's distro-specific or not....but it's less than 1 Mb installed.

(Nowt to do with your urxvt, either. It's something to do with the way I call that small black-on-yellow terminal window, though I've been using that same routine in modified format across several apps this last couple of years. It always complains of an error.....yet it always works, and does what I want it to. So I tend to ignore it.)

From long experience with YAD, I know for a fact that it seems to make NO difference what Puppy you compile it under, it will run under ANY Puppy of that same architecture.

Mike.

[greengeek]

No, it's a simple 'fix'. The detection routine uses 'v4l2-ctl".....it's part of the wee "v4l-utils" package from the PPM, which I mentioned above. I haven't included a 'generic' version of this, because I don't know if it's distro-specific or not....but it's less than 1 Mb installed.

Ah yes of course. Thanks. Forgot to install that. Will retest detection shortly.

In the meantime i found a second webcam and see that multicam is able to display either camera - but not both at once (whichever cam is selected 2nd displays a green screen). Same effect if i manually use mplayer to display one cam and cvlc to display the other simultaneously. Probably busy resource on v4l i suspect.

Do you see this issue?

[mikewalsh]

@greengeek :-

In the meantime i found a second webcam and see that multicam is able to display either camera - but not both at once (whichever cam is selected 2nd displays a green screen). Same effect if i manually use mplayer to display one cam and cvlc to display the other simultaneously. Probably busy resource on v4l i suspect.

Do you see this issue?

A-HA. Right, so.....you're seeing it too? Interesting. I thought that was just me...

At one point, I was testing with 3 webcams on the big rig. Any two of them WOULD display simultaneously, but the third one came up with.....yup; you guessed it. A "green screen".

ATM, I'm in the front room using the 'new' Dell Latitude lappie. I'm only using two cams here, but again, same thing. Either cam will work by itself, but the other one shows a "green screen" if I try to display both. So; I'm wondering now. Is this actually a shortcoming of mPlayer, or is it an issue because we're using v4l2? Might things work differently if, say, ffmpeg was used instead?

I don't mind admitting, ffmpeg scares me! If the various references & code-snippets I've seen over the last few years are anything to go by, selecting the correct options for the darned thing requires a college degree of some sort. There must be millions of them, because absolutely EVERY single parameter has to be indicated via yet another "--switch"!

More research would seem to be indicated.

(EDIT:- Curious. I now find with the modified v0.3, that on the big rig it doesn't matter if 2 cams are plugged-in or 3.....2 cams will always display at the same time. Yet on the Latitude you'll only ever get one showing at any given moment.

I can't remember where it was now, but I did catch a quick glimpse at some blog post about mPlayer, where they were talking about the app only displaying devices once per USB hub. I've got three here; the internal one in the Pavilion, and the external, 7-port, self-powered hub. (Which is actually built, it seems, from a pair of "overlapping" 4-port hubs. No, I can't work that out, either. Unless they mean the second 4-port hub is plugged-into one of the first hub's 4 ports.....leaving 3? Working via daisy-chain? Can you DO that with USB??))

--------------------------------------------------

Currently, I've been modifying MultiCam to add further code which will now allow the user to record, play back and finally save a stream from either cam. This last item is a lightly modified 'demo' command, using v4l2, that I found on the Arch Linux Wiki. Very useful site, that.

Selecting "REC 1 ?" or "REC 2 ?" will bring up the media toolbar with the basic controls on it. You can record, stop recording, play back what you've just captured and, if happy with the result you can then 'save' the .avi video file. 'Saving' moves the file from within the portable, and by default moves it into /root. The only snag, ATM, is that while recording there's no 'live' display of what's being captured; I haven't figured this bit out yet.

I've re-uploaded, and the new v0.3 build is now at the same link:-

https://www.mediafire.com/folder/agj8tl2mctt8l/MultiCam

We'll have to investigate what's going on with these "green screens"..!

Mike.

[greengeek]

At one point, I was testing with 3 webcams on the big rig. Any two of them WOULD display simultaneously, but the third one came up with.....yup; you guessed it. A "green screen".

Hmmm, suggests possibly a resource bandwidth issue? Bigger machine handles more throughput??

ATM, I'm in the front room using the 'new' Dell Latitude lappie. I'm only using two cams here, but again, same thing. Either cam will work by itself, but the other one shows a "green screen" if I try to display both. So; I'm wondering now. Is this actually a shortcoming of mPlayer, or is it an issue because we're using v4l2? Might things work differently if, say, ffmpeg was used instead?

I think Mplayer is off the hook. Two reasons:
Firstly I have the same problem when I use vlc (or cvlc) instead of Mplayer (even when manually using the cli).
Secondly - I have had similar "green screen" issues when using ffmpeg to process video. So i suspect "greenscreen" is just a generic response to problems handling video frames. (Which may implicate Vl42 or perhaps video hardware?)

I don't mind admitting, ffmpeg scares me! ...
More research would seem to be indicated.

I googled "ffmpeg green frames" and found this interesting link:
https://stackoverflow.com/questions/703 ... creen-only
(Probably totally unrelated but maybe a pointer to what - in general - can trigger green frames)

Curious. I now find with the modified v0.3, that on the big rig it doesn't matter if 2 cams are plugged-in or 3.....2 cams will always display at the same time. Yet on the Latitude you'll only ever get one showing at any given moment.

Just tried v0.3 but no change for me. Maybe video gpu and/or driver comes into play? Maybe hardware processing power determines what is possible?

I can't remember where it was now, but I did catch a quick glimpse at some blog post about mPlayer, where they were talking about the app only displaying devices once per USB hub. I've got three here; the internal one in the Pavilion, and the external, 7-port, self-powered hub. (Which is actually built, it seems, from a pair of "overlapping" 4-port hubs. No, I can't work that out, either. Unless they mean the second 4-port hub is plugged-into one of the first hub's 4 ports.....leaving 3? Working via daisy-chain? Can you DO that with USB??))[/i]

Interesting. Certainly seems like 3+4=7. I believe such a thing can work - but overall capabilities are impacted (ie Booting not supported in such an arrangement). I would also guess overall throughput drops significantly.

Selecting "REC 1 ?" or "REC 2 ?" will bring up the media toolbar with the basic controls on it. You can record, stop recording, play back what you've just captured and, if happy with the result you can then 'save' the .avi video file. 'Saving' moves the file from within the portable, and by default moves it into /root.

Awesome. Love this! Works well so far.

[greengeek]

Selecting "REC 1 ?" or "REC 2 ?" will bring up the media toolbar with the basic controls on it. You can record, stop recording, play back what you've just captured and, if happy with the result you can then 'save' the .avi video file. 'Saving' moves the file from within the portable, and by default moves it into /root. The only snag, ATM, is that while recording there's no 'live' display of what's being captured; I haven't figured this bit out yet.

Question - would you expect that recording from both cams simultaneously might be possible?
I tried to do this but got myself confused about which cam I was controlling at what time. (My thinking was that recording multiple streams may be easier than displaying them).
Might it be possible to add timestamps to the saved video to help identify if the .avi captures are original or overwrites? (ie: do you think the REC feature is automatically overwriting previous attempts?)
Love the record feature. (Keen to use this to record the outcome of a rust inspection inside the chassis of my small truck)

[mikewalsh]

Question - would you expect that recording from both cams simultaneously might be possible?
I tried to do this but got myself confused about which cam I was controlling at what time. (My thinking was that recording multiple streams may be easier than displaying them).

To be honest with you, Ian, I really don't know! This mPlayer command-line stuff is all new to me.

Like I said, I had the idea for this kicking around in the back of my skull for a long time, but initially, I wouldn't have even known where to start. As you spend more time with all this kind of stuff, you gain more experience, you learn more tricks/newer, better ways to accomplish things, and over the course of time you even learn how to research more effectively! I've always done my own research anyway, but I'm just that much better at it than, say, 10 or 15 years ago.

Might it be possible to add timestamps to the saved video to help identify if the .avi captures are original or overwrites? (ie: do you think the REC feature is automatically overwriting previous attempts?)
Love the record feature. (Keen to use this to record the outcome of a rust inspection inside the chassis of my small truck)

Way ahead of you there, mate. I was wondering how to best achieve something like this a couple of days ago. I've added some modified code from various other portable apps, along with "borrowing" some code MochiMoppel generously donated several months ago when a few of us were putting together an audio capture app for those of us with "awkward" audio cards.

When the portable is launched, an extra directory is created inside the portable's directory, called "MultiCam". Inside this a directory is created called "SAVED". And inside that, two more are created, called "Cam1" and "Cam2". This directory is then sym-linked into /root while the app is running; just easier to find here.

When you 'Save' any recorded webstream, it will save it to the appropriate directory for that camera. Camera 1 will save to "Cam1", and camera 2 will save to "Cam2". Instead of date-stamps, what I've done is to make it so that each subsequent file is numbered one higher than the previous. So, you get "streamcap-1.avi", "streamcap-2.avi", "streamcap-3.avi", and so on. (This is courtesy of Mochi's code, slightly modified).

That whole "MultiCam/Save" directory remains within the portable at all times. At close, the sym-link in /root is removed again. Keeps everything together in one place.

------------------------------------------

You can also set things up to record audio from your webcam's microphone if you want. Initially, open up a terminal and enter

Code: Select all

arecord -l

.....which will list all capture devices attached to your system, OK? Next, go into the portable directory->DATA->MEDIA->Cap1->Record. Look at lines 19 & 22:-

Look for adevice=/dev/audiox. This 'x' wants to be the same as the appropriate 'hw:x' for your webcam's mike as revealed by 'arecord -l'. In other words:-

If 'arecord -l' says your webcam's mike is hw:2,0, then edit that clause to read 'adevice=/dev/audio2'. mPlayer is like XVidCap; it uses the older OSS terminology for audio cards, where everything on your system was '/dev/something-or-other'. (You'll still see this if you look in the /dev directory; every audio device is 'audio(x)').

The numbers will always match, but the older terminology is being used.

--------------------------------------------------------

I've re-uploaded the current version to the same link, so if you want to take a look and see what additions I've made, you're very welcome to do so. I'll say this much; I'm getting quite pleased with what's been achieved to date..!

See what ya think of it so far. Enjoy.

Mike.

[greengeek]

When the portable is launched, an extra directory is created inside the portable's directory, called "MultiCam". Inside this a directory is created called "SAVED". And inside that, two more are created, called "Cam1" and "Cam2". This directory is then sym-linked into /root while the app is running; just easier to find here.

When you 'Save' any recorded webstream, it will save it to the appropriate directory for that camera. Camera 1 will save to "Cam1", and camera 2 will save to "Cam2". Instead of date-stamps, what I've done is to make it so that each subsequent file is numbered one higher than the previous. So, you get "streamcap-1.avi", "streamcap-2.avi", "streamcap-3.avi", and so on. (This is courtesy of Mochi's code, slightly modified).

That whole "MultiCam/Save" directory remains within the portable at all times. At close, the sym-link in /root is removed again. Keeps everything together in one place.

I can display each webcam fine - but unfortunately on my system v0.4 REC does not create any output (that i can find...)
I can see the /SAVED/Cam1 and /SAVED/Cam2 directories but they remain empty.
Maybe my directories are too deep. Here is my path:

path.jpg (28.22 KiB) Viewed 1236 times

EDIT: Don't know if this helps but this is the output if I manually drive Record1
(Not sure why it is looking for audio4 - maybe best if it was not trying to record audio at all?)

Code: Select all

root# ./Record1
MEncoder SVN-r37363-snapshot-4.6 (C) 2000-2015 MPlayer Team
success: format: 9  data: 0x0 - 0x0
TV file format detected.
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski <olschewski@zpr.uni-koeln.de>
 comment: first try, more to come ;-)
v4l2: your device driver does not support VIDIOC_G_STD ioctl, VIDIOC_G_PARM was used instead.
Selected device: USB2.0 UVC WebCam
 Capabilities:  video capture  streaming
 supported norms:
 inputs: 0 = Camera 1;
 Current input: 0
 Current format: YUYV
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Inappropriate ioctl for device
Error: Cannot set norm!
Selected input hasn't got a tuner!
Unable to open '/dev/audio4': No such file or directory
Unable to open '/dev/audio4': No such file or directory
Unable to open '/dev/audio4': No such file or directory
v4l2: ioctl set mute failed: Invalid argument
v4l2: 0 frames successfully processed, 0 frames dropped.
============ Sorry, this file format is not recognized/supported =============
=== If this file is an AVI, ASF or MPEG stream, please contact the author! ===
Cannot open demuxer.

Exiting...

[mikewalsh]

@greengeek:-

Ian:-

I can display each webcam fine - but unfortunately on my system v0.4 REC does not create any output (that i can find...)
I can see the /SAVED/Cam1 and /SAVED/Cam2 directories but they remain empty.

That's because of that /dev/audio4 for Camera 1.....and you'll find it shows /dev/audio5 for Camera 2. That's how the two webcams are recognised on my system. The Logitech c920 shows as

Code: Select all

hw:4,0

.....when I run "arecord -l" in a terminal, so that becomes

Code: Select all

/dev/audio4

.....in the /DATA/MEDIA/Cap1/Record script. Yours will need modifying to match the number for your own webcam.

Similarly, the other cam - a Microsoft HD3000 LifeCam - shows as

Code: Select all

hw:5,0

.....when I run "arecord -l", so that then becomes

Code: Select all

/dev/audio5

.....in the /DATA/MEDIA/Cap2/Record script.

You need to run

Code: Select all

arecord -l

.....in a terminal, and see what "hw:x,y" number you get for each device. Then edit each 'Record' script to use that "x" number to replace the number in "/dev/audio'x'". Make sense? I, too, found that just one single wrong number in the 'Record' script meant it wouldn't run; it simply quit on me....

(On MY system:-

hw:0,0 is my system audio card
hw:1,0 is the 'PC speaker'
hw:2,0 is the HDMI output from my Nvidia GPU
hw:3,0 is the audio card for my wireless headset

.....so hw:4,0 and hw:5,0 are the next two available inodes for audio devices.)

Mike.

[mikewalsh]

@greengeek :-

Nearly forgot, Ian. If you're in Tahrpup, you'll need to look for, and install

Code: Select all

mencoder

.....from the PPM. I'm gradually "installing", or at least getting MultiCam functional, across the kennels; I'm currently in Tahrpup myself ATM, and found I needed to install it.

Usually, you have to install mPlayer if you want it. Some Puppies come with mPlayer OOTB. Even these, however, often only install the media player part of the package; so, if you want to record/encode/rip/whatever, you need the mencoder package. This is the binary that contains all of mPlayer's media encoding stuff.

mPlayer functions perfectly well without it, but ONLY as a player.

Mike.

[greengeek]

Code: Select all

arecord -l

.....in a terminal, and see what "hw:x,y" number you get for each device. Then edit each 'Record' script to use that "x" number to replace the number in "/dev/audio'x'". Make sense? I, too, found that just one single wrong number in the 'Record' script meant it wouldn't run; it simply quit on me....

Thanks - i had previously tried changing the "4" to a "0" to match my hardware (as you suggested originally) but still had the problem. I begin to suspect that I may not have the mp3lame codec. (I seem to recall similar ffmpeg issues)
(I definitely have mencoder as part of the Mplayer pet I use - "mplayer-2015-01-26-i686.pet". Don't remember where that came from but definitely includes mencoder)

I have tried to find a cli command that lists installed codecs but so far no joy...

I have looked at this page and I don't find mp3lame anywhere...:
http://www.mplayerhq.hu/DOCS/codecs-status.html

EDIT : Found this useful command and it suggests that I have mp3lame available so can't be the problem i guess:

Code: Select all

root# mencoder -oac help
MEncoder SVN-r37363-snapshot-4.6 (C) 2000-2015 MPlayer Team
Available codecs:
   copy     - frame copy, without re-encoding (useful for AC3)
   pcm      - uncompressed PCM audio
   mp3lame  - cbr/abr/vbr MP3 using libmp3lame
   lavc     - FFmpeg audio encoder (MP2, AC3, ...)
   faac     - FAAC AAC audio encoder
root# 

EDIT2 :

Code: Select all

root# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: MID [HDA Intel MID], device 0: ALC268 Analog [ALC268 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

(This is with my external webcam plugeed in so i guess it has no internal soundcard or mic.... )

[greengeek]

I decided to try recording only video - so I modified lines 19 etc as follows:

Code: Select all

	mencoder tv:// -tv driver=v4l2:width=800:height=448:device=/dev/video0 -ovc lavc -o $HERE/streamcap.avi
else
	sleep 0.75
	mencoder tv:// -tv driver=v4l2:width=800:height=448:device=/dev/video0 -ovc lavc -o $HERE/streamcap.avi

And now at least the recording works in v0.4 - but playback seems half speed.

Will do a bit of research about the mencoder syntax and look at possible options.

[mikewalsh]

@greengeek :-

Heh. I'm having the same issue, except mine is kind of opposite to yours, if you like. When I play back after recording, audio is at normal speed.....but video is playing back at 2x the speed it should (as though it were fast-forwarding?)

This is ONLY in 32-bit Tahrpup. With every other member of the kennels, it's so straight-forward it's humdrum. I wonder if it's related in any way to the fact that for this release only, someone at Canonical decided to replace ffmpeg with the "forked" avplay instead....??

Will do a bit of research about the mencoder syntax and look at possible options.

Good luck with that. The mPlayer documentation is "comprehensive", to say the least.....like a small stack of Bibles! I very quickly got lost, due to sheer number of options. At this point, I'm out of ideas...

Mike.

[rockedge]

You will have much better results in Tahr using a Static FFMPEG. @mikewalsh has experience using the static ffmpeg versions.

Yes the avplay and other the replacements for ffmpeg cause many unexpected results.

[mikewalsh]

@rockedge :-

My usual tactic in Tahrpup32 is to

1. Replace the anemic, feature-deficient original ffmpeg with the static, 3.3.2 build from John van Sickle.
2. Delete /usr/bin/avplay.
3. Create a sym-link, called "avplay", to the upgraded JvS ffmpeg binary.

This seems to work quite well. Admittedly, I myself was made aware of this by another Puppian on the old Murga forums; can't remember who it was, though.

-------------------------------------------------------

Precise used ffmpeg as normal. Somebody at Canonical apparently thought the then-in-the-news 'avplay' fork sounded like a good project to support; this was around the time the two projects split & went their separate ways, so this was what 'Trusty' got. Tellingly, however, ffmpeg was firmly back in the driving seat by the time Xenial Xerus was released.....so others besides us must also have found it wasn't all it was cracked up to be!

I'm very glad either Fred or Will - can't remember who it was - discovered these static builds from JVS. I know Puppy's ffmpeg builds were always traditionally kept tiny along with everything else, but the JvS builds make so much stuff functional in a way that the original, minimal Puppy ffmpeg build never seemed to be able to. And hardware resources - and consequently, RAM/storage space - for many of us are no longer anywhere near such an issue as they once would have been...

Mike.