Newer version 0.8.18 version of main wex dotpet attached (fixes the pulse audio doc issue described below).

ERROR IN weX program documentation/tooltips:For pulseaudio use:

On weX setup gui, entry box "audiosystem" should set to "alsa" (without the quotes), and entry box "audiodevice" should be set to "pulse" (rather than plughw:0.0 or whatever). The new combined wexweavscrox version I have released for tinycore/dCore as an sce, has that documentation error fixed, and can be found here: http://murga-linux.com/puppy/viewtopic.php?p=946639#946639
---------------------------------------------------

weX is a gtkdialog-based audio, video, webcam, and X11 screencast recorder, which provides and substantially improves upon all of the previous functionality of both the earlier Precord (for audio) and pAVrecord (for audio, video, webcam and X11 screencast recording). Its recording quality is equal or similar to that of SSR but can additionally include embedded webcam stream and does not require qt libs on your system.

NOTE WELL: If you have no webcam connected on your computer, remember to untick the webcam stream checkbox in weX or weX will fail to create a video. Webcam is currently selected by default (will be left unchecked in next version).

Please find weX, along with scrox and weav, for various distributions, attached to the foot of this post.

If you are trying to install weX onto a different distribution than provided for below, please take note of the information in the following link:

NEW Mar23, 2017: fredx181 has put together a small utility called gifenc for converting videos to animated gif. It is a modification of the original code from http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
You can find the gifenc utility at the link below including a mini-howto in which Fred explains how to use the weX-provided external utilities provision to add a button for gifenc to the weX gui. Pressing the resultant button will make an animated gif copy of any weX-created video or screencast just created (without erasing the orignal video):

Added 13 Sept 2016: static ffmpeg build by Fredx181 (of DebianDog) and portable app version of weX including that ffmpeg compilation (wex-portable). Believe it or not wex-portable even worked perfectly for me in old Puppy Slacko 5.3.3 (including embedded webcam, great video quality, and perfectly in sync audio and video). Also worked perfectly in my quick test on XenialDog and XenialPup. Since worked so well on old Puppy Slacko 5.3.3, I expect wex-portable should work great on many Pups (oldish and new), and Fred's static ffmpeg build should be a good old Pup update (and better than the ffmpeg in new Pups too IMO):

For simple instructions on how to install wex,weav, and scrox for Puppy systems follow the link below for older Pup Slacko 5.6 example. Most things should be the same except you shouldn't do the last part (i.e. don't change the default audio_in.plug or video_in.plug from those provided by default).

NOTE: I've now also tried weX, weav, scrox on an older Pup (Slacko 5.6), which has an older ffmpeg so needs modified /root/wex/plugins/audio_in.plug and video_in.plug. I've now therefore written a short howto install to an older ffmpeg system like Slacko 5.6. The howto given via the link below also explains how to get the giblib and imlib2 dependencies needed by scrox, which may be applicable to many Pups. (NOTE WELL however that you should NOT CHANGE audio_in.plug and video_in.plug if you are using a more recent ffmpeg on a more recent Pup like XenialPup or XenialDog or FatDog):

FatDog (and similar) version: Uploaded new version of weX for where ffmpeg is generating two or more child processes (such as happens with FatDog64-710beta on my machine).

For full weX functionality, you need to install weX, either the 32 or 64 bit version of scrox (depending on your system), and weav. If you don't already have them on your system, you also need suitable versions of imlib2 and giblib1 for scrox (see installation requirements further below).

weX uses scrox to select windows (with or without border) or fullscreen or mouse-selectable rectangular capture area. (Works great capturing youtube or similar streaming videos, actually, via Alsa MIX for audio rather than MIC input and X11 screencast for video, though of course it is generally better to simply download such videos directly via say Firefox video download extensions).

Please temporarily find attached both deb files and dotpets for weX, weav and scrox (32bit and 64bit versions of scrox), but please note the extra library files you may also need as dependencies for scrox as described in INSTALLATION REQUIREMENTS below. I'm only publishing these files temporarily on Puppy forum so grab them now if you want to test. Later I'll be moving them to my personal website, but can't guarantee when they will be available again. I don't intend making many if any mods to the main programs, other than any important bugfixes, but for many cases can support weX via its plugin facility (and weav, via its commandline combobox list).

