wex screencast, webcam, audio recorder

[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.

[fredx181]

Hi Mike, wiak, all

Here's a 64-bit wex-portable
https://dl.dropboxusercontent.com/s/8ct ... ar.gz?dl=1
Extract and run "wex-portable64"

It includes this static ffmpeg build
https://www.johnvansickle.com/ffmpeg/ol ... tic.tar.xz
See more here:
https://johnvansickle.com/ffmpeg/

I tested on slacko64 and Bionicdog64 and works fine, I guess it should also work on other 64-bit Puppies (testing would be appreciated ).

It has in /etc/wex/plugins/audio_in.plug :

Code: Select all

ffmpegFilter_Complex0=""

If you ran weX earlier and it doesn't work properly, replace ~/.wex/plugins/audio_in.plug with: /etc/wex/plugins/audio_in.plug

EDIT: Above is wrong, there's no "/etc/wex/plugins/audio_in.plug" when running the portable, so remove whole (hidden) folder ~/.wex if there are problems. (it will be re-created then)

I noticed no video/audio out-of-sync issues with this setting.

Another way (instead of wex-portable) to make weX work e.g. in slacko64, is to replace /usr/bin/ffmpeg with the static ffmpeg build from e.g. ffmpeg-3.3.4-64bit-static.tar.xz (see links above)
And install Mike's 64-bit wex pet package for Bionic from here:
http://murga-linux.com/puppy/viewtopic. ... 99#1009799
Then you have the benefit of a newer ffmpeg (system wide installed).

Fred

[wiak]

thanks for the static build 64bit Fred. I came across that one at some stage and had tried it but think I was using too old version of Slacko64 (wierd, but quite likely I made some other mistake; my development system is full of files disorganized all over the place... needs some TLC) - good it works on latest Slacko64.

wiak

[Mike Walsh]

@ Fred:-

A-ha! Nice one, mate.

Fred, have you done the same with this 64-bit portable as you did with the 32-bit version? I get that you've packaged WeX together with ffmpeg; can I assume you've included libImlib2 & libgiblib1 as well? And scrox?

Just waiting on confirmation, then I'll run up a 64-bit 'all-in-one' .pet.....without gifenc-sel. I'm going to package this one separately.

In all likelihood I'll re-pack the 32-bit version without gifenc-sel, too.

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

<snip>...but quite likely I made some other mistake; my development system is full of files disorganized all over the place... needs some TLC...<snip>

That's one lesson I learnt a long time ago; the hard way (through losing some important stuff due to being slap-dash about things!) It might seem a bit anal to some folk, but every time I save anything, I fit it into a strict hierarchical structure. I take the view, as with so many other things in life, that if something only needs doing once, then you may as well take the time to do it properly; you can then forget about it, secure in the knowledge that you know you can track it down easily when you want it..!

Takes some organising initially, but once you've done so, you quickly get into the habit of staying on top of things. For me, at least, it's now second-nature to do so...


Mike.

[fredx181]

Fred, have you done the same with this 64-bit portable as you did with the 32-bit version? I get that you've packaged WeX together with ffmpeg; can I assume you've included libImlib2 & libgiblib1 as well? And scrox?

Hey Mike, yes, same as 32-bit setup, all you mention are inside the portable.

[wiak]

Just waiting on confirmation, then I'll run up a 64-bit 'all-in-one' .pet.....without gifenc-sel. I'm going to package this one separately.

In all likelihood I'll re-pack the 32-bit version without gifenc-sel, too.

Personally, Mike, I rather like gifenc-sel included in the Puppy all-in-one dotpet since it is so useful yet tiny addition. What I was saying was that I am going to repackage weX itself to contain most of the programs associated with that (even its ancestor, Precord) but, in that, I won't be including either ffmpeg or gifenc-sel or libgib1 or libimlib2, since these are extras (and not by me anyway); but... an All-in-one dotpet already contains ffmpeg (since that is a static ffmpeg build and required to make the thing portable) - I actually thus see no reason for gifenc-sel not to be included in an all-in-one assembly (if you see what I mean). Basically, once weX package itself includes all its main parts, I think it is commonsense that the ALL-in-one includes weX and everything else required... Perhaps Fred can chip in with his opinion?

wiak

[fredx181]

Well... I can see the logic in not including gifenc, it has not to do with screencasting, but I wouldn't mind if it's included in the all-in-one (as it's very tiny addition).

Btw. note that gifenc does depend on the ffmpeg (and yad) installed in the system (cannot make use of the ffmpeg inside the wex-portable)

Fred

[wiak]

(and yad)

Ah, yes, I forgot about that just now. Yes, that is a major reason really not to include it in All-in-one, since not really an all in one if gifenc-yad inclused without yad (and yad certainly has to be kept as own package since it's major and a core system package like gtkdialog/gtkwialog) - though from Puppy dotpet point of view that's maybe not a big deal since yad likely to become installed on Pups surely nowadays? Then again, a separate dotpet for gifenc-yad also makes a lot of sense since it is a standalone program and doesn't depend on weX for any functionality per se.

I've no fixed opinion about it, except the weX user-util config by default should include gifenc-yad as optional button (which only pops up in weX if gifenc-yad actually installed anyway).

wiak

[Mike Walsh]

@ Fred:-

Any 'constraints', as far as which version of YAD is required for gifenc-sel/gifenc-yad? I would hazard a guess it needs to be new-ish?

(As far as I'm concerned, everything is ready for upload. Pets for

a) Wex 0.8.18 'all-in-one' (both arches) - these will be updated in due course, as & when;
b) The static ffmpeg builds (both arches), for system-wide use;
c) 'GIF-creator' (gifenc-sel) - noarch, of course, since it's just a script;
d) YAD v0.40 (both arches)

Just waiting on confirmation about YAD version, that's all.)


Mike.

[fredx181]

Hi Mike, don't know exactly, the yad version 0.12 is too old, just tested gifenc with v 0.20 and works fine, so 0.40 will be double fine

Fred

[mikeslr]

Hi Mike,

I appreciate 'All-in-one'/"self-contained" application packages. They're an efficient way to publish, enabling the user to quickly get up and running without having to track down dependencies. But, IMHO, every good idea can be taken too far.

Where I would draw the line is when a potential component is a 'foundation module' -- needed not only for the prospect application but for several other applications a user may also want. Wine, and Qt are examples of 'foundation applications.' Once it's present/installed on the system it can be used by several applications. Duplication of such module by also including it in an application, or several applications, just uses disk-space/Puppy-Space and band-width.

Python seems to be an exception to the exception: each application depending on python may require its own version, or some component depending on a specific python version; and unlike Qt, the presence of different versions of python results in conflicts. But then, I admit that I don't understand python.

I'm not sure where yad falls on this spectrum of 'foundation modules'. Can a system support two versions without their causing conflicts? Are newer versions backward-compatible so that the installation (via pet) of a newer version won't break applications dependent on an older version? Can an application packaged as an SFS or external program run if a different version of yad exists in the SaveFile/Folder or Puppy_version_number.sfs [both of which have priority in the "merge file system"?

All tolled, I think it would be better not to include yad in the application itself, but rather to either note the dependency of a particular version or higher in the announcement, perhaps providing a link to a qualifying pet, sort of like what you did in packaging google-chrome for both Tahrpup64 and Slacko64 where the latter needed an additional file/lib. Or like what ITSMERSH did with PaDS --providing notice when the application was installed that in order to function from the Menu --with its greater customization options-- xdotool was required.