Xvidcap....in 'portable' format. A long-standing Linux app - and a 'proper' Puppy size!

[mikewalsh]

Evening, gang.

I'm well aware that many of my recent 'portable' offerings have been rather on the large side, size-wise. Admittedly, much of this is engendered by having that 32GB of RAM.....an upgrade I was determined to go for after years of being limited to just 3 GB of the stuff (and DDR first-gen, at that!) The freedom to do anything I want without worrying about running out of space is quite refreshing....but it DOES mean I'm not really thinking like a true 'Puppian' any longer. This offering will hopefully redress the balance, and prove to y'all that I still think about those stuck with more limited hardware.

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

I've always loved Xvidcap's quirky interface; it appeals to the inner child, I think. This is someone who was obsessed with Lego, Joe 90, Captain Scarlet, Meccano, etc, etc, as a kid. I was always accustomed to thinking outside the box, and often approached problems from a lateral direction, coming up with some highly 'original' solutions of my own.

Xvidcap has always faithfully recorded video in my Pups, but audio has been a saga all of its own. The bulk of the issue has come from the fact that most recording/playback apps use the "hw:x,x" nomenclature, which we all of us understand (at least, I think we do). Xvidcap, on the other hand, has been kicking its heels around the Linux landscape for so many years that it was written to look for a character, 'block' device; "/dev/something-or-other".....in other words, the actual inode that the kernel creates to communicate directly with various devices, BEFORE it gets muffled by layer upon layer of software. This is my understanding of the concept, though it's possible I'm barking up the wrong tree....

That aside, I have sussed-out how to make Xvidcap communicate with our currently-defined audio hardware. I posed the question on the forum just the other day; Fred made a couple of suggestions, which set me on the correct path at long last. I can now record audio, using Xvidcap, via either my webcam's built-in microphones OR the headset's plug-in 'boom' mike. Which I'm really, really chuffed about!

(*They say little things please little minds, don't they?*) Couldn't care less, me; this is summat I've been chipping away at, on & off, for years, and I'm just pleased to have finally 'cracked it'. All thanks to Uncle Fred..!)

Okay. So; how does this work?

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

If we go into the /dev directory, we should find various character, 'block' device files labelled 'audio', audio2', 'audio3', etc. These appear to correspond to the ALSA 'hw:x,x' labelling system. So; 'audio' should correspond to 'hw:0,0'; 'audio2' should correspond to 'hw:2,0', etc.....and so on, and so forth.

Rt-click the Xvidcap 'counter' to access 'Preferences'->tab 'Multi-frame', then this is what works for me:-

• File format:- Untick the 'Auto' check box. Select 'Microsoft Audio Video Interleaved File (avi)'.

