| Age | Commit message (Collapse) | Author |
|---|
|
Technically fixes a leak, but it's benign since we're shutting
down anyways.
|
|
This changes --use-jack PORT to expect a single port in its
argument, since popt doesn't really support what was being
attempted.
Instead, to specify multiple JACK ports, you just repeat
--use-jack PORTN N times, e.g:
--use-jack system:capture_1 --use-jack system:capture_2
This way we don't get into the business of parsing multiple ports
from a single argument, and picking which separator to use. It
appears JACK port names don't have any reserved characters,
judging from the API docs and a brief perusal of the code. So we
couldn't even pick a bulletproof separator if we wanted to.
Fixes https://github.com/recordmydesktop/recordmydesktop/issues/8
Jack support is totally untested in my fork so it's largely
as-inherited still.
|
|
Some mistakes here noticed as slight colorshift corruption for
odd-width recorded windows.
|
|
When --windowid specifies a window that hasn't yet been mapped
this thing would just exit.
But in scripted invocations where a window of interest is created
and mapped by the client immediately prior to launching
recordMyDesktop, there's a good chance the window manager hasn't
yet handled the MapRequest before recordMyDesktop launched and
attempted to get the window's attributes.
This change subscribes to the window's visibility and structure
events when the attributes show it's not yet mapped and visible,
entering into an event loop waiting for the window.
No timeout has been added at this time.
Some interesting directions to go from here:
- Pause recording on unmap, resume recording on map
- Follow the window if it moves
- It'd be nice if recording could handle window resizes, but
especially for on-the-fly encoding this seems awkward at best.
For cached recordings the encode could start with the largest
dimensions and simply pad out any smaller frames.
I'll have to look at Theora to see if there is any support for
variable sized video streams.
Fixes https://github.com/recordmydesktop/recordmydesktop/issues/7
|
|
Fix some minor whitespace/indentation inconsistency.
|
|
Trivial cosmetic changes noticed while glancing at --help
|
|
We no longer bother with such things in this fork. It's worth
noting the original codebase bothered with these things in places
where it was altogether unnecessary.
This means --follow-mouse will precisely follow the mouse, not
only when the mouse has moved out of the bounding area enough to
reach the next even coordinate.
|
|
Put back parens which must have been removed accidentally in a
cosmetic cleanup pass, restores --follow-mouse functionality
which was confirmed/reported as broken by @koo5 in
https://github.com/Enselic/recordmydesktop/pull/32#issuecomment-902089762
|
|
Fixes:
warning: ‘__builtin_strncpy’ output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
|
|
Fixes:
warning: conversion from ‘long unsigned int’ to ‘CARD32’ {aka ‘unsigned int’} changes value from ‘18446744073709551615’ to ‘4294967295’ [-Woverflow]
|
|
By inlining its current implementation in libjack:
https://github.com/jackaudio/jack1/blob/2e78fb6c883286287ae514ff0d262a5584ecdd35/libjack/client.c#L1429
The end-result should be that that the behavior of the app remains the
same as before.
|
|
nothing functionally different
|
|
other than a div to shift coversion, this is just formatting
cleanups
|
|
fixes bug introduced by typo in 5322492387de
bug manifested as pointer region's colors being off
|
|
switch to using rmdThread() and handle errors
previously pthread_create() errors were completely unnoticed
|
|
This doesn't try to cleanup anything on the failures, basically
assuming they're always fatal and the process will exit.
Previously no pthread_create() errors were noticed at all, which
could result in some very strange failure modes.
|
|
specsfile write failures were completely undetected outside of fopen
errors
|
|
no functional changes
|
|
also stop unnecessary NULL initialization
|
|
Alignment is done separately to the inserted rect in uv_align()
now, the dirty rect structure no longer concerns itself with such
things.
After this commit `make check` passes again... not that there's
much coverage to speak of.
|
|
rmdEncodeAudioBuffers() and rmdSyncEncodeAudioBuffer() each
implemented the actual jack vs. non-jack encoding of the buffer
redundantly despite being identical.
This commit moves that step into a shared private function.
|
|
finishing up mechanical change started in previous commit
|
|
mechanical change to get filenames more accurate, thread function
will be renamed in subsequent commit.
|
|
finishing up mechanical change started in previous commit
|
|
mechanical change to get filenames more accurate, thread function
will be renamed in subsequent commit.
|
|
s/for(/for (/g
|
|
Mostly trailing space/tab removals, no functional changes.
|
|
Since avd is unconditionally copied just a few lines down,
this copy is pointless and harms readability.
I think when it was originally written there was going to be an
else branch where the unconditional copy is currently, but never
bothered.
The avd shared variable should really get changed to an atomic,
removing its lock. To anyone reading: PRs welcome.
|
|
The existing code would leave the internal handle non-NULL when
the underlying close failed. In the event of a transparent close
when chapters switch failing, a subsequent explicit close is
expected, and the handles must be NULLed out for that explicit
close to not blow up because fclose() leaves the handle undefined
after errors. It's basically a use after free bug.
|
|
Various functions rely on this stuff at least being zeroed, rmd.c
already had been fixed but rmd_rescue.c has been neglected.
|
|
This would potentially exceed the clip w/h on odd inputs because
it was wrongly adding the cliprect offset while comparing against
coordinates already made relative within the cliprect
|
|
--rescue mode doesn't set pdata->capture_frameno to the total
The whole --rescue initialization path is a snowflake and should
get reworked to share more in common with the normal startup.
reported by @xloem, thanks!
|
|
Spurious artifacts in the chroma channels when the damage
regions weren't aligned showed up because this function
wasn't actually doing anything.
|
|
This only applies to ALSA, but the av-sync precision is entirely
dependent on the granularity of what ALSA refers to as "periods".
The pdata->avd delay is decremented by the audio capture in
period aligned steps, meaning the smallest decrement it can
possibly do is the period size. Between these period sized
intervals, rmdGetFrames kind of flies blind if the FPS is high
enough for frametime to be substantially smaller than the period
time.
A smaller period does increase the ALSA capture overhead,
basically increasing the number of times ALSA returns data to
userspace, kind of like a higher interrupt rate. But it seems
negligible for a modern system.
|
|
mechanical file rename to plural form
|
|
Mechanical rename to more accurate plural form
|
|
Not sure why the inherited code prohibited this, but it doesn't
jive with my expectations to ignore SIGINT just because the
recording is paused.
|
|
This removes the timer thread entirely in favor of a coordinated
delay loop directly within rmdGetFrame.
When there's an audio stream to synchronize with, avd is
maintained by the pcm buffer updates, and the fps-derived
frametimes synchronize with the audio that way.
When there's no audio stream (--no-sound), avd is now maintained
synthetically via clock_gettime(CLOCK_MONOTONIC) coordinating
with the clock instead.
There's been some reworking of frame sampling/reusing and cloning
logic, which may need some refinement. But for now the tests
seem to show promise.
The old timer approach just increased the non-determinism by
adding more scheduler latency and influence unnecessarily.
|
|
|
|
Make the names reflect their units of microseconds
|
|
This changes the syncer thread to always be created for writers,
and makes it posix_fallocate() the cache file to the maximum
size.
When the syncer is disabled w/ms=0, it simply returns after the
posix_fallocate.
posix_fallocate errors are ignored, this is simply an
opportunistic optimization. I have some concern about the glibc
emulation mentioned in the man page, but writers are opened
O_WRONLY which the notes say cause the emulation to fail with
EBADF which is preferable, and I'm using O_WRONLY for the
writers.
|
|
In preparation for posix_fallocate() pre-allocation of cache
files, expect zeroes for the header when running off the end of
valid data into the only allocated space, and handle gracefully
as an EOF equivalent.
|
|
This adds a new flag:
--periodic-datasync-ms
with a default of 100ms.
When a new CacheFile is created for writing, and the datasync
period is non-zero, a thread is created for the sole purpose of
calling fdatasync() on the underlying fd in a loop separated by
sleeps of the specified duration.
The purpose of this is to prevent a large backlog of dirty
buffers from accumulating until the operating system's normal
background dirty sync kicks in. Depending on how the underlying
filesystem and storage stack is configured, these bulk writebacks
can result in very long stalls on a subsequent write operation.
This is easily observed on ext4+lvm+dmcrypt setups, even using a
simple test like `dd if=/dev/urandom of=testfile bs=8M`. Despite
having plenty of available buffers, once ext4's internal journal
fills while a bulk writeback is underway, dd's progress will
completely stall until the entire writeback is completed, usually
it's in the jbd2 wchan of do_get_write_access().
When this occurs during a recording by recordMyDesktop, the
result is dropping frames for the entire duration of the stall.
One thing recordMyDesktop could do to insulate from this is
perform its own buffering of sampled frames at the YUV stage,
with the cache writer consuming from this pool of buffered
frames. Then when the cache writer gets stalled on jbd2/dmcrypt
holdups, the buffer pool just grows instead of frames being
dropped. I may explore this option in the future, but for now
simply syncing regularly has been sufficient in my usage, as it
keeps the storage subsystem more continuously utilized and
spreads out the writebacks so they don't completely back up the
journal.
|
|
hopefully this is is all of it, will need more testing
I noticed during some non-full-shots tests that the dirty areas
didn't seem to be getting rounded up properly so my single pixel
window border's color was sometimes omitted on the right edge and
bottom...
|
|
|
|
This minimally switches all the ad-hoc image cache files handling
over to using CacheFile.
I left the audio cache alone for now as it seems to not be
compressed. It might make sense in the future to switch that
over as well, especially if I start adding features to CacheFile
like preallocating and async periodic fdatasync.
|
|
Throughout the existing cache-related code there's constant checking
if compression is active or not.
This commit introduces a CacheFile ADT with the intention of
replacing all the open coded stuff with simple calls into
rmdCacheFile* functions operating on CacheFile instances.
The management of split up cache files has also been implemented
behind this API, so the reads and writes will transparently
handle the split files. These have been named "chapters" in new
code.
No callers have been changed, this only adds the new facility. A
subsequent commit will migrate things over.
|
|
No need for fflush(stderr) when it's already unbuffered by default.
According to setvbuf(3):
Normally all files are block buffered. If a stream refers
to a terminal (as stdout normally does), it is line
buffered. The standard error stream stderr is always
unbuffered by default.
|
|
Making things a bit more consistent
|
|
Despite this listing already being named rmd_cache_audio, it used
sound instead of audio for the api.
|