INSTALLATION REQUIREMENTS/DEPENDENCIES:

You need to have libimlib2 and giblib1 on your system. Use your package manager to install these if you don't have them. For XenialDog/DebianDog (assuming they don't already have them) it is simply a matter of:

FatDog64-710 ffmpeg creates two processes (probably multithreading), which meant STOP button wasn't ending the capture with main weX dotpet above. I have thus uploaded a version of weX specially for that version of FatDog (the only FatDog I have tested) - but should be used for any ffmpeg that similarly starts up additional child processes during record (at this date versions of XenialPup and XenialDog/DebianDog should use the main weX dotpet).

The dotpets seem to install fine, but as I said, weX currently works best in XenialDog since it has some webcam issues when used with Puppy XenialPup32 (which otherwise works not too bad).

WilliamLast edited by mcewanw on Wed 31 Aug 2016, 17:44; edited 1 time in total

Okay, the temporary problem/fail in installation of the deb packages is because I share /usr/local/share/pixmaps/wex icons with both wex and weav, so once one of these is installed Fred's (EDIT) right-click install deb utility won't allow the other to install on XenialDog. I have temporary used the following install deb from commandline workaround:

Code:

dpkg -i --force-overwrite weav__9.1.0_i386.deb

Or do the same for weX if you installed weav first. Hopefully Fred will come back to me with a better proper solution since I really do want both programs to be able to share common icons. Anyway, I'm becoming desperate for my long break...

WilliamLast edited by mcewanw on Fri 19 Aug 2016, 04:05; edited 2 times in total

Posted: Fri 19 Aug 2016, 02:42 Post subject:
This morning, i have just seen you provide a new tool.

pAVrecord used yesterday for this tutoriel 'ISObooter' ISOs on USB, multiboot.
. The difficulty was too set quality and where to screencast.
This morning, i have just seen you provide a new tool. I will test it for my next tutos._________________Passenger Pelo ! don't ask him to repair the aircraft. Don't use him as a demining dog .... pleeease.Last edited by Pelo on Fri 19 Aug 2016, 23:51; edited 1 time in total

Okay, the temporary problem/fail in installation of the deb packages is because I share /usr/local/share/pixmaps/wex icons with both wex and weav
...
Hopefully Fred will come back to me with a better proper solution

William

Okay, Fred (DebianDog fredx181) provided the Debian control line fix, so I've uploaded new deb packages for wex and weav so should install fine now without needing to use any dpkg 'tricks'.

Despite definitely taking a break from programming/computing very shortly, I am contemplating trying to code a YAD version of weX/weav or less likely, Bacon, if can't get interface the way I like it in YAD, but don't wait... it may never happen. Just try these gtkdialog versions to see if they are any use for anyone and report back if they are - at least if you would like public versions of weX, weav and scrox maintained and made available.

