wex screencast, webcam, audio recorder

[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

[wiak]

I don't have any audio/video sync issues to test (all recordings on my machine are coming out in sync) so that's problem trying to decide on 'best' filter option. For the moment however, I'm tending to favour using:

Code: Select all

ffmpegFilter_Complex0="-af aresample=async=1000" 

since that 'might' help some systems and doesn't seem to cause any problems otherwise. I'm on BionicPup64 at the moment (using its inbuilt ffmpeg); I'll switch to XenialDog64 in a moment to see how that audio_in.plug alteration effects things with XenialDog64's inbuilt ffmpeg. Don't want to test earlier than that really since don't have the isos or space on my system currently.

My aim would be to not need Fred's special portable ffmpeg (which I don't use on XenialDog anyway, since not required there at least). However... for older Puppy systems you are best to use Fred's special portable ffmpeg since some of these very old ffmpegs used in old Pups do not allow the essential ffmpeg option -thread_queue_size (or asyncts for that matter) so for a 'universal' package including portable ffmpeg is best option (but increases package size a lot and need both 32bit and 64bit version of the portable ffmpeg - i.e. two alternative All-In-One packages. However most older pups are 32bits anyway, so maybe just one 32bit All-In-One would indeed be enough in practice).

wiak

[wiak]

After some further tests, I think it is fine to just use:

ffmpegFilter_Complex0=""

for 64bit systems (seems to work okay for Xenial and Bionic at least; I'm not supporting 64bit Tahr so not testing that).

for older Pups, which tend to be 32bits, I think it is best to use All-In-One by Mike Walsh that includes Fred's special compiled static ffmpeg.

I don't think I'll modify weX itself at present though. Just a note to make the above edit to /root/.wex/plugins/audio_in.plug if using Bionic and above anyway (no need to change anything at all for Xenial as far as I see).

For Puppy users the best situation would be if new Pup builders would build weX in and then they can check if modified /root/.wex/plugins/audio_in.plug gives optimum results (wex is just a tiny script afterall and scrox is small - the ffmpeg in modern pups is fine so no extra ffmpeg required on new builds. Furthermore scrox contains all traditional scrot functionality so scrot being a symlink to scrox works fine for taking screenshots scrot-fashion). I have no control over that so it's up to Puppy users to ask the builders if they want weX configured out of the box. Fred tends to configure weX appropriately (at least in XenialDog; I don't have BionicDog installed at the moment, so don't know if weX is on that - good if it is. Did try BionicDog earlier, but can't remember).

I'll think more about this matter later if I decide to produce a 0.8.18 version of weX.

wiak

[wiak]

Just installed BionicDog64. weX is pre-installed. However, wasn't working because of same Bionic ffmpeg issue above. Simple fix, Fred, is to edit the config file (really should be the one in /etc; i.e. /etc/wex/plugins/audio_in.plug) and, as explained above posts, use:

Code: Select all

ffmpegFilter_Complex0=""

i.e. uncomment above line in audio_in.plug

instead of:

ffmpegFilter_Complex0="-filter_complex asyncts" (i.e. comment that line out)

When weX is run for the first time it copies /etc/wex folder to ~/.wex automagically, so all should be fine if ~/.wex is removed before first run.

wiak

[wiak]

Coming soon

Refer to my above post for recent related info. Tonight I'm busy re-organizing weX package (version for 32bit and another for 64bit system). For simplicity of installation (and maintenance from my point of view) it will now contain scrox and weav in the package. It will NOT itself however contain any version of ffmpeg or any program developed by someone else, such as gifenc-sel (however, the ~/wex/user_utility config script will by default list gifenc-sel as one of the utilities weX will try to include as a button action.

EDIT: Oh, and 'possibly' precord will become included as part of weX package since they share a great deal of common code and precord offers more efficient arecord-based audio recording (though lame, installed by default on most all? Pup/Dog systems, is a dependency). I tend to develop precord weX at same time since helps me keep them in step in terms of user interface improvements. EDIT2: Tonight mainly been revamping Precord (to version 9.0.6) to give it audio-related post processing user-editable utility buttons (like in weX) - also using some weX code in Pecord to make config file handling a bit more robust. Otherwise much the same user-interface as previous Precord. Also now uses defaultfilemanager, or pcmanfm, if available, or checks what's otherwise available, such as rox, for filemanager view of save dir.

