FD-710 alpha comes with a screen cap script that does audio and video. I think you can find it in the multimedia menu. An improved GUI as well a couple of bug fixes are coming in the FD-710 beta, but the current script core should be enough to show how jamesbond glued a/v streams together.smokey01 wrote:I just built the latest version, 3.1.1, for fatdog64-710 and made a sfs.
http://smokey01.com/fd710/sfs/
Problems using ffmpeg (Solved)
[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]
Step, if you mean Screencast.sh then it doesn't work here. It never worked properly in any of the 700 series for me. AVI does work but very poor quality even checked as high quality. Have you tried all the variations? Does it work for you?step wrote:FD-710 alpha comes with a screen cap script that does audio and video. I think you can find it in the multimedia menu. An improved GUI as well a couple of bug fixes are coming in the FD-710 beta, but the current script core should be enough to show how jamesbond glued a/v streams together.smokey01 wrote:I just built the latest version, 3.1.1, for fatdog64-710 and made a sfs.
http://smokey01.com/fd710/sfs/
Even after a quick glance, I can see why the video resolution is so bad.
The values for VIDEO_BITRATE (for all codecs/options) are way too small, in fact they are even smaller than the audio in many cases.
For low, it should be around 250K, for medium around 1M and for high around 5M.
Note however that if your screen resolution is around 1920 X 1080 or higher, then you may want to make the "high" setting even larger at say around 8M or even 10M.
Sure the file sizes will be much greater, but if you want better quality, you will also get bigger file sizes.
Depending on the FFmpeg version, , the "M's" may have to be written as "K's", i.e 1M = 1000K, and 5M = 5000K.
The variable VIDEO_BIT_TOLERANCE is not required.
The audio parameters could be bumped up as well.
For example 11.025KHz is just above telephone quality, not great.
I will study the script in more detail and comment further.
The values for VIDEO_BITRATE (for all codecs/options) are way too small, in fact they are even smaller than the audio in many cases.
For low, it should be around 250K, for medium around 1M and for high around 5M.
Note however that if your screen resolution is around 1920 X 1080 or higher, then you may want to make the "high" setting even larger at say around 8M or even 10M.
Sure the file sizes will be much greater, but if you want better quality, you will also get bigger file sizes.
Depending on the FFmpeg version, , the "M's" may have to be written as "K's", i.e 1M = 1000K, and 5M = 5000K.
The variable VIDEO_BIT_TOLERANCE is not required.
The audio parameters could be bumped up as well.
For example 11.025KHz is just above telephone quality, not great.
I will study the script in more detail and comment further.
Aha, thanks and so it has.
Code: Select all
ffmpeg -h full | grep isync
snip
-isync this option is deprecated and does nothing
smokey01 wrote:Step, if you mean Screencast.sh then it doesn't work here. It never worked properly in any of the 700 series for me. AVI does work but very poor quality even checked as high quality. Have you tried all the variations? Does it work for you?step wrote:FD-710 alpha comes with a screen cap script that does audio and video. I think you can find it in the multimedia menu. An improved GUI as well a couple of bug fixes are coming in the FD-710 beta, but the current script core should be enough to show how jamesbond glued a/v streams together.smokey01 wrote:I just built the latest version, 3.1.1, for fatdog64-710 and made a sfs.
http://smokey01.com/fd710/sfs/
Code: Select all
# 5. build the commandline to be passed
FFMPEG_ARGS="-y -f x11grab -s $SOURCE_RES -r $FRAME_RATE -i ${XDISPLAY_NUMBER}+${SOURCE_ORG}"
if [ $RECORD_AUDIO = "true" ]; then
FFMPEG_ARGS="${FFMPEG_ARGS} -f alsa -ac $AUDIO_CHANNEL -ar $AUDIO_SAMPLERATE -i $AUDIO_DEVICE -isync -acodec $AUDIO_CODEC -ab $AUDIO_BITRATE"
fi
FFMPEG_ARGS="${FFMPEG_ARGS} -r $FRAME_RATE -vcodec $VIDEO_CODEC -s $TARGET_RES -b:v $VIDEO_BITRATE -bt $VIDEO_BIT_TOLERANCE $VIDEO_OPTION -f $FORMAT "
#echo "$FFMPEG_ARGS"
Code: Select all
-preset slow
Main thing here was just to give a commandline that works on modern ffmpeg (can remove options that aren't recognised for older ffmpegs, but results will vary). Fact is ffmpeg is a moving target due to development as eventually machine specs. My laptop core2 duo is more than 8 years old, and works fine with newer ffmpeg, so it seems appropriate to me to write new app based on that (and modify older apps).
William
github mcewanw
My own app includes an output of the exact ffmpeg command used, particularly so other developers can use the core command options in modifying or updating their own works. Otherwise we are writing apps that simply become obsolete after a year or two. My first version will simply include codecs that work for me on my system (which as I say isn't a particularly modern or fast machine anyway, but faster than some I've recently retired...). I have however left provision in both the code and my gui for adding some other codecs depending on my needs and possible requests. However, I'm keen to see as many such apps as possible, since variety is a good thing especially since everyone has their own 'tricks' we can learn from. That's the only reason I'll be publishing any apps nowadays since I only write them for my family needs, and I find I can't be bothered coding much nowadays (this last was a big effort for me - had the idea two years ago but slow... to start coding it... too lazy now and too much effort) and plenty better apps than any of mine out there nowadays anyway (not surprisingly!). Anyway, back to my less-than-wonderful app or I'll never finish it - everything working but a few little bits I'm playing around with in terms of functionality and I'm chopping and changing how the gui looks for my tastes. Not particularly worth waiting on though (just use a good commandline...), so hope someone writes something better.
William
EDIT: Actually, I prefer commandlines, which ironically means that the only gtkdialog app I've written that I particularly like is DoMyFile (along with Premote, and DoMyCommand, which are just variations of the same). I expect hardly anyone else uses that much if at all though, so was probably not worth my publishing it really (aside from sharing ideas)! Well, I do use Precord since it makes it quick and easy to open up mixer and check capture settings and allow quick opening of the record target directory, otherwise I'd probably just use a commandline for audio recording too... (or DoMyFile for the quick convenience). Actually, I might produce/extend at least one more app for my own satisfaction since I'd like to stick start/stop/pause buttons on DoMyFile since that's a convenience I like - then I can play around with commandlines to my hearts content thereafter (Pelo hates that approach of course since he seems to think 'passengers' as he refers to himself have no use for commands, which is just the simplest form of coding really)!
The worst and totally unhelpful thing, in my opinion is when someone talks as if knowledgeable but doesn't give a complete and tested command (talking generally, by the way, not about this thread or anyone in particular - I would say, however, that it is usually easy to pull-apart others code, and worth making suggestions, but all code takes a lot of work and most authors had reasons for their decisions - often better to write your own code if you can, if not happy with something, and making constructive suggestions based on that). We can all read, but only testing sorts through the junk, so it is not IMO helpful to simply suggest command options which may only have been read about by someone who has never tested the option in practice themselves. A tested command, on the other hand, saves a huge amount of re-reading and actual in-practice testing. If you haven't tested the option or command yourself, don't bother talking about it - at the most just provide a link to the page you read, in case it proves useful or relevant. The reason I say this is because of the amount of time I've wasted trying to find up-to-date actual working code for various needs when browsing the internet (or this forum) - there is so much out-dated info or rubbish re-gurgitated out there, it just makes the whole process of finding actual 'working' answers all the more difficult. At least Pelo doesn't pretend to code or use commandlines, so I thank him for not providing false leads...
William
EDIT: Actually, I prefer commandlines, which ironically means that the only gtkdialog app I've written that I particularly like is DoMyFile (along with Premote, and DoMyCommand, which are just variations of the same). I expect hardly anyone else uses that much if at all though, so was probably not worth my publishing it really (aside from sharing ideas)! Well, I do use Precord since it makes it quick and easy to open up mixer and check capture settings and allow quick opening of the record target directory, otherwise I'd probably just use a commandline for audio recording too... (or DoMyFile for the quick convenience). Actually, I might produce/extend at least one more app for my own satisfaction since I'd like to stick start/stop/pause buttons on DoMyFile since that's a convenience I like - then I can play around with commandlines to my hearts content thereafter (Pelo hates that approach of course since he seems to think 'passengers' as he refers to himself have no use for commands, which is just the simplest form of coding really)!
The worst and totally unhelpful thing, in my opinion is when someone talks as if knowledgeable but doesn't give a complete and tested command (talking generally, by the way, not about this thread or anyone in particular - I would say, however, that it is usually easy to pull-apart others code, and worth making suggestions, but all code takes a lot of work and most authors had reasons for their decisions - often better to write your own code if you can, if not happy with something, and making constructive suggestions based on that). We can all read, but only testing sorts through the junk, so it is not IMO helpful to simply suggest command options which may only have been read about by someone who has never tested the option in practice themselves. A tested command, on the other hand, saves a huge amount of re-reading and actual in-practice testing. If you haven't tested the option or command yourself, don't bother talking about it - at the most just provide a link to the page you read, in case it proves useful or relevant. The reason I say this is because of the amount of time I've wasted trying to find up-to-date actual working code for various needs when browsing the internet (or this forum) - there is so much out-dated info or rubbish re-gurgitated out there, it just makes the whole process of finding actual 'working' answers all the more difficult. At least Pelo doesn't pretend to code or use commandlines, so I thank him for not providing false leads...
github mcewanw
That was already in the program, Pete, there is a checkbox to create or not create ffmpeg log (uses FFREPORT for those who want to do similar).Pete wrote: I'm not sure how close to completion your program is, but think about possibly giving the user some feedback from ffmpeg.
As in, example:
Code: Select all
FFREPORT=file=/tmp/myprogram.log:level=32 ffmpeg
followed by rest of ffmpeg commandline options per already posted
Again, as in my now aging pavrecord (which itself is needing brought up-to-date with ffmpeg changes), I have allowed for creation of separate audio or video tracks already. Though, unlike in pavrecord, I join the separate audio and video commands into one to the commandline form I already posted above. In pavrecord, which was really designed for capturing webcam and not much for screencast work, the av tracks are later combined using ffmpeg, whereas in my new app, as I said, it ends up being a one-liner, which is easier to control (though more difficult to manually adjust sync, which I haven't found the need to do for my laptop anyway).Pete wrote: You may also want to give an option for selecting with or without audio.
Anyway, I'd better get back to work polishing the gui up a bit or it will be another two years before I post it. Alas, when I'm coding, I get bored and seek distractions, and I turn to forum thread posting, which at other times I try to minimise to direct help requests or DebianDog testing/helping developments. Just happened to see smokey01s request for ffmpeg commandline solution and coincidentally had that at my fingertips.
William
github mcewanw
That's fine smokey01. Just what I expected from someone once I posted that commandline - like I basically said, the more the merry and with most open-source licenses can freely publish code extracts with nothing more than acknowledgements if appropriate - not expected for just the underlying commandline! :-) Your app might be just what people want. My more complicated (yet hopefully also very simple to use) gui will be a few days yet probably.smokey01 wrote:Sorry, I couldn't help myself. I just had to make a simple GUI. For the moment I've called it VSSR (Very Simple Screen Recorder).
It's huge, make sure you have lots of disk space :lol:
William
github mcewanw
Yes, I meant screencast.sh. It works for me, audio and video, avi and mp4 with FD-710a2. I tested the version that will be included in the 710 beta cycle. Attached. Feedback is welcome - perhaps this script can be further improved before beta starts. Note that I tested small size capture windows only at default quality. I'm quite far from understanding all ffmpeg and multimedia quality nuances.smokey01 wrote: Step, if you mean Screencast.sh then it doesn't work here. It never worked properly in any of the 700 series for me. AVI does work but very poor quality even checked as high quality. Have you tried all the variations? Does it work for you?
- Attachments
-
- fatdog64-710b1-screencast.tar.gz
- for fatdog64 710 beta, currently unreleased, might still change, I don't know
- (6.16 KiB) Downloaded 125 times
[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 and SSR,step wrote:Yes, I meant screencast.sh. It works for me, audio and video, avi and mp4 with FD-710a2. I tested the version that will be included in the 710 beta cycle. Attached. Feedback is welcome - perhaps this script can be further improved before beta starts. Note that I tested small size capture windows only at default quality. I'm quite far from understanding all ffmpeg and multimedia quality nuances.
Nice program with lots of potential. Just tried it - wish I had known about it a week ago and I might not have bothered pursuing my own one (and still might not once your one is final - I'm feeling lazy and fed up programming... but I may complete my own alternative anyway if only to inspire you to further develop your one).
Your program did record, but there seems to be a current problem of it leaving ffmpeg processes lying around after completion requiring me to manually killall ffpeg before running again.
As for more on ffmpeg -x11cap options, coincidentally I just came across a nice webpage that has tons of good info you might find useful in your developments. I hadn't seen it before (but again wish I had!):
https://ubuntuforums.org/archive/index. ... 92026.html
It also gives link to FFcast (which I've tried in the past):
https://github.com/lolilolicon/FFcast
and well as that author's xrectsel, which I see you are using as underlying screen area coord find in your app:
https://github.com/lolilolicon/xrectsel
Though I knew about xrectsel, I'm not myself using it in my app since I wanted to avoid having to also use xwininfo so did a bit of my own coding in C, which I probably will publish later, though probably changing its output format first (actually that's the main thing I was coding - my screencast GUI was originally just supposed to be very simple just for testing my C utility.
Anyway, looking forward to seeing your finished product - i note you are not currently implementing pause functionality, which would be a nice addition (though tricky to implement for video with ffmpeg - I believe SIGSTOP, SIGCONT don't really work properly (with av streams being recorded in a one-liner at least) - they mess up timestamps and leave gaps usually.
William
NOTE: that there is a probably reliable method of implementing pause functionality given in the above HOWTO link - using mkvmerge utility (package name mkvtoolnix - only for mkv of course).
github mcewanw
Hi mcewanw, thanks for your feedback and ideas. On fatdog64 710, which is the intended platform for this script, I don't see ffmpeg processes hanging. Maybe it's specific to your pet?
[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]