When converting from using the 'movie' source filter to using separate
ffmpeg command line inputs, it wasn't taken into account that the
'movie' filter passes through timestamps from the source file, while the
ffmpeg input adjusts timestamps so that '0' is the selected seek point.
The easiest fix is to add an option to the ffmpeg command to disable the
timestamp adjustments.
Fixes#15644 (This needs to go into BigBlueButton 2.5 and 2.6)
- Update the version to 2.6.0 to ease the detection of old/new whiteboard events
- Fix recording cursor when there is no pan/zoom and annotations in tldraw
- Don't generate slides pngs for 2.6.0, they are not used anymore in playback (svgs instead).
Changed the names of tldraw record events to differentiate from before.
Publish tldraw.json file with all shape information during the meeting to be used in playback.
Adapted cursor.xml and panzoom.xml to store tldraw data.
Publish slides svgs to be used by playback's tldraw component (otherwise we have different image sizes in pngs and thus messing the coordinates).
Retro-compatible with old recordings.
Based on work done by Tiago Jacobs and Guilherme Pereira Leme to
investigate the behaviour of ffmpeg on videos with changing input size.
Rather than having the EDL code set fixed sizes for the scale and pad
filters, instead use ffmpeg's built in features to calculate the scale
and pad automatically, dynamically updating if the input video size
changes.
In the version of ffmpeg in Ubuntu 20.04, the 'movie' input filter is
buggy and doesn't correctly handle the video size changing. Instead of
using the movie filter, use separate inputs to the ffmpeg command (the
design used here is based on the code in audio.rb). The filter chain is
now stored into a file (using -filter_complex_script) to reduce problems
with the command line getting too long.
We are using a version of ffmpeg that's new enough to have the tpad
filter now too, so use it to extend the video if needed instead of an
extra concat.
In BBB 2.5, we switched the recording system to use bundled gems
included privately in the recording package, rather than installed
system-wide. The rap-enqueue.rb script needs to be updated to load the
bundler gems.
According to bundler devs, setting the BUNDLE_GEMFILE environement
variable is the supported way to tell bundler where to find it
(otherwise bundler will search starting at the current working directory
- which in the case of rap-enqueue.rb is probably nowhere near the
Gemfile).
Use a relative path from the directory where the script is located so it
can be run both when installed and from a development environment.
Switch the script interpreter to use /usr/bin/env to load ruby from the
path. Doesn't make a difference in the installed package, but it makes
testing on development systems with multiple ruby environments easier.
Fixes#15085
* fix unit name: the unit name on Ubuntu is `redis-server.service`
* services which need a working redis require both After= and Wants=
See the description in the `systemd.unit` man page.
In some cases with incomplete/partially corrupt files, the input video
file can be shorter than the displayed time. If there is a badly timed
cut, this can result in a seek being generated to a point where ffmpeg
is unable to start at.
Add a detection for this situation, and replace with a blank video.
The rap scripts might load or run some scripts using relative paths from
the scripts directory, so restore that.
Bundler automatically looks up in parent dirs to find the Gemfile, so
loading gems will work correctly.
Several scripts internally run bundler setup, so no explicit bundler
command is needed. For the others, start up using /usr/bin/bundle
(installed by ruby-bundler) to load the environment.
Now uses Ubuntu's bundler version to install all dependencies at build time
rather than install time. Gems are also now vendored, and no longer pollute the
operating system.
