Sneak preview Youtube video of debiandog screencast application, ddogxcap in action. Hope I've uploaded the video successfully and that the link to it works okay:
https://youtu.be/D4vzoAl-p5c
William
sneak preview of ddogxcap (CLOSED)
sneak preview of ddogxcap (CLOSED)
Last edited by mcewanw on Fri 05 Aug 2016, 14:10, edited 1 time in total.
github mcewanw
http://www.murga-linux.com/puppy/viewto ... 329#914329
Yes, I was referring to Toni (aka saintless) and yourself using him as an excuse to sneak out of the far below deck developers' boiler room - though you may actually just have been throwing up over the side of the ship of course, or sneaking up for a Martini with your friend Pelo.
As for the webcam embedded in the uploaded video - that's just an extra video stream which the underlying ffmpeg/avconv program combines with the Xgrab if you select it to do so. If you look near the bottom of the video you should see three checkboxes: one for audio, one for X11grab video and one for webcam - you just click whichever you wish included. You can change the size of the webcam image to as full or tiny as you wish (there is an input box for webcam image width in pixels). The whole video can be scaled to half or lower resolution of course (another input box).
As with Precord/pAVrecord all settings are persistent for next use, so the small gui is all that is needed for general use (once it is configured to the users' liking - though the default settings should just work fine on computers with suitable specs anyway. Might not perform so well on computers with lower specs than my test machine, which is nine years old, and has 2GHz Intel Core-II duo processor and 2GB RAM. I didn't use cpufreq-set to put my computer into 'performance' mode - but that may be help - mine was just left in ondemand mode throughout the capture).
Assuming the computer has ffmpeg or avconv included, ddogxcap can therefore also pretty much replace Precord for simply recording audio streams: mp3, ogg or m4a (being aac encoded) and replaces pAVrecord for simple webcam video recording. Of course, ddogxcap (like pAVrecord before it) derives from Precord code anyway (though Precord was written to not need ffmpeg for mp3 files - Precord uses arecord | lame for that).
The fork of scrotx, by the way, includes the pretty-much untouched functionality of original scrot. So on my XenialDog system I have scrot replaced by scrotx (much the same binary size) and have a symlink called scrot pointing to scrotx.
ddogxcap can be run as a commandline app too, by the way (once earlier configured via main configure gui). That allows it to be autostarted in, for example, the background via say 'chron' (or via Pschedule, which is Puppy gui frontend for chron). It also includes a simple plugin facility so user can create, for example, their own video encoder part of the main ffmpeg/avconv command. One other reason I made it controllable from commandline is that I want to experiment with a 'motion capture' plugin I haven't yet written - though I may not bother with that since want to enjoy sunbathing on the deck beside the 'cruise-ship' bar...)
As for any release date - I'm in no hurry - still polishing up things (plenty of other screencast apps out there nowadays anyway). I'll maybe release it, as a welcome gift, once and if Toni climbs back on board to scrub the decks, which Pelo deserves to help him with. Mind you, ddogxcap won't work on what appears to be Toni's next debian-live-based offering since he is cutting out all the gtkdialog/yad crap - but he has a good idea, since doing so will make a nice clear core and the other stuff can be added in again later should it be wanted.
But anyway, perhaps the screencast app being developed on FatDog will be better, in which case I'll just leave Pelo to use that or SSR QT app instead.
William
Hi Fred,fredx181 wrote:Hi William,
So that's you on a ship presenting your screencast program.. very original :)
If you could save Toni from the sharks, first give him a little rest of course, but then the next day punish him for his misbehavior by letting him scrub the deck :wink:
(but I might be referring at the wrong Toni..., excuse me then for misunderstanding,, punish me, I will climb the mast!)
Looking forward to test your program, please give some explanation how you configure the program to show yourself in the bottom right corner.
(although I don't have a webcam at this moment I (and maybe others) like to know how to do it)
Fred
Yes, I was referring to Toni (aka saintless) and yourself using him as an excuse to sneak out of the far below deck developers' boiler room - though you may actually just have been throwing up over the side of the ship of course, or sneaking up for a Martini with your friend Pelo.
As for the webcam embedded in the uploaded video - that's just an extra video stream which the underlying ffmpeg/avconv program combines with the Xgrab if you select it to do so. If you look near the bottom of the video you should see three checkboxes: one for audio, one for X11grab video and one for webcam - you just click whichever you wish included. You can change the size of the webcam image to as full or tiny as you wish (there is an input box for webcam image width in pixels). The whole video can be scaled to half or lower resolution of course (another input box).
As with Precord/pAVrecord all settings are persistent for next use, so the small gui is all that is needed for general use (once it is configured to the users' liking - though the default settings should just work fine on computers with suitable specs anyway. Might not perform so well on computers with lower specs than my test machine, which is nine years old, and has 2GHz Intel Core-II duo processor and 2GB RAM. I didn't use cpufreq-set to put my computer into 'performance' mode - but that may be help - mine was just left in ondemand mode throughout the capture).
Assuming the computer has ffmpeg or avconv included, ddogxcap can therefore also pretty much replace Precord for simply recording audio streams: mp3, ogg or m4a (being aac encoded) and replaces pAVrecord for simple webcam video recording. Of course, ddogxcap (like pAVrecord before it) derives from Precord code anyway (though Precord was written to not need ffmpeg for mp3 files - Precord uses arecord | lame for that).
The fork of scrotx, by the way, includes the pretty-much untouched functionality of original scrot. So on my XenialDog system I have scrot replaced by scrotx (much the same binary size) and have a symlink called scrot pointing to scrotx.
ddogxcap can be run as a commandline app too, by the way (once earlier configured via main configure gui). That allows it to be autostarted in, for example, the background via say 'chron' (or via Pschedule, which is Puppy gui frontend for chron). It also includes a simple plugin facility so user can create, for example, their own video encoder part of the main ffmpeg/avconv command. One other reason I made it controllable from commandline is that I want to experiment with a 'motion capture' plugin I haven't yet written - though I may not bother with that since want to enjoy sunbathing on the deck beside the 'cruise-ship' bar...)
As for any release date - I'm in no hurry - still polishing up things (plenty of other screencast apps out there nowadays anyway). I'll maybe release it, as a welcome gift, once and if Toni climbs back on board to scrub the decks, which Pelo deserves to help him with. Mind you, ddogxcap won't work on what appears to be Toni's next debian-live-based offering since he is cutting out all the gtkdialog/yad crap - but he has a good idea, since doing so will make a nice clear core and the other stuff can be added in again later should it be wanted.
But anyway, perhaps the screencast app being developed on FatDog will be better, in which case I'll just leave Pelo to use that or SSR QT app instead.
William
github mcewanw
Works fine in XenialPup but TahrPup ffmpeg a bit old
Just reporting that I have now tried ddogxcap on XenialPup too and it worked fine on that system, without any alterations whatsoever. I normally use it on XenialDog, on which I developed the program (XenialDog, which is a true Ubuntu-live compatible system, should not to be confused with XenialPup, which is a woof-CE Puppy). XenialPup has ffmpeg version 2.8.6.
I also quickly tried ddogxcap on TahrPup64, but the ffmpeg version 2.7 provided there is too old to allow option asyncts. However, I was able to get it basically working with that old ffmpeg simply by creating ddogxcap plugin file ~/.ddogxcap/audio_in.plug. That audio_in.plug is simply a txt file containing the following code:
alternatively, for my system, I could simply use the following audio_in.plug instead:
That's a good example of how plugins work in ddogxcap and how they could be easily implemented in other developers scripts. I find that the biggest problem with ffmpeg/avconv frontends is the moving target situation of older ffmpeg versions or ffmpeg/avconv compiles that have different encoders (especially for aac audio) enabled, but this simple ddogxcap plugin mechanism allows for easy mods without, most of the time, having to change the main ddogxcap program itself.
It is similarly a simple job to use, for example, a different video encoder to that provided in ddogxcap by default (via a similarly created vcodec_user1.plug or vcodec_user2.plug). They are just simple txt files to be put into ~/.ddogxcap containing simple ffmpeg command snippets like the above usually.
In this audio_in.plug case I simply did not include any reference to asyncts in the ffmpegFilter_Complex0 string. The above plugin code simply overrides the default code for that section in ddogxcap itself. Note that any such plugin files are all copied into /tmp storage during actual use, so are effectively being read from RAM (assuming /tmp is tmpfs in RAM, as is the case I believe in Puppy and also in DebianDog series).
I should add, that without that newer option 'asyncts' the audio and video streams do not synchronize (at least on my old machine), so I wouldn't say default ffmpeg in TahrPup is greatly usuable from that point of view (though of course, you can simply record the Xvideo stream and add audio later with a different program).
However, audio only stream recording does work well in TahrPup (with or without that audio_in.plug). Best nevertheless, would be to install a newer version of ffmpeg or libav (avconv) for TahrPup, though I prefer to avoid the issues altogether by using XenialPup or XenialDog (which has a suitable newer libav/ffmpeg squashfs available) or similar member of DebianDog family.
William
I also quickly tried ddogxcap on TahrPup64, but the ffmpeg version 2.7 provided there is too old to allow option asyncts. However, I was able to get it basically working with that old ffmpeg simply by creating ddogxcap plugin file ~/.ddogxcap/audio_in.plug. That audio_in.plug is simply a txt file containing the following code:
Code: Select all
ffmpegFilter_Complex0=""
ffmpegAudioIn0="-f $audiosystem -ac $channels_arecord -ar 44100 -i $plughw"Code: Select all
ffmpegFilter_Complex0=""
ffmpegAudioIn0="-f alsa -ac 2 -ar 44100 -i plughw:0,0"It is similarly a simple job to use, for example, a different video encoder to that provided in ddogxcap by default (via a similarly created vcodec_user1.plug or vcodec_user2.plug). They are just simple txt files to be put into ~/.ddogxcap containing simple ffmpeg command snippets like the above usually.
In this audio_in.plug case I simply did not include any reference to asyncts in the ffmpegFilter_Complex0 string. The above plugin code simply overrides the default code for that section in ddogxcap itself. Note that any such plugin files are all copied into /tmp storage during actual use, so are effectively being read from RAM (assuming /tmp is tmpfs in RAM, as is the case I believe in Puppy and also in DebianDog series).
I should add, that without that newer option 'asyncts' the audio and video streams do not synchronize (at least on my old machine), so I wouldn't say default ffmpeg in TahrPup is greatly usuable from that point of view (though of course, you can simply record the Xvideo stream and add audio later with a different program).
However, audio only stream recording does work well in TahrPup (with or without that audio_in.plug). Best nevertheless, would be to install a newer version of ffmpeg or libav (avconv) for TahrPup, though I prefer to avoid the issues altogether by using XenialPup or XenialDog (which has a suitable newer libav/ffmpeg squashfs available) or similar member of DebianDog family.
William
github mcewanw
Ah, I'm in the movie too! Didn't catch that at first (adjusted my sound to low), anyway, thanks for having me!William wrote:Yes, I was referring to Toni (aka saintless) and yourself using him as an excuse to sneak out of the far below deck developers' boiler room
Thanks for the further info about your program.
Fred
It looks very complete, and quite polished already. I'm looking forward to a public release if you decide so. I will test it on Fatdog64. Thanks.
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
Hi step,step wrote:It looks very complete, and quite polished already. I'm looking forward to a public release if you decide so. I will test it on Fatdog64. Thanks.
I'm quite happy with it, but it's not perfect in terms of my own wishes (more wishes than needs!). I wish I could tap into the ffmpeg code itself to better implement pause functionality - simple STOP/CONT/TSTP ffmpeg process works well enough with audio but not well with video or mixed audio/video. I haven't any more sophisticated method as yet (and probably won't) but I'm still thinking about it. SSR program manages pause control very well, but that's 'easier' for SSR to do since able to more precisely control ffmpeg process threads since SSR is using C++. Otherwise I'm reasonably happy in terms of ease of use and performance.
It is possible (maybe?) I could write a small C utility, simply to better effect pause functionality, and use that as a go-between from my ddogxcap shell script, but far from trivial to implement that since I'd have to study ffmpeg code itself first, and I'm not convinced I want to spend so much effort now for that one single matter! Also, I wouldn't be surprised if ffmpeg (and avconv) didn't itself finally provide a good accessible pause mechanism - perhaps it already does(?) - though I don't think so. I certainly don't want to spend days trying and then a new ffmpeg comes out that provides the function anyway! So I guess ddogxcap will have to remain with that imperfection. The alternative of cutting up the recording into sections (each time there is a pause) and joining them back together again at the end is painful to me, so I doubt I will bother doing that either.
What would work for me would be to have a utility that removed parts of the output audio/video file based on gaps with silence in them (since the audio track pauses fine). Hoped to find such a utility via googling but haven't come across one as yet - the alternative is manual editing via something like Avidemux or Openshot, but would love it to be automatic and without using a large extra media-processing app. I do still have some job control options to examine though I'm not convinced that will work because of video stream buffers and timestamp issues - but maybe I'll get lucky.
William
Last edited by mcewanw on Sat 23 Jul 2016, 12:34, edited 2 times in total.
github mcewanw
Mic's certainly do pick up on the PC whirring noise (or was that the sound of the ships engines 
). A trick I learned from one of Sneeky's vids was to use Audacity to clean up the sound track. Amplify or attenuate if too quiet/loud, and there's a noise filter where you can highlight/select a quiet bit of track (when you're not speaking) and apply that as a filter to the entire track i.e. exclude PC fan noise (in the case of the fan speeding up however as per your vid, I guess you'd have to apply noise filters for two different background noise samples). Openshot is good for editing the vid, especially if you add in Blender and full blown inkscape (the puppy cut down version doesn't work properly with Openshot) as they they enable you to add in the likes of animated 3D titles, scrolling titles etc.
). A trick I learned from one of Sneeky's vids was to use Audacity to clean up the sound track. Amplify or attenuate if too quiet/loud, and there's a noise filter where you can highlight/select a quiet bit of track (when you're not speaking) and apply that as a filter to the entire track i.e. exclude PC fan noise (in the case of the fan speeding up however as per your vid, I guess you'd have to apply noise filters for two different background noise samples). Openshot is good for editing the vid, especially if you add in Blender and full blown inkscape (the puppy cut down version doesn't work properly with Openshot) as they they enable you to add in the likes of animated 3D titles, scrolling titles etc.Whilst I am nearing completion of polishing up ddogxcap I am also moving to a 2-day per week only development cycle (rather than the often 7 days/wk I've been working on since beginning this).
I've become quite happy with the interface and performance now, but, having used it for a while now, have a couple of extra ideas I am considering additionally implementing. I will try these new ideas and then decide if the extra functions are worth it or not, give everything a final 'rigorous' test and polish and then likely release it. I am even considering sending a pre-official-release copy to Pelo in the nearish future, just to keep him busy, since he has a penchant (say that with a french accent) for these kind of apps.
It remains, and likely will remain the case, that the simple pause control mechanism used (STOP/CONT) only really works well in ffmpeg/avconv for audio stream. I have thought long and hard about this and don't think it is worth while implementing a "record the whole video in multi-segments and then stitch them together" approach to pausing av video. Despite the fact that approach could be made to work, and transparently from users point of view, it is a real kludge that required extra utilities, for different video containers, for the stitching back together and so on. So would also add lots of bloat to the installation. No thanks.
Anyway, my view is that if a user wants to create 'professional class' screencasts they would be better recording separate date-stamped video segments (rather than pause) and join them later in special utility for that or using video editor program. Also, they may well record video track separately and add an audio track later, so, as far as av video creation is concerned, pause control is really just for home video creators who are satisfied with a one-off non-edited recording. What is more important IMO is the quality of the recording and the simple flexibility of the gui.
Having said that, I continue to hope that ffmpeg/avconv developers will implement pause (rather than just quit) functionality in ffmpeg/avconv itself. They may eventually do so (it really needs to be implemented internally to clear audio/video buffers/fix timestamps etc - certainly a C/C++-coded program can tap into the internal libraries and do that (probably using av_rescale_q, and av_init_packet as part of it), but not a simple shellscript frontend methinks). I believe ffmpeg current accepts Ctrl-C (SIGTERM) to effect stop, so hopefully they will one day allow SIGSTOP/SIGTMPT and SIGCONT to effect pause (in which case that functionality is already provided in ddogxcap) - but it is no big deal.
By the way, I have renamed my new program because ddogxcap doesn't roll round my scottish tongue easily enough, so will likely publish it in a new thread with the new name soon (maybe a few days, maybe a couple of weeks, but not long away I currently feel). Anyway, posting on here is just an excuse for me to avoid the work and get a short rest - this being one of my two assigned development days, I better get on with it...
William
EDIT: It will soon be August, so winter will be drawing to a close soon in this part of the world. Once summer arrives I pretty much stop using my computer altogether (if last year is anything to go by). For one thing, I don't like taking my laptop in the kayak... for another, it is good to catch up with my children before I forget their names. Nor do I believe development efforts (or sitting at the computer more generally) is good for my otherwise very healthy relationship. I do hope Fred (from DebianDog) and others also realise the marital dangers associated with programming.
You may think your loved ones are ultra-thankful that you are putting such a nice OS or program onto their computers for them (and many of you love telling your stories in apparent confirmation of that), but the truth is they secretly probably prefer 'Windows' and wish you would leave them alone to use it, and your grandparents are just being kind, and pretend the system is wonderful when you install your Dog or Puppy for them. They love you despite knowing you are a bit eccentric and a bit of a techno-lunatic, but get back to Windows as soon as they hear the door closing on your departure.
I've become quite happy with the interface and performance now, but, having used it for a while now, have a couple of extra ideas I am considering additionally implementing. I will try these new ideas and then decide if the extra functions are worth it or not, give everything a final 'rigorous' test and polish and then likely release it. I am even considering sending a pre-official-release copy to Pelo in the nearish future, just to keep him busy, since he has a penchant (say that with a french accent) for these kind of apps.
It remains, and likely will remain the case, that the simple pause control mechanism used (STOP/CONT) only really works well in ffmpeg/avconv for audio stream. I have thought long and hard about this and don't think it is worth while implementing a "record the whole video in multi-segments and then stitch them together" approach to pausing av video. Despite the fact that approach could be made to work, and transparently from users point of view, it is a real kludge that required extra utilities, for different video containers, for the stitching back together and so on. So would also add lots of bloat to the installation. No thanks.
Anyway, my view is that if a user wants to create 'professional class' screencasts they would be better recording separate date-stamped video segments (rather than pause) and join them later in special utility for that or using video editor program. Also, they may well record video track separately and add an audio track later, so, as far as av video creation is concerned, pause control is really just for home video creators who are satisfied with a one-off non-edited recording. What is more important IMO is the quality of the recording and the simple flexibility of the gui.
Having said that, I continue to hope that ffmpeg/avconv developers will implement pause (rather than just quit) functionality in ffmpeg/avconv itself. They may eventually do so (it really needs to be implemented internally to clear audio/video buffers/fix timestamps etc - certainly a C/C++-coded program can tap into the internal libraries and do that (probably using av_rescale_q, and av_init_packet as part of it), but not a simple shellscript frontend methinks). I believe ffmpeg current accepts Ctrl-C (SIGTERM) to effect stop, so hopefully they will one day allow SIGSTOP/SIGTMPT and SIGCONT to effect pause (in which case that functionality is already provided in ddogxcap) - but it is no big deal.
By the way, I have renamed my new program because ddogxcap doesn't roll round my scottish tongue easily enough, so will likely publish it in a new thread with the new name soon (maybe a few days, maybe a couple of weeks, but not long away I currently feel). Anyway, posting on here is just an excuse for me to avoid the work and get a short rest - this being one of my two assigned development days, I better get on with it...
William
EDIT: It will soon be August, so winter will be drawing to a close soon in this part of the world. Once summer arrives I pretty much stop using my computer altogether (if last year is anything to go by). For one thing, I don't like taking my laptop in the kayak... for another, it is good to catch up with my children before I forget their names. Nor do I believe development efforts (or sitting at the computer more generally) is good for my otherwise very healthy relationship. I do hope Fred (from DebianDog) and others also realise the marital dangers associated with programming.
You may think your loved ones are ultra-thankful that you are putting such a nice OS or program onto their computers for them (and many of you love telling your stories in apparent confirmation of that), but the truth is they secretly probably prefer 'Windows' and wish you would leave them alone to use it, and your grandparents are just being kind, and pretend the system is wonderful when you install your Dog or Puppy for them. They love you despite knowing you are a bit eccentric and a bit of a techno-lunatic, but get back to Windows as soon as they hear the door closing on your departure.
github mcewanw
You made my day!
mcewanw wrote: You may think your loved ones are ultra-thankful that you are putting such a nice OS or program onto their computers for them (and many of you love telling your stories in apparent confirmation of that), but the truth is they secretly probably prefer 'Windows' and wish you would leave them alone to use it, and your grandparents are just being kind, and pretend the system is wonderful when you install your Dog or Puppy for them. They love you despite knowing you are a bit eccentric and a bit of a techno-lunatic, but get back to Windows as soon as they hear the door closing on your departure.
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
-
Pelo
I am completely for how-to by video.
I watched to the video on you Tube. I am completely for how-to by video. In spite of we don't understand comments, we guess the lesson only by images;
Who is talking on the video ?
About ddogxcap, it does the job, regarding to the Youtoube video.
Who is talking on the video ?
About ddogxcap, it does the job, regarding to the Youtoube video.
Final remarks on ddogxcap.
Well, I think the now polished-up ddogxcap program is finally completed to my 'near' satisfaction. I've taken some time over this since I am contemplating it being my last published effort (or maybe one more?) and (with that decision in mind) I have designed it such that I can easily maintain it and change some functionality via simple plugins (which are simply very short code extracts kept in tiny generally user-editable text files - a few simple plugins will be supplied as working/editable exemplars).
I believe the quality of the screencasts should be pretty much identical to those able to be produced by Simple Screen Recorder (since I think the default encoder and primary ffmpeg quality settings are the same as the SSR default (x264, superfast with crt 23). All of that is easily edited/changed by the user and I have designed the program so the user can adjust any ffmpeg setting or encoder commandline via editing the simple plugins. The program in fact includes some features not currently available with SSR (for example, embedded webcam stream, if so selected) and also some reasonably good integration with commonly installed puppy/debiandog av utilities such as mhwaveedit, ffconvert, dogradio, pupradio, VideoToAudioExtract, and DoMyFile etc (user can edit the post-processing apps list - it's a simple text file).
The whole installed package is less than 100 kB in size uncompressed and unlike SSR requires no QT libs whatsoever, so might be useful for anyone trying to get back to creating as small a puppy-like system as possible (personally I don't like the movement into multiple gtk and qt libs in standard puppy or puppy-like systems - as well using more mainstream distributions in that case IMO). The app does require ffmpeg or libav (avconv) installed (or loaded via sfs load) however, since, as usual, that provides most of the underlying functionality.
The new app does have a limitation, in that pause control only works properly with audio, and it is slow to load initially following a reboot of my XenialDOg system (but fast thereafter) - so be patient with it for that initial load... Since SSR is able to access ffmpeg library audio/video/muxer threads direcly via C++, it can correctly pause X11 video capture - I'm hoping ffmpeg will later itself provide better access to internal threads via bash via ffmpeg commandline args - simple SIGSTOP of the record process is insufficient. I don't consider that a big deal though - more professional screencasts are better, I feel, created by saving separate date-stamped video segments and then joining them together later (rather than simple pause). That is easy to achieve with the new program. Oh, and I have made no attempt to include special OpenGL capture capability, since standard X capture at even quite high frame rates seems to work perfectly well for my own needs (at say, 30 fps or more) on my nine year old Intel Core II duo, 2GHz cpu system, which has 2GB of RAM - lower spec machines are always likely to have issues anyway as do old versions of ffmpeg/avconv. I do expect to be able to get reasonable results with somewhat slower machines - no worse than SSR could achieve anyway.
In any case, the new program can be used as a direct replacement for both precord and pavrecord (it being the much-improved descendant of these) with much more functionality. And for audio recording, pause works fine, which is when it is most useful I feel (e.g. recording short mp3 or ogg audio clips on the fly).
I am, by the way, renaming the app since ddogxcap does not easily roll off my Scottish tongue. On release, I will accordingly be starting a new thread and this thread should be considered now closed.
Following expected release for download next week, I will be taking an extended holiday so please don't be offended or surprised if I do not respond for a long time (if at all) to any comments. I will take note of any bug descriptions however and consider addressing these sooner or later.
William.
I believe the quality of the screencasts should be pretty much identical to those able to be produced by Simple Screen Recorder (since I think the default encoder and primary ffmpeg quality settings are the same as the SSR default (x264, superfast with crt 23). All of that is easily edited/changed by the user and I have designed the program so the user can adjust any ffmpeg setting or encoder commandline via editing the simple plugins. The program in fact includes some features not currently available with SSR (for example, embedded webcam stream, if so selected) and also some reasonably good integration with commonly installed puppy/debiandog av utilities such as mhwaveedit, ffconvert, dogradio, pupradio, VideoToAudioExtract, and DoMyFile etc (user can edit the post-processing apps list - it's a simple text file).
The whole installed package is less than 100 kB in size uncompressed and unlike SSR requires no QT libs whatsoever, so might be useful for anyone trying to get back to creating as small a puppy-like system as possible (personally I don't like the movement into multiple gtk and qt libs in standard puppy or puppy-like systems - as well using more mainstream distributions in that case IMO). The app does require ffmpeg or libav (avconv) installed (or loaded via sfs load) however, since, as usual, that provides most of the underlying functionality.
The new app does have a limitation, in that pause control only works properly with audio, and it is slow to load initially following a reboot of my XenialDOg system (but fast thereafter) - so be patient with it for that initial load... Since SSR is able to access ffmpeg library audio/video/muxer threads direcly via C++, it can correctly pause X11 video capture - I'm hoping ffmpeg will later itself provide better access to internal threads via bash via ffmpeg commandline args - simple SIGSTOP of the record process is insufficient. I don't consider that a big deal though - more professional screencasts are better, I feel, created by saving separate date-stamped video segments and then joining them together later (rather than simple pause). That is easy to achieve with the new program. Oh, and I have made no attempt to include special OpenGL capture capability, since standard X capture at even quite high frame rates seems to work perfectly well for my own needs (at say, 30 fps or more) on my nine year old Intel Core II duo, 2GHz cpu system, which has 2GB of RAM - lower spec machines are always likely to have issues anyway as do old versions of ffmpeg/avconv. I do expect to be able to get reasonable results with somewhat slower machines - no worse than SSR could achieve anyway.
In any case, the new program can be used as a direct replacement for both precord and pavrecord (it being the much-improved descendant of these) with much more functionality. And for audio recording, pause works fine, which is when it is most useful I feel (e.g. recording short mp3 or ogg audio clips on the fly).
I am, by the way, renaming the app since ddogxcap does not easily roll off my Scottish tongue. On release, I will accordingly be starting a new thread and this thread should be considered now closed.
Following expected release for download next week, I will be taking an extended holiday so please don't be offended or surprised if I do not respond for a long time (if at all) to any comments. I will take note of any bug descriptions however and consider addressing these sooner or later.
William.
github mcewanw
The finished ddogxcap, renamed weX is now currently available for a short time here:
http://www.murga-linux.com/puppy/viewtopic.php?t=107905
William
http://www.murga-linux.com/puppy/viewtopic.php?t=107905
William
github mcewanw