Right now the captions are only rendered if there's a video present. If
the meeting doesn't have a video (webcam or desktop sharing), we'll need
to just make up a blank one.
This shouldn't normally be hit... but if it ever is, the processing will
fail with an error, since the Logger class doesn't have a method named
'warning'.
We now use ghostscript to output pngs directly from the original pdf,
rather than using convert on the split pages. This should make corrupt
or strange pdfs less likely to cause issues.
As well, if a pdf page conversion fails (for any reason, including that
the original pdf is missing...) it will be logged, and a blank page
generated, and processing will continue.
I've been working on this for a while, and it's adapted from code that
has been fairly well-tested on a wide variety of recordings. I've found
it to do a more accurate job of combining multiple webcam files, and it
should be more accurate in the audio as well.
Another key feature is that it does fewer re-encoding steps during video
processing, which should both speed it up and hopefully improve quality.
The settings on the VP8 encoder have been tuned somewhat as well.
also, the output video resolution is modified to the highest screen resolution shared during the conference, independently on the output video resolution set by the user; it was done to preserve the quality of the desktop sharing image; if there's no desktop sharing, the output video resolution is respected
Refactored the code that generates the video file used in the presentation playback. The problem with the sync of video sources was related to problems of precision inside FFmpeg (sometimes the script runs FFmpeg to trim video files, and the output video file trimmed sometimes was 3+ seconds bigger or smaller than the requested).
Also it's a little more modular, so it will be easier to expand functionality. The processing steps are more explicit now, and the logs are better now to understand the final output.
A new parameter on presentation.yml was added to enable the admin to add an offset for the audio stream - this is mainly useful when the session ran with h264, because the video takes longer for the client to encode, and then in the recording we can see the huge gap between audio and video.
This was broken by my earlier change to fallback the pdf filename for
really old recordings.
Rearrange the code so that the pdf logic is only used in the case when
the presentation is a pdf.
In some old recordings (0.80?) I've seen the default presentation pdf
located at the filename .../default.pdf/default.pdf. Support this old
location with fallback logic so the new scripts will work to reprocess
old recordings.
I've improved the error handling logic here a bit as well.
