| 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 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 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.
|
|
Making things a bit more consistent
|
|
these concepts may return but not in this form
|
|
avd accesses aren't serialized currently despite occurring from
concurrent threads. I'm reworking avd but this just introduces
and initializes a mutex for the existing variable.
|
|
This restores the recordmydesktop/ subdir as root from the mirror I
cloned by fork from.
I have no particular interest in the gtk/qt frontends and it doesn't
appear they were part of a single tree in the past. But I will
probably preserve backwards compatibility of the cli so they can
continue to work with this fork installed.
|
