wex screencast, webcam, audio recorder

[Mike Walsh]

UPDATE

19/07/18:- The 'all-in-one' has been re-uploaded. It now includes a third desktop entry, for starting Fred's 'gifenc-sel' directly from the Graphic Menu, since it will create GIFs from any short video clip.....not just those created by WeX. (Fewer mouse-clicks than opening from within WeX via the shortcut buttons..!)

Look for 'GIF-Creator' in the Graphic Menu.

New link is available in the original post:-

http://www.murga-linux.com/puppy/viewto ... 080#998080

(Don't forget to install xterm from your Pup's PPM.)


Mike.

[mikeslr]

Hi wiak or anyone,

Following (AFAIK) the instructions from http://murga-linux.com/puppy/viewtopic. ... 64#1009164 I installed scrox-0.8.17_64bit.pet and wex-0.8.18.pet. [pfind located both libgiblib and libimlib2 libraries mentioned. Xenialpup64 has ffmpeg version 2.8.11 which I hoped might be adequate -- in any event, that was the question I hoped experimentation would answer].

Starting wex via terminal, the small toolbar [showing "Record" "Pause" "Stop" "Main Configuration screen" and "Quit" icons] appear. Left-Clicking the Main Configuration screen icon closes the application with the following error:

** (gtkdialog:10134): ERROR **: gtkdialog: Error in line 302, near token '</hbox>': syntax error

/usr/local/bin/wex: line 714: 10134 Trace/breakpoint trap gtkdialog --program=MAIN_DIALOG -G +216+0 > "${PROGRAMTMPHOME}/maindialog"

To quote Mike Walsh: The Devil finds work for idle hands, doesn't he?

Nah. I think, rather, that it's best taken as a reminder that none of us is omniscient or infallible and to heed the words of Prophet after whom the other Mike and I were --probably in a round-about manner-- named: Micah 6:8

[wiak]

Starting wex via terminal, the small toolbar [showing "Record" "Pause" "Stop" "Main Configuration screen" and "Quit" icons] appear. Left-Clicking the Main Configuration screen icon closes the application with the following error:

** (gtkdialog:10134): ERROR **: gtkdialog: Error in line 302, near token '</hbox>': syntax error

/usr/local/bin/wex: line 714: 10134 Trace/breakpoint trap gtkdialog --program=MAIN_DIALOG -G +216+0 > "${PROGRAMTMPHOME}/maindialog"

Ok, I don't have XenialPup64 but I'll fetch and install it and check if that latest wex 0.8.17 dotpet I uploaded today has any issues or if I can find reason you have problem. The original upload/link(?) from months ago has mysteriously vanished from the forum post. That one I uploaded today was on my hard disk - maybe it wasn't the final that I previously uploaded but thought it was. I'll report back. I guess I should check on BionicPup64 too, but presumably should be same steps.

Pity the Pup builders don't simply try weX and get it working prior to releasing their distributions; then all would be well for all users (similarly, Fred's gifenc-sel is highly useful and recommended). Even if they prefer SSR, weX is Puppy forum created and a very small script aside from requiring ffmpeg (as do many other Puppy forum created multimedia apps).

wiak

[Mike Walsh]

Mike/Will:-

Okay. I did some serious experimentation last night, in Xenialpup64, and have assembled an all-in-one, using the wex-0.8.1.8 .pet Will published last night; the 64-bit version of scrox, and the Weav 9.1.0 .pet. I've also included the 'gifenc-sel' GIF creator Fred published, though for some mysterious reason, no matter what size settings I give this, everything comes out the size of a postage stamp..!!

(Any ideas on that one, Will?)

As t'other Mike points out, the installed version of ffmpeg in Xenial64 is 2.8.11. If you update the PPM, and search for 'ffmpeg', the current version is 2.8.15. Although these are all 'ticked' as being installed, you'll want to click on all of them to re-install the current versions. Omit the very last one in this list (libxine-ffmpeg); we don't want that.





