https://github.com/chilicuil/ffcast
Bests
]]>It might be easier to manually use ffmpeg for screencasting at this point, but FFcast gives the distinct advantage of allowing you to easily select a recording window/area.
]]>Do you happen to know if lolilolicon is continuing to develop/maintain ffcast2?
It appears that development has stalled, but I wouldn't call it dead. I don't know really. You can also try recordmydesktop 2.0 as mentioned earlier in this thread, but I haven't tried it. There is also recordscreen, but that one is also untried by me. Both of these appear to use ffmpeg.
]]>Dirk Sohler wrote:Is there a way to pause and continue recordings without completely stopping the recording?
You can try pkill as shown here.
I haven't tried this.
]]>Also, a question about usage. I record fairly lengthy screencasts which I need to pause on occasion. I know that's not really possible with ffcast and ffmpeg's x11grab. To date, I've just ended the video and started a new one, joining together the resulting separate files with a nice script I found on-line that does just that (called mmcat). I think, however, that this sort of joining is unlikely to work very well with the screen-grabbing functionality of ffcast--that because the grabbed region of the video files is likely to differ, even if only very slightly.
My question, then, is whether my assumption that joining resulting video files is unlikely to work well is a correct one?
Thanks,
James
Hey guys, I created https://github.com/kaihendry/recordmydesktop2.0 that hopefully helps you guys. Be ideal to merge projects or work together.
Interesting. Why ffvhuff? Do you find that it performs better than huffyuv, ffv1, (lib)utvideo, or libx264 (lossless with ultrafast preset)? Why flac instead of pcm_s16le?
The convenience of using the native FFmpeg AAC encoder (-c:a aac -strict experimental) may outweigh the need to compile for the higher quality of libfaac. The native FFmpeg AAC encoder isn't as bad as most people think. Or if possible use the native encoder as a fallback so at least an output can be created despite the encoder situation. Also, people are lazy. Just something to consider.
]]>Is there a way to pause and continue recordings without completely stopping the recording?
You can try pkill as shown here.
]]>Another question: Is there a way to pause and continue recordings without completely stopping the recording?
]]>Is there a way to give ffcast a default X geometry syntax like area to record like 724x396+76+96 for example? I want to record videos in an exactly defined area having an exact width and height.
The most basic command using your geometry would be:
ffcast 724x396+76+96
But I have a question: Is there a way to give ffcast a default X geometry syntax like area to record like 724x396+76+96 for example? I want to record videos in an exactly defined area having an exact width and height.
]]>Two major changes since 1.0rc3:
Backward compatibility breakage of the -m option. -m now requires an integer. The default behavior without -m is unchanged; `-m 16' is equivalent to the old `-m'. This gives better control; the trimming of the region can be disabled with `-m 1' for example.
New feature as suggested by Mad Fish and Cloudef. Support selecting specific Xinerama heads (physical displays) via the -x option.
For example, to capture the 1440x900 head of your dual-headed setup:
$ ffcast -x list
head #0: 1440x900 @ 0,124
head #1: 1280x1024 @ 1440,0
$ ffcast -x 0
As usual, if there're other selections, they will be combined by union.
This feature introduces new dependency on xdpyinfo.
FFcast has come a long way since the initial commit. I'm impressed
]]>