Post record optimisation
cdplayer opened this issue · comments
From personal experience it's a tall ask to record in one step on low performance computers.
Suggest add option to post-optimise the original 'uncompressed' file recorded
Here is what is used (...before finding ffscreencast)
- i record in as efficient a format as I could find for low performance cpu AND _drive. i could be wrong about libx264 and rgb24 usage.
- i also record only 640x480/vga/sntsc at 20 fps then reduce to 10
- 18MB -> 1.1MB
- libopus support for mono 16-20 kbps is very efficient for voiceovers
- i've also been looking for a way to record 'faked' mouseclick sounds and keypresses into a channel so it's not using the microphone to record the typing. could use same solution to show modifier and function keys pressed on overlay see
https://github.com/wavexx/screenkey
#my 60 second test record
ffmpeg -f x11grab -framerate 20 -video_size 640X480 -i :0.0 -c:v libx264rgb -pix_fmt rgb24 -tune animation -crf 0 -preset ultrafast -t 60 raw.mp4
one minute is about 16mb
#my_ re-compress, oddly -crf 35 still looks good.
ffmpeg -i raw.mp4 -c:v libx264rgb -r 10 -preset veryslow -crf 35 -tune animation -movflags faststart compressed.mp4
Hi @cdplayer ,
thanks for the input. I am still trying to find the best balance between compression (size) and performance on old cpu's.
However, when you want to adjust the way it records, you can simply use --sargs and --oargs.
To verify your command without executing it, simply add --dry (which will only show what would be executed).
I could almost mimic your command with the exception of the resolution as this is auto-picked according to your screen resolution.
$ ffscreencast --oargs="-pix_fmt rgb24 -tune animation -crf 0 -preset ultrafast -t 60" \
--sargs="-framerate 20" --dry
/usr/local/bin/ffmpeg -hide_banner -loglevel info -thread_queue_size 512 \
-f avfoundation -video_size 2880x1800 -framerate 20 -i "1" -c:v libx264 \
-pix_fmt rgb24 -tune animation -crf 0 -preset ultrafast -t 60 -threads 0 \
"/Users/cytopia/Desktop/Screencast 2016-08-26 at 21.48.55.mkv"Also note that you can add your presets to ~/.config/ffscreencast/ffscreencastrc so you can start it without any arguments and it will use the defined defaults.
Post processing is a neat topic as well, however i would not integrate it, but separate it into a different tool, which could output videos based on presets, including nice gif versions.
Things i've found
- some record format like huffyyuv take a load off the processor, BUT add a huge load to disk writing time and space. ffvhuff is slighty better or preffered by ffmpeg.
- documentation of ffvhug, rawvideo, huffyyuv is quite poor especially in terms of disk space usage and also how each effects cpu usage. the
'-crf 0 -preset ultrafast'to create the intermediate file does appears to be good for performance and disk space usage. - further understanding of the -tune options may lead to better efficiencies. I understand you can compound these commands.
-tune animation -tune zerolatency - libx264rgb and libx264 are different. Mostly people use libx264 but is focus towards video (yuv colorspace) as apposed to displays(rgb/rbg). screencasts (without camera overly) at least seem best to use libx264rgb/rgb24 and pixel formats other than YUV.
- With x264 codecs being so efficient and widely used i was wondering if there are other codecs (other than x264) that ffmpeg supports that is as good as or better for highly efficient playback of screen recordings. My work so far has mostly been around finding most efficient and most compatibly settings for playback with x264 based playback facilities.
- I was thinking of having a package type recording being made that had video and audio and camera in seperate files. Was also looking for ways you could add subtext/subtitles to the video (maybe by hand). I'm away of youtubes ability to add this (sort of automatically).
So I would suggest we pick a couple of potential defaults for initial recording, compile a nice way for benchmarking them on different machines and ask people to help collect benchmark data on that.
Best would be to have a standalone Benchmark.md page with all results for different hardware.
Once done I could integrate different presets into ffscreencast for easier recording.
Tasks that would still have to be done is
- Post processing (in another script)
- Separating input videos into different streams (which I find quite nice)