• Video Codec:- Leave the 'Auto' box checked. This will set itself to 'Microsoft DIVX 2' (I told you this thing had been around for ages, didn't I? How long is it since DIVX had any kind of market share or presence, huh?) BUT; it works....and way better than any of the other options, too.

• Under 'Audio Settings', tick the box to 'Enable Audio'. For 'Input Device', having figured out the /dev/audio equivalent to the ALSA name for your microphone's card, click the three dots to the right, and navigate through the file system to it, and enter that as the required device.

• Audio Codec:- Leave the 'Auto' box checked; this will set itself to 'MP3'.

• Make other adjustments to suit yourself, but I use:-
  Sample rate=44100 (44.1k)
  Bit rate=64000 (64k)

All things being equal, you'll now be able to record audio with Xvidcap...

(I suspect Xvidcap expects to find MPlayer on the system. At any rate, it appears to look for it in order to play back the clip you've just recorded, at 'close of play'. If not present, close the app, look for your clip wherever you've set it to save them to, then fire it up with your default media player.)

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

If anybody's interested, you can find both 32-bit and 64-bit portable versions here:-

https://mega.nz/folder/2XonxASQ#0eja7qnZMRKEV7EEFPP6Ug

.... or here:-

https://drive.google.com/drive/folders/ ... sp=sharing

Usual stuff applies; d/l; unzip; move the 'portable' directory anywhere you like, though preferably outside the 'save'. Click to enter, click 'LAUNCH' to fire it up. Config stuff is created within the portable, and sym-linked out to the expected locations at run-time. Links are removed again at close.

You can use the included scripts to add a Menu entry from wherever it's located. The 'MenuReadMe' explains how to use these.

Have fun with it, y'all. Enjoy!

Mike.

[mikeslr]

Thanks, Mike, both for the Portables and especially for sussing-out how to make Xvidcap communicate with our currently-defined audio hardware.

Maybe also for drudging the verb suss from out of antiquity and returning it to our common parlance

Seriously, though, xvidcap is an application I've always installed into every Puppy and placed in a launcher on its Taskbar. You may not have a lot of time to capture what's being displayed. Xvidcap's interface has, IMHO, always been the most amenable to quick action. It would be great to also be able to capture sound.

Just checking as you didn't say and I haven't yet had the chance to explore: Do the portables store their settings in their respective folders? i.e. once sound is configured for a particular computer that setting will be used by any Puppy until you have a reason to change it?

[mikewalsh]

@mikeslr :-

It does indeed create the .config stuff within the portable; these are then sym-linked out to where Xvidcap will look for them. I've used the 'touch' command to create an empty file for the first run, which then links into /root; just a simple 'rc' text file (.xvidcaprc).

At close, the sym-links are then removed again.

If you look in the portable, inside the 'config' sub-directory, there's a directory called 'xvidcap'. This sym-links into /usr/share; it contains the Glade config file for XVidcap's interface, so this one has to be a part of the 'install'. After the first run, there will be two items; the 'xvidcap' directory, AND the 'xvidcaprc' file.

Because I have multiple microphone inputs, my personal version also contains a 'switcher' script (plus extra config files) which allows quick swapping between inputs, controlled by a wee YAD GUI. But to answer your question, yes; whatever audio input you've selected WILL hold until you have reason to change it. However, you may find that the selected 'dev/audio'' file doesn't always hold true for every Puppy. Some of my Puppies see the webcam's audio input as '/dev/audio3', some see it as '/dev/audio4'. It'll need to be checked on a per-Pup basis, before trying to record with it. I don't believe this is anything to do with Xvidcap itself, more just something to do with perhaps specific combinations of Puppies & kernels.....? I really couldn't say.

If you enter 'arecord -l' in the terminal, this is the easiest way to figure out which of the /dev/audio files you need to select. Just match the file number to the 'hw:x,x' card number. This works for me.

(If you want, I could always upload my personal version that includes the 'switcher' GUI. This allows for quick swapping of the various /dev/audio files via modified copies of the 'xvidcaprc' config file. These only add a few KB to the total size.)

Any further questions, just ask..!

Mike.

[mikeslr]

Mike, Thanks for unscrambling the sound issue. I've yet to test it as I usually run with the sound muted. But the following may help with the mplayer requirement for systems which don't have it. Operating under the assumption that xvidcap may have mplayer hard-coded I did this on Bionicpup64. That OS came with mpv builtin. I opened /usr/share/applications/mpv.desktop and found that it's Exec line read:

Exec=/usr/bin/mpv --profile=pseudo-gui

So I created an executable bash script named mplayer in /root/my-applications/bin which reads

#!/bin/sh
exec /usr/bin/mpv --profile=pseudo-gui "$@"

xvidcap seems happy: it's play command played the 'vid' I created.

Probably something similar would work with vlc or any other video player.

I've heard of something called 'alias'es. But other than the name and its implications I know nothing about it.

Dah. Should have thought of this alternative:
The line in the 'mplayer' script now reads:

exec defaultmediaplayer "$@"

with equally acceptable results.

By the way. The reason I resorted to an assumption about 'hard-coding' was that I couldn't find xvidcap's 'config' file. I looked for it to see where your suggested changes were being written: figured I'd built that into a pet so, at least, on this computer I wouldn't have to configure xvidcap multiple times. ? /etc --I don't understand how files in /etc relate to the system as a whole so I don't mess with it nor examine it. ? /dev -- same story. And I figured pfind "xvidcap" or ".xvidcap" would have revealed relevant files despite my precaution.

[mikewalsh]

Evening, gang.

Now then; I've performed something of an 'overhaul' on the portables. The GUIs have been somewhat tarted-up, along with the inclusion of instructions-as-you-go (rather than a 'Help' file, per se.) I just think this is a wee bit more "friendly"..!

With the addition of another 'AppRun' sym-link, the whole thing is now a RoxApp.....and has proved to me that it's perfectly possible to 'nest' one RoxApp inside another.

Initial clicking on the RoxApp now produces this:-

From here you can either set-up your audio device - according to XVidCap's 'preference' - or you can launch XVidCap immediately (the 'portable' DOES remember preferences from one session to another, but do be aware that not all Puppies will see a given hardware device in quite the same way....)

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

Audio configuration is, I hope, self-explanatory. Since running

Code: Select all

arecord -l

....in the terminal is the very quickest way to find out the audio card number for your microphone, that's the suggested course of action.

When you've checked your card number, and selected the corresponding /dev/audio device, launch XVidcap via the button at the bottom. All things being equal, you'll be getting audio capture now.

Still available from the same link as in post #1.

Mike.

[mikeslr]

Mike, I haven't tried you newest publication yet. Will tomorrow. But following your report of success I got the prior portable working under VoidPup64. All it needed was libpng12. As that may be true for other 'New' 64-bit Puppys, I've attached it here. Decompress the tar.gz and copy the library and the symlink named libpng12.so. into /usr/lib. Restart-x.

libpng12.tar.gz

Decompress, then copy files into /usr/lib

(69.41 KiB) Downloaded 85 times

For 64-bit 'Slackos', /usr/lib64 is also a likely location for this dependency.

[mikewalsh]

Evening, gang.

Further 'dressing-up' and extra items have ensued.

The 'Audio Control Panel' now has a couple of extra device buttons added. My own often number up to at least hw:4,0.....and I'd forgotten to include a 'Set' button for default.....card hw:0,0!

You can also launch

Code: Select all

arecord -l

....directly in an already opened terminal. This helps you to check which "dev/audio" you need to select.

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

I've also added an "INFO" button down the bottom of the Audio Control Panel. This brings up an infobox, explaining how to correlate the old '/dev/audio' standard with the more current 'hw:x,x' one we're all used to.

Downloads at the regular link in post #1.

Enjoy!

Mike.