| Age | Commit message (Collapse) | Author |
|---|
|
The existing code was assuming every frame would get cached
before the next frame was collected. But that's not strictly
enforced in the current architecture. Sure, the condition
variable is signaled for every frame, but that doesn't guarantee
the cache_frame side will wake up and actually do its thing
before get_frames moves on to the next frame. There's no waiting
for cache_frame to ack the signal before grabbing the next frame.
So in damage-tracking mode (the default when available), there
was a very real potential for lost damage, especially with higher
fps rates.
This commit moves the resetting of the YUV dirty blocks to the
cache_frame side, only after the accumulated dirty blocks have
been processed, immediately prior to releasing yuv_mutex.
As a side effect, the previously get_frames-private
rmdBlocksReset() has moved to rmd_yuv_utils.c and renamed to
rmdYuvBlocksReset(). Some comments have been thrown in flagging
the need to refactor the YUV blocks creation/maintenance - it's
all very ad-hoc as-inherited, I haven't cleaned that up, and it
needs it badly.
Hopefully this fixes some of the lost damage I've been noticing
doing 60-fps captures of programming.
|
|
this seems obviously wrong
|
|
When you depend on the shortcuts as _the_ means of
stopping/pausing a recording, like in a WM integration scenario,
it's preferable to have rmd exit fatally when the grabs can't be
setup. (usually this occurs when you've accidentally tried
starting multiple recordings, and the shortcuts collide)
This way, the integration can detect the failure and throw up a
dialog or something informing the user that the recording wasn't
started. All that's needed is including --need-shortcuts.
Note this is a little janky in how it's implemented, because
XSetErrorHandler() is janky and doesn't even support a user
pointer payload.
Rather than introducing global variables to either communicate
the grab failures to other parts of rmd, or exposing the parsed
args struct to the error handler globally in the other direction,
I just made a grab-errors-are-fatal variant of the handler which
gets installed when --need-shortcuts is specified.
|
|
After making a lengthy recording I noticed this overflow:
Cached 17592186042575 MB, from 80475 MB that were received.
Average cache compression ratio: -21860206917.2 %
This commit fixes the nbytes accumulating minimally by just
narrowing its cycle to one iteration, which seems like what was
probably intended by whoever wrote this once upon a time.
|
|
This is necessary for keeping A-V in sync, and when not done at
all is simply broken.
|
|
The other side needs to be waked up should it be blocked in the
cond var, and we're not going to send anything. Otherwise it
won't notice !running and exit its side.
This should take care of the --use-jack hangs on shutdown
|
|
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.
|
|
* --follow-mouse fixes
* --windowid fix to wait for unmapped/invisible window instead
of immediately exiting. Particularly relevant for programmatic
invocations on newly created windows.
* YUV color plane shift corruption fixup for odd width capture
windows.
|
|
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
|
|
this is a temporary kludge since automake is angry
|
|
other than a div to shift coversion, this is just formatting
cleanups
|
|
For now just going to rely on the git history and will try
describe a digest of noteworthy changes in the tag commit for new
versions, time permitting.
You can always just consult the git history.
This ChangeLog format inherited from the previous authors is an
abomination, good riddance!
|
|
- Fixed XFixes pointer YUV updates of V channel, manifested
as incorrect hue of pointer region in recordings
- Fixed rmdCacheFile crash when chapter rotate failed, usually
triggered by filling the filesystem during a recording
- Improved error checking
- Many code cleanups
- Bumped to 0.5.0 as a latent realization of the new flag
--periodic-datasync-ms introduced back in 0.4.3
|
|
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.
|
|
|
|
--rescue uninitialized structs fix
uv_align bounds check fix affecting odd-sized windows
|
|
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
|