But don't worry about feedback otherwise, I won't be offended! In the past BarryK used to sometimes adopt little forum-created gtkdialog apps for Puppy distributions but nowadays I think apps would need submitted to woofCE team for consideration if someone wanted an app available by default. I have no such ambitions, and later Puppies have moved towards bigger apps now, like SSR, anyway. And the much smaller distribution, Slitaz, has all but given up on gtkdialog scripts I think - yad being the current favourite there for small util GUIs (and they wouldn't include ffmpeg by default anyway).

Hence I suspect these new gtkdialog-based apps of mine are only of use to me, and probably not so much use to me now either, since I'm slowing down on computer use best I can. Possibly more chance scrox is useful?

Hi, I did some limited testing on Fatdog64-710 for wex-0.8.17FATDOG.pet, weav-9.1.0.pet and scrox-0.8.17_64bit.pet.
I converted all three pets to Fatdog64 txt packages using the right-click rox entry. For scrox I installed giblib-1.2.4-x86_64-1.txz from http://smokey01.com/fd700/packages/. All went well.
I grabbed rectangular areas of video+webcam, and video only, output as x264 mkv files using the default frames rate, etc. Then I looked at weav, and I like all the possibilities that you have in there, and the sort of "tutorial" feeling from it - there's a lot that I can learn by using your software!
The wex user interface is a bit too crammed for me, perhaps you could change some of the radio buttons to drop-down selectors to give the GUI some room. GUI set aside, the functionality that wex provides is very rich - this should be an excellent screencap program, thank you!
One thing I noticed running scrox -p -s is that the output filename is printed to stdout with % special variables unexpanded, while they are expanded in the actual output file name. I think scrox should print the expanded filename to stdout, otherwise it's of little use for shell scripting.
In vcoder_user2.plug I noticed word 'the' repeated: "...ffmpeg arguments to the exactly the same variables as here..."
Thanks again for this excellent combo program!_________________Fatdog64-800|+Packages|Kodi|Findnrun|+forum|gtkmenuplus

I'll look into what you came across especially the unexpanded scrox variables - I was in a hurry to get onto using that in weX so didn't look over if it was easy to expand the filenames or not - just taking a break now and longer one soon so may be a while.

The gui preference has always been a point of difference - I tend to prefer the radioboxes myself though I realise some find that too cluttered. The matter was actually first raised with the earliest Precord when I wrote it in 2008. Certainly does take up a bit more gui space, but I like to see all choice/chosen options at a glance rather than having to mouse around the gui dropping down combobox lists - matter of taste I guess and no doubt combobox approach makes a program a bit first-time friendlier.

External app mhwaveedit works better with weX if mplayer is installed since it needs that to automatically open mp3, ogg or whatever audio track inside the video, but that's a small matter if user doesn't have an interest in editing the audio track with mhwaveedit.

One thing I noticed running scrox -p -s is that the output filename is printed to stdout with % special variables unexpanded, while they are expanded in the actual output file name. I think scrox should print the expanded filename to stdout, otherwise it's of little use for shell scripting.

Hi again step,

For a moment I thought I had output the wrong variable by mistake! However, that is not the case. The output filename you mention actually can only be output in unexpanded form because the purpose of the related --xcap option of scrotx is to start up an external program BEFORE the screenshot file is processed (i.e. full filename is not available at that time in original scrot since that filename expansion is later done by the actual screenshot creation imlib program - which is an inherent part of the original scrot program design).

I remember now hesitating to bother outputting the unexpanded filename at that point therefore, but decided there was no harm in doing so, since it might still be useful on rare occasion (since external program could expand it, in some way, for some purpose or other). However, the program already contains an output that starts up an external app AFTER the screenshot is taken (--exec) and for that case the expanded filename IS passed out to the external app (though nothing is printed out to stdout itself at that time - that's also a design decision/implementation in the original scrot code).

As far as its use for shell-scripting, scrox, contains all the same, untouched, shell-scripting functionality as the original scrot program with the addition of the screen coordinate output functionality - the stdout pre-screenshot processing unexpanded filename may not be of much if any additional use, but I'll leave it in just in case and since it's harmless.

EDIT: I should mention that if you were using scrox in a script to find the coordinates for capture area you would probably want to add option -n:

Code:

scrox -n -p -s

The -n turns off screenshot capture, so the stdout unexpanded output filename is irrelevant in that case and should just be ignored.

EDIT2: I should mention, that the scrox stdout filename is primarily included for non-datestamp filename use, since any specified filename is echoed to stdout exactly and also passed to external program as argument if -x option used. For example, per Example 2 given in scrox --help:

Code:

scrox -s -p -d 5 -x /usr/bin/programA 'filename.jpg'

the exact filename (in above example: filename.jpg) is passed as an argument to program or script /usr/bin/programA.

Maybe it's too much to ask making a screencast while playing a video, but anyway full-screen works well.

Very advanced program, indeed as Step says, a lot to learn and discover!

Will test more later (and reply (although very late) on your posts in the DD64 and Xenialdog threads).
Still having sort of timeout, but began little by little to work on a rebuild of Debian-Jessie openbox_xfce version (which is still my favorite 'Dog').

Good testing and interesting results. Looks like it couldn't keep up on your machine with the Area option etc. What were you using? There is a parameter that could be adjusted to maybe make it okay again: increase the -thread_queue_size (on the relevant audio plugin I think). Not sure since works fine on my Intel Core II duo 2.1GHz 2GB RAM machine - I have little doubt slower machines will run into frame dropping/sync issues of course.

On my computer, I have no issues even when using Area to record a playing Youtube video - comes out great.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum