Now it's done in the application and positioning is not hard-coded
inside acorn player, so it works in a responsive page.
Still not 100%, the playback jumps back and pauses on swap. Have to
make the transition seamless.
This allows configuring a server to use https without having to edit
any ruby files directly.
(Ideally, the metadata files wouldn't include the server name/protocol
at all; that should be set dynamically by bbb-web, but this is what we
have for now.)
This fixes loading the shapes svg, and the events and cursor xml files
on servers configured with https support. (Otherwise they'll be loaded
off http:// and trigger mixed-content errors).
FreeSWITCH writes wav files >4GB long with incorrect values in the length
field in the header. Recalculate the length based on file size, and ensure
that ffmpeg reads the complete audio file rather than stopping.
There were a couple of problems:
* A division by 0 when calculating the percentages
* Positioning of the number of results counter was incorrect
Fixes#2739
Note that this requires a new dependency be added to the
"bbb-playback-presentation" format; the "gnuplot" package is now
required (it's used to actually generate the chart images)
In 0.9.0, the slide clear events changed from using 1-based page numbers to
using 0-based page numbers.
Add 1 to the page number for recordings generated on a 0.9.0+ server to
fix the issue; at this point it's too late in the release to change the value,
and there's too big of a body of existing recordings out there.
If the video EDL merge function is applied to an EDL that has already
been edited to apply recording marks, the merge function will change the
video start times to incorrect values on edit points during the timestamp
recalculation.
The fix is pretty simple; just pull in the timestamps from the entry that's
being merged in and apply them to the relevant videos.
This bug doesn't currently cause any issues in the BigBlueButton recording
scripts, since the existing code does the merge before the start/stop marks
are applied. But to avoid surprises later, it would be good to fix this.
It had some leftover debug code that caused it to only convert the
first 10 recordings instead of all of them.
The name of the '.done' file is changed so the update will be re-run
automatically.
This allows them to be preserved for a period of time, rather than be
deleted immediately. Useful for recovering recordings when someone forgot
to press the record button during the session.
The slides processing scripts have never been updated for 0.9.0 events,
and probably never will be. They're still using older video/audio
processing apis that have poor sync, too. Just remove them.
The playback support files will still be installed, to allow recordings
from old BigBlueButton servers to be copied to a 0.9.0 server.
This adds the version number to the playback links so that
recordings select the correct version-specific playback support
files.
This script may be run automatically during upgrade; in that
case it should be run like
.../bbb-0.9-beta-recording-update --quiet
After copying recordings from an old BigBlueButton server, you
may want to manually re-run the script, and it takes the option
--force to recheck all recordings even if it has previously been
run.
Right now there is a possibility that the rap-worker process might
see the recording.done file (written by bbb-web) prior to Red5 having
completed writing the video files to disk.
This happens most often when a meeting end api request is sent while a
webcam is visible.
Add a delay (currently 2 minutes) before the archive scripts are run
to work around the issue. Real fix is far more complicated...
The logic for deleting the process done files was wrong, resulting in
the script (attempting and failing) deleting all of the done files for
all of the processed recordings after the publish completes for one of
them.
Fix the logic to only delete the process done file for the recording that
just completed publishing.
Now the 0.81 presentation playback files are in an appropriate versioned
directory. If desired, the recording metadata can be updated to reference
the versioned files directly, but an nginx redirect has been added so
that unmodified recordings will also work.
This makes it a bit more obvious how the versioning can work going
forwards, and makes it so that we do not need to update the nginx
config each time we have a new version of the playback files.
The 0.81 files remain at the top level of the presentation directory
for compatibility reasons.
This fixes an issue where recordings copied from a 0.81 server might
not play back correctly on a 0.9 server.
This changes the 0.9 recording scripts to use playback support files
from a different subdirectory, 'presentation2', while existing 0.81
recordings continue to use the 'presentation' directory.
If the raw files from an old recording are reprocessed, it will
switch to using the newer playback support files.
This was added because BigBlueButton 0.9 started using 1-based page
numbers in the events.xml file. That change has been reverted, so as
to avoid behaviour changes from 0.81 in places where it's unnecessary.
With the switch to a different clock source in red5, the timestamps
in the events file are no longer real-time, but are rather in
seconds since computer boot.
The timestamp in the meeting id is still realtime, so use that as
the start time. Calculate the end time by adding the meeting length
to the start time.
Makes it handle possibly corrupted video files with less chance of
breakage. Use features from newer ffmpeg release to simplify the video
trimming - in particular, using -ss as an input option is accurate now.
This is the point at which the start/stop events for the audio are
correctly matched up with eachother; doing it later can give
incorrect results if an 'end recording' event was missing from
the events file.
The previous version may have the beginning of the audio off by a bit,
since it was seeking in the audio file to find the start before the
stretch was applied.
There's some fairly major changes here, including:
* All audio is resampled to 48kHz stereo on input, allowing files with
non-standard or varying rates to be mixed
* The audio processing is now done in a single pass; ffmpeg reads all
inputs, concatenates them, and outputs one file.
The 'mkclean' tool reorganizes the encoded webm file to optimize it for
streaming. In particular, it moves the index to the start of the file.
This fixes streaming in Chrome, which otherwise had a very long delay
before playback started since it downloaded until it saw the index
before it started playback.
This needs a new dependency added to the bbb-record-core package to
pull in the mkclean tool.
I had it on DEBUG temporarily for testing. The old version used ERROR,
but this made it print virtually no output which made diagnosing
issues difficult.
It now does much less directory reading, and performance should
scale far better with large numbers of recordings.
Semantics should be mostly unchanged, but there's greater use
of '.fail' files to mark errors, and '.done' files are now removed
after all of the following processing steps complete.
The rap worker no longer relies on processing scripts leaving
behind empty directories; those are now removed where appropriate.
There are many codes other than '404' which indicate that the media
file is not present or otherwise unusable. Instead of checking for
a particular failure mode, check for explicit success.
I ran into this on a server that had directory listing disabled, and
returned a 403 (access denied) error on non-existant files.
We can only get here if all of the files for the presentation are
*completely* missing. One thing that can cause this is if the
presentation filename starts with a '.' character - the presentation
files aren't correctly archived then.
Firefox has a bug where it can't seek in the audio-only webm files with
no cues, and it seems like they have no intention of fixing this...
Serve up the ogg files first for them.
Adding cues to audio-only webm files is *hard*, there are no standard
tools that support doing this cleanly.
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.
