| Age | Commit message (Collapse) | Author |
|---|
|
This is focused on keeping --on-the-fly-encoding in sync even
over long videos. The existing code inevitably would fall into a
permanently negative pdata->avd value letting things get
increasingly out of sync and never correcting.
Before removing the vestigial negative avd "don't wait" logic
from get_frame when this permanently negative avd state was
entered, get_frame would just start sampling at an unregulated
fps.
The timer thread which drives get_frame now consults avd on every
tick, Depending on which which half is ahead, the timer will
either cause get_frame to drop frames by advancing the frameno by
more than one, or it will adjust its sleep delay in proportion to
the delta.
See comments in rmd_timer.c for more details.
Note that in testing especially with a loaded system I observed
some surprisingly large deltas where multi-second sleeps occurred
to let the sound catch back up. I expect to revisit this issue
more in the future, but would just like to get things more
correct for now.
|
|
When the encoder finds the encoded - captured frameno delta > 1
it needs to fill the gap somehow.
With how things are currently architected, the old yuv countents
are gone so there's only the current frame available for filling.
The newer theoraenc.h API exposes a theora_control() parameter
for this purpose, so I've also added a theoraenc.h include
implicitly bumping the libtheora dependency. But by now it
shouldn't matter, and the rest of rmd should probably get updated
to use the new theora API eventually anyways.
I'm still uncertain what role pdata->avd will play in the
long-run, but leaving its maintenance for now.
|
|
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.
|
|
Vestigial broadcast, only a single waiter on this now.
|
|
Maybe this made sense at some point in the original code, but the
way I have this setup currently get_frame() should strictly
capture a frame on every tick of the timer at the desired FPS to
the best of its ability.
The capture_frameno gets propagated to the encoder whenever a new
frame is acquired on that timer. When the encoder consumes it,
it should just dupe the frame to fill any gaps between the last
encoded frameno and the new one.
As-is, this avd value seems to drift permanently negative
eventually at which point get_frame() ceases ever waiting on the
timer. That's obviously broken, and devolves into a pinned CPU
with get_frame() attempting an infinitely high frame rate. Which
likely just makes things worse not better by starving the encoder
of CPU time.
I need to go check out the encoder now to make sure it fills
frameno gaps.
|
|
Name the timer and sound capture threads as well, and fixup the
rmd{Encode,Cache}Sounds names -> rmd{Encode,Cache}Sound
|
|
Nothing changed, just syntactic sugar to make this
more readable
|
|
Quick minor release primarily for the paused CPU burning fix
|
|
usleep() is deprecated by posix in favor of nanosleep(), nanosleep
doesn't dick with signals so it's generally better anyways.
|
|
rmdGetFrame() can't just block on pause_cond because it services the
event loop, which may be the very thing responsible for unpausing
when not triggered by an external signal.
The existing code handles this correctly but it spins on polling
the paused flag and running the event loop when paused.
This commit just adds a short delay to that cycle so the rmdGetFrame
thread doesn't pointlessly burn CPU while paused.
|
|
Now users can easily differentiate which rmd subtasks are
busy by using top-like tools in show-threads mode.
Also aids in troubleshooting...
|
|
Formally making first release since forking, I'm sure there are bugs
but I doubt anyone will be inclined to help test any of this if there's
nothing at least stating it's a newer version and some mention of the
user-visible changes.
|
|
Just some quick modifications to reflect the forked status
|
|
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.
|
|
This isn't tested as I don't currently have a JACK setup, but it
at least compiles and looks semi sane.
|
|
Nothing functionally changed
|
|
Nothing functionally changed
|
|
Nothing significant changed
|
|
This may just be ffmpeg ogg decoding bugs, but it requires
investigation to confirm. The playback does show corruption
in mpv/vlc in my testing, but that problem existed pre-fork
as well.
|
|
Nothing significant changed
|
|
With no rrect alignment adjustment happening, there's no need for this
fuckery anymore. The theora encoding offsets will always be left at
0, the frame_{width, height} will clip to rrect.{width,height}, and
the yuv buffer dimensions are the only thing 16x16 aligned.
|
|
rrect of any size/place should be perfectly usable now
|
|
|
|
|
|
Minor cleanup
|
|
Nothing functionally changed
|
|
nothing functionally changed
|
|
nothing functional changed
|
|
Nothing functionally changed
|
|
Assume rects that come in for insertion are already as aligned as
possible within the rrect bounds. If the rrect has odd dimensions,
then there's potential for edge case odd rects too - but the only
even-sensitive code is the YUV updating and that's been amended to
at least ignore those edge cases gracefully.
Also constify the supplied xrect while in here.
|
|
The current rectinsert code does this, but it does it in the absolute root
window coordinate space.
In preparation for dropping all the alignment stuff out of rectinsert, do
the alignment at the rectinsert caller and do it in the rrect-relative
coordinate space.
|
|
Eliminate some pointless duplication
|
|
Just some sanity checks to ensure clipping is working properly
|
|
More tidying of things
|
|
No need to duplicate this down at the teardown, it won't go away
with outstanding references so you can basically queue the rm.
|
|
Baby step towards encapsulating the shmem and ximage state
|
|
More preparation for yuv and rrect dimensions differing
|
|
Nothing significant
|
|
minor formatting/whitespace changes
|
|
No idea why this had such a large type, its members just hold 0 or 1.
|
|
This is temporary, in preparation for potentially odd-dimensioned
image buffers.
For now I'll just skip the last row / column in the UV update for such
odd dimensions.
In the future there could be a read-modify-write dance for handling the
last row/column or something like that.
|
|
This needs to maintain dirty blocks in the yuv frame coordinates,
not in the captured image's cooridinates.
The existing code assumes those are the same in double-buffer mode
where the dirty block tracking is applied. But I'm working towards
allowing the captured image dimensions to be free from the 16x16
alignment constraints the yuv buffers must conform to for theora.
To handle that future, the block coordinates should at least use
the (yuv)->y_width, not width_tm. I also added shifting the x,y
but in double-buffer mode that shouldn't actually be needed since
it'd always be full-shots unless I'm mistaken.
|
|
Nothing really changed here, just rearranging some stuff and
replacing some divides with shifts.
|
|
No idea why rmdGetZPixmapSHM() is doing this, the whole point of
shmem is to not have to read the data over the wire. You request
the server to do the copy into the shared memory and that's all
there is to it.
This program is so confused
|
|
Remove more pointless code
|
|
XCreateImage() returns a fully initialized ready-to-use XImage,
I have no idea why the author did this.
|
|
nothing functionally changed
|
|
nothing functionally changed
|
|
nothing functionally different
|
|
|