In the wex/weav/scrox re-organisation process, I will update main weX program itself to version 0.8.19 to address some of the recent issues. In particular, I will probably provide an optional extra plugins package (deb and dotpet), which will be distribution dependent to address the various ffmpeg variations these use. The new 32bit version of the weX package should be conveniently able to be used by Mike Walsh for assembly of his All-In-One package (which will include portable ffmpeg, which is known to work well on older 32bit Pups too).

Finally, once the new wex version 0.8.19 packages are complete I will be reorganising the wex/weav/scrox threads to one main thread (it got out of control...) and later working-on/polishing my github site containing these projects.

The above are my current plans anyway...
Thought I'd better list them since they affect Mike's All-In-One assembly.

wiak

[Mike Walsh]

@ William:-

Just to let you know, those audio plugin modifications are working nicely in Bionicpup64.

The whole idea of putting the 32-bit 'all-in-one' package together, initially, was for my own benefit! I run around 14 Pups in total.....mostly 32-bitzers. I just wanted to make installation easier across the kennels; rather than installing 3 or 4 packages in each one (or multiple sym-links to each one from a remote partition), I wanted a simple process of click-to-install, click to use. Of course, it then occurred to me that by doing so, I'd inadvertently created a package which would quite possibly be of interest to many other Puppians.....newbies in particular.

So, I published it.

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

It does work well across a whole range of Puppies, certainly as far back as early 5-series Pups.....rerwin's Lucid 5.2.8.7 & BK's T2-based Racy 5.5 being my oldest ones. The only thing with these is that they need a bit more experimentation to get the mixer settings correct, since the sliders don't have the 'logarithmic' unit-on-unit increase - only the 'linear' one - and need to be set rather higher to achieve the desired result. Again, this is going to vary from not only Puppy to Puppy, but also machine to machine in any case. As the saying goes, YMMV.

