In BBB 2.0, the cursor positions are given relative to the page
size (like annotation positions). Since the recording cursors
aren't actually drawn in the page like annotations, it's more
convenient to have them relative to the visible area (viewbox),
so do that conversion.
While I'm in here - since we switched to new incompatible scripts
for BBB 2.0 anyways - remove an extra factor in the cursor positions
in cursor.xml, and just use a simple ratio of width/height instead.
The new shapes code, required for handling smooth shape updates & multi-user
whiteboard in the 2.0 BigBlueButton, hits a bug in old recordings where
the pencil tool incorrectly used "line" in its shape names, meaning that
there could be both a pencil mark and a line with the same shape name.
The old recording code didn't rely on the shape name to match shapes, since
there was no chance of concurrent shapes. As this is an incompatible playback
change, we need to make a new playback directory for the updated files.
The previous code would cause shapes to "blink" during updating if
the updates weren't continuous - in a gap between updates, the shape
would disappear.
Rework the logic for looking up "current" shapes to return the
nearest previous update rather than only exact matching timestamps,
and simplify the logic that decides whether to make a shape visible
or hidden.
We were getting the duration with a Popcorn temporary instance. This was causing a slowly increase on the cpu usage, which could compromise the performance of long recordings.
- Created function "seySync( )" which sets the sync logic. Basically, we sync all medias when pausing the master video. We pause the master video when any video receives a waiting event, or when the master video is seeked. If necessary, we resume playing after the sync.
- Refactored when 'media-ready' event is fired. We fire this event only when the medias receive a 'canplayall' event.
- Popcorn "onFrame" method runs around 6 times per second. That was unnecessary , causing the CPU work to significantly increase, and preventing the two videos (deskshare and webcam) to run together smoothly
- We only synchronize the medias if one of them fires a "waiting" event. If the user pauses the playback, we synchronize them as well.
The playback had no handling for this type of event. The aspect ratio used to calculate the max-width of the slide div has to be the vbox aspect ratio.
The code was previously passing the message string provided by the user
directly to jQuery - which works okish if the first character is '<' since
it'll parse it as HTML, but the chat messages don't. As a result, it was
sometimes being parsed as a selector, failing, and raising an exception.
The fix is to put the chat message into a DOM node (have the browser parse
the HTML) before doing the jQuery operation to modify the link targets.
Fixes#3670
Chrome frame has been discontinued for quite a while. The playback code actually
does work in IE if you install an extra codec pack or switch the video format used.
Due to the extra delays added by setting up the closed captions, it happens more
often that the writing.js code will attempt to initialize popcorn on the video
element before the video element actually exists on the page.
(This was always a problem, it's just worse now)
Add a synchronization point which will delay the popcorn initialization until the
video element is ready.