get_frame: refresh capture_frameno post acquire

Acquiring the new frame can take a potentially significant amount of
time, rather than letting any frames dropped during the acquire get
all taken by the next frame, update this one to include them.

It's both more accurate (the dropped frames occurred literally while
this was going on) and makes it more likely get_frame() will have
to wait on the upcoming cond_wait(time_cond) for the next tick.

If the upcoming cond_wait(time_cond) doesn't wait because a new
frame is already pending, it makes it more likely get_frame() will
snatch yuv_mutex before the encode/cache thread can wake up and
grab it.  When that occurs it's effectively dropping frames because
the encode/cache thread gets blocked on yuv_mutex while the contents
get replaced, so the frames the previous contents were going to be
applied to will instead get the updated contents that belong to
the future sample's frames.

0 files changed, 0 insertions, 0 deletions