(I never thought I'd hear myself saying this, but in this particular instance a totally 'home-brewed' solution has proven to be so much more effective than any number of 'commercially available' ones. Again; thank you so much!)

I'll keep an eye on developments, and will re-build/re-pack the 32-bit 'all-in-one' when you release WeX 0.8.19. BTW, are you intending to consolidate things by re-doing an old thread, or arrange things with Flash so that you start a new thread, including relevant stuff from those older threads, followed by removing the latter? Just curious, so I'll know what to look out for.....


Mike.

[wiak]

I'll keep an eye on developments, and will re-build/re-pack the 32-bit 'all-in-one' when you release WeX 0.8.19. BTW, are you intending to consolidate things by re-doing an old thread, or arrange things with Flash so that you start a new thread, including relevant stuff from those older threads, followed by removing the latter? Just curious, so I'll know what to look out for.....

Hi Mike,

I'll PM you once I have the 0.8.19 version uploaded. I'm not sure how long that will take since, as I've said, there are several things I'm planning to include/fix/modify for that release and I'm busy otherwise enjoying the summer weather here. So it's up to you if you wish to release a 64bit version that with the fix I outlined that will work with Bionic (and it seems older Xenial) and without needing to include any portable ffmpeg with that one.

For the 32bit version of your All-In-One, I'd just leave it as it is (including Fred's portable ffmpeg included, since that ffmpeg does accept asyncts option so no fix required for the 32bit systems case (and previous audio_in.plug asyncts option may well work best in older systems like Racy, Tahr, Precise and so on).

But for 64bits Linux OS, yes, a new with fix All-In-One which does NOT have portable ffmpeg would be nice since ffmpeg provided already on the OS distribution itself works fine as long as wex audio_in.plug fix done.

Cheers!

EDIT: note that we must keep the line that includes -thread_queu_size; that's an important needed option still and both Fred's portable ffmpeg and the newer ffmpegs (such as that provided in Bionic) still use that option fine (very old ffmpegs didn't understand that option and results bad without it).

wiak

[Mike Walsh]

@ William:-

Okay; that's all taken care of, now.

Attached below are two 64-bit Wex 'all-in-one' packages (without ffmpeg). One is for Xenial64, where the standard audio_in.plug 'setup' works fine. The other is for Bionic64, where the audio_in.plug 'ffmpeg' lines have been reversed; nothing else has been touched, since that's the only mod required.

I've now left Fred's gifenc-sel out of the mix, since I agree with you on that score. As I said, it's 'icing on the cake'.....and not everyone likes icing. (My sister hates the stuff.....although she does like the marzipan that's often found beneath it!)

You're obviously in the Southern Hemisphere, if your summer's just now getting under way. Enjoy it; I just hope it doesn't get too hot for ya!

I'll look out for a PM, as & when.


Mike.

[wiak]

Thanks Mike. I imagine XenialPup64 and BionicPup64 will be popular Puppy distributions (for those wanting to use recent 64bit OS) so useful weX versions.

Of course, Fred's portable ffmpeg is only needed really for 32bit Pups of vintage Tahr and older, so later will be good to have 32bit versions for any 32bit Pup version of Xenial and Bionic similar to these 64bit ones.

Actually, one of these 64bit All-In-One offerings may work with Slacko64 as well - I can't remember what ffmpeg it uses, but I tend to recall that it didn't work with asyncts either (so maybe that Bionic 64bit one will work with it). Only issue with Slacko64 Pup would be if it also didn't understand the provided, and very important for good results, -thread_queue_size option (which would mean it would also need a specially compiled ffmpeg, which doesn't make sense for such an up-to-date distribution and so I wouldn't bother).

I'll check Slacko64 sometime with your above offerings and report back. I have the iso somewhere on my system. Have now checked: Slacko64 ffmpeg is too old (ffmpeg version 2.6.1) so would need a portable ffmpeg compiled as was done for old 32bit systems. Admittedly, I'm not sure if the Slacko64 I have is the latest - the one I have uses slackware packages for slack version 14.1, rather than 14.2, so 'maybe' more recent Slackware has newer ffmpeg (I now note that woofCE suggests latest Slacko64 uses 14.2 packages with a slack compile of ffmpeg ver 2.8.11; I'm not sure if that would work with Xenial 64 All-In-One; I'll have to download the iso and try I suppose...)? Too much work otherwise, unless enough users commented they had a major need for it in my opinion - otherwise a big compile for something no-one maybe ends up using. I'm happy just to keep things as they stand with 64bit All-in-One packages for Xenial 64 and Bionic 64 systems and the existing portable ffmpeg All-In-One for older 32bit systems (which many seem to still like using). However, I note, for Slacko users, there are some newer 'alien' builds of ffmpeg available, such as here:

http://www.slackware.com/~alien/slackbu ... kg64/14.2/

That version (ffmpeg 3.4.2) would probably work with Bionic 64 All-In-One weX, but not sure what dependencies it has been compiled with (seems to need libpulse.so.0 for example. I think we should just leave Slacko64 to people who use it to find newer ffmpeg etc (unless 2.8.11 works...).


EDIT: Above alien build ffmpeg didn't work for me (though perhaps cos I used older Slacko64 or maybe just not compatible one), but Fred found static ffmpeg build that does. See his post below:

http://www.murga-linux.com/puppy/viewto ... 80#1009980

wiak

[wiak]

@ William:-

Okay; that's all taken care of, now.

Attached below are two 64-bit Wex 'all-in-one' packages (without ffmpeg). One is for Xenial64, where the standard audio_in.plug 'setup' works fine. The other is for Bionic64, where the audio_in.plug 'ffmpeg' lines have been reversed; nothing else has been touched, since that's the only mod required.

Just one extra thing I thought about, Mike. You should maybe mention in your downloads post that you also need to use PPM to search for giblib (for libgiblib1) and it's dependency libimlib2 (which PPM should install automatically with libgiblib). Unless they are already installed by default, which I doubt.

wiak

[Mike Walsh]

Morning, Will.

I've posted in the Bionicpup64 & Xenialpup64 threads about the new version, and have mentioned the need for 'libgiblib1'. Apparently, 'libImlib' appears to be installed by default in both Pups; it was on my system, anyway. So most people should only need to install 'libgiblib1' to get WeX running.


Mike.