Issue #6338

It looks like there was a logic error in the code that was causing it
to break out of the event deletion loop early when deleting events for
the last (or only) segment in a recording. (In this case, last_index
is -1, so i >= last_index is always true).

The trim_events_for call was always succeeding, so the events were
being removed from the event list (meeting:{ID}:recordings key) even
though the events themselves hadn't been deleted in the loop.

I've moved the trim_events_for call to below the event deletion loop
to ensure that if the archive script is interrupted, the events list
will contain all not-yet-deleted events.

The checks for 0 numerator or denominator were failing due to
type mismatch

The archive_dir can by the raw recording directory in some recording
formats - including, hopefully, presentation at some point (to avoid the
extra copy)

The previous calculation used the video size in pixels, which might lead
to stretched/squashed videos in rare cases where the video has non-square
pixels. The new calculation is correct for all video sizes.

The video_info function returns the start time already in milliseconds,
so compare against 1ms instead of 1/1000.

The ffprobe command in ffmpeg 4.0 now omits the aspect ratio fields in the
json output when indeterminate, instead of returning an invalid value with
0 in the numerator or denominator. Handle this correctly.

Since the update to the newer red5, seeking in flv files (webcams in
particular are noticable) has been broken, resulting in cameras
appearing to "hang" any time there is a cut in the generated video -
which happens when start/stop button is pushed, or when cameras are
added or removed.

We can detect the problematic video files because the timestamp of the
first frame is large (old red5 versions always set first frame
timestamp to 0.001 seconds). If we see a file like this, having ffmpeg
remux the file - rewriting the timestamps and index - works around the
problem.

Due to improvements in the recording scripts, most of the stuff the sanity
script was checking for is no longer needed (missing/corrupt video files
are handled by the processing scripts). The version of this script in
master has been cleaned up so that the only things it does are:

- Check that the events.xml exists and is properly formatted xml
- Rebuild flv files from red5 .flv.ser/.flv.info files

The script from master is compatible with the 2.0 code, so just use it
as-is.

This fixes a problem where following the recent red5 upgrade in 2.0 branch,
an flv file is never written for webcam streams where no frames were
received, despite there being recording events.

This improves the quality of portrait documents, before they were
1200px when landscape documents got 1600px.

Switching to scaling to a square means that we can use the "-scale-to"
option on pdftocaio, which means that it generates images directly
at the desired size. This can save quite a bit of time (and memory)
if a document was uploaded with extremely large page size.

There's some cases where you can get 0-duration recordings due to
recording event placement (e.g. a single recording event is the last
event in the events.xml). Detect these cases, and treat them like
no recording marks in the archive script (it will stop the recording
from being automatically processed).

I've also adjusted the sanity script to detect these cases and error
out. The recording processing scripts cannot handle 0-length recordings,
you have to manually edit the events. I've added a message to the
sanity log about this.

In some cases (due to network issues), the webcam video can be shorter
than the time between the start/stop events. Pad the input video with a
blank video to make sure that there's input to the video tiling filters,
to fix a problem where the video won't render correctly with ffmpeg v3.4
and later.

In some cases (due to network issues), the webcam video can be shorter
than the time between the start/stop events. Pad the input video with a
blank video to make sure that there's input to the video tiling filters,
to fix a problem where the video won't render correctly with ffmpeg v3.4
and later.

In some cases when there is a slight mismatch between audio file
duration and event timestamp difference, and we have a record
status or chapter break event in a certain location, it could
trigger a seek past the end of an audio file. Detect this
condition and just render silence instead.

Also adjust the thresholds for the audio length scaling - they
were being triggered on short recordings that should be correct.

In some cases when there is a slight mismatch between audio file
duration and event timestamp difference, and we have a record
status or chapter break event in a certain location, it could
trigger a seek past the end of an audio file. Detect this
condition and just render silence instead.

Also adjust the thresholds for the audio length scaling - they
were being triggered on short recordings that should be correct.

With the current segment processing, we might be processing one segment
while archiving a different segment from the same recording. To avoid
that the processing scripts see an incomplete events.xml file, write to
a temp file then rename.

Red5 sometimes writes webcam video files with a large offset in the
video frame offsets, sometimes up to 30 or even 60 seconds. However,
the start event in the events.xml file corresponds to the time at
which red5 received the first keyframe (recorded frame) in the video.

The end result is that the video will sometimes appear to be
delayed (out of sync) in the processed recording.

The correction is simple: We're already reading video metadata,
including the timestamp of the first frame, so we just have to apply
a correction during video processing to undo the frame timestamp
offsets in the video file.

Red5 sometimes writes webcam video files with a large offset in the
video frame offsets, sometimes up to 30 or even 60 seconds. However,
the start event in the events.xml file corresponds to the time at
which red5 received the first keyframe (recorded frame) in the video.

The end result is that the video will sometimes appear to be
delayed (out of sync) in the processed recording.

The correction is simple: We're already reading video metadata,
including the timestamp of the first frame, so we just have to apply
a correction during video processing to undo the frame timestamp
offsets in the video file.

When working with the segmented recording format, the events file might
end with a mismatched start video event for an incomplete file. The
sanity script was removing this event, meaning the video didn't show up
in future segments.

Simply drop the code that tries to find invalid video files and removes
them from the events file. The new video processing code is already
robust against missing or corrupt files.

The timestamps no longer line up after applying one edit, so these
have to be all done at the same time in one step.