(A side note here. As a result of having been running the 32-bit version in Xenialpup64 - albeit very briefly - I'd ended up with the 32-bit versions of libImlib2 and libgiblib overwriting the 64-bit originals. Now; libImlib2 is readily available from the PPM. Libgiblib, however, is NOT - for some weird reason - even after updating.





Canonical appear to have put a block on accessing the repos/package listings manually in the course of the last few days (!?) However, this isn't the only place I hunt for dependencies; I also use the Debian package listings (in this case, the most appropriate match is 'Stretch'), and, of course, pkgs.org.)

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

Anyway, I tracked down a matching 64-bit version of libgiblib from pkgs.org - it's from the ROSA 2016.1 repos; an RPM package - and have put together a .pet for it, if anybody should need it. It's attached below.

I now have WeX working nicely in Xenialpup 64 7.5. Here's a wee video clip to prove that fact; the settings mentioned in the clip do in fact happen to be the ideal ones as recommended by YouTube:-

https://www.youtube.com/watch?v=TC_V3-L ... e=youtu.be

Bionic, however, is another kettle of fish entirely, which I'm increasingly finding to be the case. (Why am I not surprised???)

Despite following the exact same steps to ensure that ffmpeg is the latest version, after installing the WeX 'all-in-one', nothing happens when starting from the Menu Entry. Running from the terminal reveals why. According to the readout, 'syntact-utils' (from libavutils) can't be found - segmentation error - aborting.

Libavutils is installed, and the latest version.....so why this error, heaven above knows. (And Canonical, no doubt!)

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

The WeX 'all-in-one' is attached below. As stated, it does work in Xenialpup64 7.5. Unfortunately, I'm afraid Dusty is going to find that it won't work for her in Bionic64.....so it appears I've been leading her up the garden path.....

And that, boys & girls, is the current 'state of play'.


Mike.

[Mike Walsh]

Now, then:-

To re-cap; for screen recording:-

Container - mp4 seems to work best (on my hardware, at least)
Video codec - leave at x264 default
Audio codec - aac is best for Youtube uploads (mp3 is OK for general recording)

Probably best not to use the 'Mic Boost' feature in Retrovol; if you do, you tend to get all sorts of hissing, popping, humming and general background crud. Leave it off, but crank the 'Capture' slider fairly well up the top of the scale.

The above statement is, of course, subjective, and you'll need to adjust for your own use case, depending on hardware involved, positioning, etc.

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

This next bit's for t'other Mike:- (if he manages to get this working. There's no real reason why he shouldn't, TBH).

Here's a demo I've done of recording a Youtube video with WeX. Don't castigate me.....I like Glenn Miller!

https://www.youtube.com/watch?v=0-bSkqv ... e=youtu.be

For this, leave the WeX settings as they are for screen-recording. Instead of 'Fullscreen' for capture, use the 'Area/Window' selection instead.

Hit the 'Mixer' button, bottom right corner.

In Retrovol, change 'Mic' to 'Mix'. You'll probably need to crank the 'Capture' slider down to around the 25-30% mark (approx), and most likely you'll need to back the 'PCM' slider off a fair way, too. Leave the video playing while you do this, and keep an eye on the VU meter; you want this peaking at no more than 65-70%, max. Otherwise it'll come out all distorted from overload!

Now, click on 'Continue', up the top left corner. Click on the 'Record' button in the WeX interface, and select a window around the video on-screen. It'll start recording immediately, unless you've configured a delay in the 'Settings' window.

When you're done, hit the 'Stop' button.

And that, mes amis, should be that. (See, it can be done. In most aspects of computer stuff, I'm a total dunderhead.....so if I can fumble my way through this, I reckon just about anybody can!) Will deserves a commendation for this, and in my opinion, this should either be in the repos, or come with Puppy by default. Probably the latter.


Mike.

[Mike Walsh]

Double-post; sorry!

[mikeslr]

Hi Mike & All,

Followed the last instructions to install Wex to Xenialpup64-7.5. As per my previous post, starting Wex from the terminal appears to generate a fully functioning application. However, clicking the Configuration tool still crashes the application. The "error message" however has changed to:

** (gtkdialog:11931): ERROR **: gtkdialog: Error in line 309, near token '</hbox>': syntax error

/usr/local/bin/wex: line 714: 11931 Trace/breakpoint trap gtkdialog --program=MAIN_DIALOG -G +216+0 > "${PROGRAMTMPHOME}/maindialog"

[ITSMERSH]

Off Topic

I like Glenn Miller!

You probably won't believe it, though: me too!

[wiak]

Hi Mike & All,

Followed the last instructions to install Wex to Xenialpup64-7.5. As per my previous post, starting Wex from the terminal appears to generate a fully functioning application. However, clicking the Configuration tool still crashes the application. The "error message" however has changed to:

** (gtkdialog:11931): ERROR **: gtkdialog: Error in line 309, near token '</hbox>': syntax error

/usr/local/bin/wex: line 714: 11931 Trace/breakpoint trap gtkdialog --program=MAIN_DIALOG -G +216+0 > "${PROGRAMTMPHOME}/maindialog"

Hi Mike, I can confirm that I'm getting same errors on installation to pristine Xenialpup64-7,5.

EDIT: It's a bit odd so might take a while to track down... The exact same weX script is working fine in XenialDog64 and BionicDog64. I temporarily 'borrowed' the gtkdialog from there (not gtkwialog) and tried that in XenialPup64 but still same problem in that Pup. Since no error occurs in XenialDog64 I can only imagine there is some kind of race condition (timing issue difference in XenialDog64 compared to XenialPup64) but maybe something else since race condition would be a surprise. Investigation continues.

I'm looking into it, but going out shortly so back in a few hours...

wiak

[wiak]

XenialPup64 installation issue solved. See here:

http://www.murga-linux.com/puppy/viewto ... 55#1009255

[mikeslr]

I can confirm that installing pupradio resolved the problem. Just to be clear, I'm running Xenialpup64-7.5 with Mike Walsh's all in one Wex, obtained and having followed the instructions from here: http://murga-linux.com/puppy/viewtopic. ... 03#1009203

[wiak]

I've also included the 'gifenc-sel' GIF creator Fred published, though for some mysterious reason, no matter what size settings I give this, everything comes out the size of a postage stamp..!!

Did you get that gifenc-sel issue resolved to your satisfaction Mike?

[Mike Walsh]

I've also included the 'gifenc-sel' GIF creator Fred published, though for some mysterious reason, no matter what size settings I give this, everything comes out the size of a postage stamp..!!

Did you get that gifenc-sel issue resolved to your satisfaction Mike?

No, I haven't, Will. I thought it was just in the 64-bit Pups that I've been working on the last couple of days, but I've just tried it out in a couple of the 32-bit Pups. Previously, it was working fine in these.....but now even these are doing the postage stamp thing!

Which points to something I must have installed system-wide recently, across the kennels. Hmmm.....

I'm in Slacko 560 ATM. I thought perhaps it might have summat to do with my putting Fred's ffmpeg in /usr/bin for system-wide use, so I temporarily replaced it with the original version that shipped with 560 by default. No dice; gifenc-sel wouldn't even do the job. Refused point-blank. So I put Fred's version back.....

The terminal gives no clues at all; according to that, it's doing what it's supposed to do.

Will, is gifenc-sel meant to use the version of ffmpeg that's built-in with Fred's 'portable' AppImage?


Mike.

[fredx181]

I've also included the 'gifenc-sel' GIF creator Fred published, though for some mysterious reason, no matter what size settings I give this, everything comes out the size of a postage stamp..!!

Did you get that gifenc-sel issue resolved to your satisfaction Mike?

No, I haven't, Will. I thought it was just in the 64-bit Pups that I've been working on the last couple of days, but I've just tried it out in a couple of the 32-bit Pups. Previously, it was working fine in these.....but now even these are doing the postage stamp thing!

Which points to something I must have installed system-wide recently, across the kennels. Hmmm.....

I'm in Slacko 560 ATM. I thought perhaps it might have summat to do with my putting Fred's ffmpeg in /usr/bin for system-wide use, so I temporarily replaced it with the original version that shipped with 560 by default. No dice; gifenc-sel wouldn't even do the job. Refused point-blank. So I put Fred's version back.....

The terminal gives no clues at all; according to that, it's doing what it's supposed to do.

Will, is gifenc-sel meant to use the version of ffmpeg that's built-in with Fred's 'portable' AppImage?


Mike.

Hi Mike, I can't reproduce that the .gif becomes the size of a postage stamp.
Tested on XenialPup 32-bit (but needed to upgrade yad, version 0.12 included in XenialPup is too old).

The ffmpeg included in "wex_portable" is to workaround problems for weX itself (with older ffmpeg (or without compiled in some required options) weX will not work properly AFAIK)
William knows more about that.

The gifenc script is another thing, it should work with any newer ffmpeg version (as I said, with the ffmpeg version in XenialPup it works okay for me).

If you have further ideas how I could reproduce the problem, please tell me.

Fred

[Mike Walsh]

Hi, Fred.

I wish I could, mate. I don't know what to tell you, because I don't have a clue what I may have done to cause this.

All I can say is that an 'area' video clip from weX (approx 700 px high, by maybe 250 px wide) will end up, regardless of size settings at something like 100px x 35 px. And it does this in every Pup I've tried it in - 32- or 64-bit (which is very, very odd, because until very recently it worked fine under the 32-bit Pups).

Regardless of the clip used, or the choice of size, whatever is selected for conversion ends up something like 5% of the original full size. It's like it's stuck on the 'default' smallest selectable size.....if that makes any sense.

It's weird as hell. I fail to see how this could simultaneously go wrong in over a dozen separate, individual installs of gifenc-sel.

Personally, I'm stumped, mate.


Mike. (*shrug*)

[wiak]

Another issue has arisen in Bionic systems, at least in BionicPup64, which I am currently testing weX on (not the All-In-1 dotpet but using the ffmpeg already provided in BionicPup64): That inbuilt ffmpeg doesn't have the asyncts filter capability weX needs from ffmpeg (in default recording case). It appears that newer ffmpeg is no longer the new issue since:

From ffmpeg version 3.3 onwards:
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog

Removed asyncts filter (use af_aresample instead)

hmmm... I'll need to work on that since I have no idea how to replace current asyncts filter with aresample filter (don't yet know how to use that). As far as I remember, my old workaround for no asyncts filter ability in some ffmpegs was to simply drop that part of the command (but with loss of audio/video sync) - presumably aresample filter can fix that issue, but now I have to research how to do that and upgrade weX commands accordingly. What a pain. At least Fred's specially compiled ffmpeg portable (as in All-In-1 assembly) can be used for now anyway but I don't want to have to rely on that overall. The whole ffmpeg capability seems to be full of moving goalposts.

EDIT: I also notice I now have two main weX threads because for a while mcewanw could no longer log in so I started new weX thread as wiak. But that is a real pain and I'll have to fix that disorganisation. When I do manage to build a newer weX, inspired by Mike Walsh's assembly, I've decided to include weX, weav and scrox in the one package (so will have a 32bit version and a 64bit version). I'm hesitant to include your gifenc-sel in that manner, Fred, since it is your package, and you may upgrade it from time to time. Better, I feel, to just include gifenc-sel as one of the defined weX buttons since weX won't show that button anyway unless it detects gifenc-sel actually installed on system. I really want to try and get weX working in recent pups with the ffmpeg they provide though, rather than having duplicate via additional portable ffmpeg (since that is quite a big addition when duplicated on the system).
wiak

[wiak]

/root/.wex/plugins/audio_in.plug is the code I'm going to have to work on (see my previous post for why):

Code: Select all

# The audio_in assignments given below for ffmpegFilter_Complex0 and ffmpegAudioIn0 are user-editable but you need to use correct bash and ffmpeg syntax in any such modification (e.g. no spaces on either side of the equals signs). The main reason I am including this plugin is that some older ffmpegs do not understand -filter_complex asyncts or -thread_queue_size. For such a case it is best you upgrade your ffmpeg/avconv, but if you insist on using an old one, uncomment the two commented alternatives below and comment out the current ones:

# Of course, if you get this at all wrong, weX will temporarily not function correctly, if at all, so you are advised to back up the original plugin before trying to modify this one! However, no harm will be done to the actual weX program itself if you do make an error here. If the worst comes to the worst you can simply delete the plugin since the assignments used by default within weX itself work fine with newer ffmpeg :-)


ffmpegFilter_Complex0="-filter_complex asyncts"
ffmpegAudioIn0="-thread_queue_size 512 -f $audiosystem $channels_arecord $asamplerate -i $plughw"


# The following are for old ffmpeg/avconv that don't understand options asyncts or -thread_queue_size:

# ffmpegFilter_Complex0=""
# ffmpegAudioIn0="-f $audiosystem $channels_arecord $asamplerate -i $plughw"

I'm assuming (will have to test BionicPup64 ffmpeg) that -thread_queue_size option still works.

wiak

[wiak]

Yes, weX is now working in BionicDog64, using the ffmpeg it provides by default, if I edit /root/.wex/plugins/audio_in.plug and use:

ffmpegFilter_Complex0=""
(i.e. edit audio_in.plug to uncomment this one; meaning remove the hash)

instead of:

ffmpegFilter_Complex0="-filter_complex asyncts"
(i.e. edit audio_in.plug to comment out this line)

Only further testing will reveal if audio/video will remain in sync during long recordings with that change. However, I really want to see if aresample can be used such that AV sync works for most ffmpegs (though old ffmpegs certainly don't accept -thread_queue_size option; but that at least is okay since I don't intend supporting such old ffmpegs anyway).

EDIT: Perhaps this alternative will do the job (it works at least - but I'm not sure if it is doing anything useful or not or what it does...):

ffmpegFilter_Complex0="-af aresample=async=1000"

wiak

NOTE: Refer to my previous two posts to see what this is all about...

[Mike Walsh]

@ Will:-

Another issue has arisen in Bionic systems, at least in BionicPup64, which I am currently testing weX on (not the All-In-1 dotpet but using the ffmpeg already provided in BionicPup64): That inbuilt ffmpeg doesn't have the asyncts filter capability weX needs from ffmpeg (in default recording case). It appears that newer ffmpeg is no longer the new issue since:

From ffmpeg version 3.3 onwards:
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog

Removed asyncts filter (use af_aresample instead)

Mm-hm. That's the exact item that threw me out when I was trying out the 'all-in-one' I put together for the 64-bit Pups. So; if I have this correct, the 'fix' is to comment out

Code: Select all

ffmpegFilter_Complex0="-filter_complex asyncts" 

...and un-comment

Code: Select all

ffmpegFilter_Complex0="" 

.....in the audio.in plugin, yes?

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

BTW:- You're probably right about Fred's gifenc-sel; it should be left as a separate package. I think I'll re-build my 'all-in-one' to omit it for now, and concentrate that just on WeX, Weav & scrox. Gif conversion is, after all, not a necessary part of what you want to achieve here, TBH. It's 'icing on the cake'.....and not everybody wants, or even likes icing..!


Mike.

[wiak]

So; if I have this correct, the 'fix' is to comment out

Code: Select all

ffmpegFilter_Complex0="-filter_complex asyncts" 

...and un-comment

Code: Select all

ffmpegFilter_Complex0="" 

.....in the audio_in plugin, yes?

Yes, that is correct Mike. However, I'm also experimenting with alternative to using ffmpegFilter_Complex0="":

Code: Select all

ffmpegFilter_Complex0="-af aresample=async=1000"

in case that second one (or similar) results in better audio and video syncing (no difference that I see on my own laptop so far though).

There is a possible issue though... some older systems do work better with the asyncts line as it is... So if I find an alternative that works for all cases (holy grail...) then I'll later make new version of weX with any change code incorporated in main script. For now, leaving things as they are works best for many systems (when using that Fred compiled ffmpeg since that ffmpeg recognises asyncts filter anyway).

As for gifenc-sel: I think it is a very worthwhile extra but better as a separate dotpet since being developed separately by Fred (so hard to maintain if put in All-In-One package) - but definitely recommended to be installed since I really like weX having that utility available.

wiak