|
RecordPlaybackSpecification
Draft - The Vision/Scope for implementation of Record and Playback in BigBlueButton.
OverviewNOTE - This page is being updated to reflect what we have done so far. The first part of this document describes the long-term vision and scope for implementing record and playback into BigBlueButton. The second part outlines the work to be done for the initial record and playback release. The purpose of this document is to provide a clear understanding of the business needs, the long-term vision to address the needs, and the constraints that are being faced during this phase of this project. It also details the requirements and specifications for implementation of the first iteration. The document also attempts to foresee and mitigate any risks that for the first iteration. This document assumes the reader understands the current BigBlueButton architecture. To get an overview of the architecture see http://code.google.com/p/bigbluebutton/wiki/ArchitectureOverview. The terms "virtual meeting", "virtual classroom", and "sessions" all refer to a virtual meeting within a BigBlueButton server. VisionThe long-term vision for Record and Playback is to enable a university or college to capture, store, search, and retrieve lectures without any additional effort on the part of the teacher or students. The implementation of this vision would extend the current API to enable third-party plugins -- such as those for Moodle, Sakai, WordPress, and so on -- to give the teacher control over creating the recordings and provide students easy access to the recordings. The success of this vision would be measured in the number of educational institutions that actively use BigBlueButton to capture and distribute their lectures. PhasesRecord and playback can be broken down into the following phases (The details of the technical implementation for the first iteration are covered later in this document):
Capture PhaseThe Capture phase involves enabling the BigBlueButton modules (chat, presentation, video, voice, etc.) to emit events over an event bus for capture on the BigBlueButton server. Components that generate media (webcam, voice, desktop sharing) must also store their data streams on the server as well. Archive PhaseThe Capture Archive phase involves one or more server-based tools that subscribe to the event bus and store the emitted events (such as "advance to slide 3 at 12:34:32") together with the associated media (slides, audio, video, and other media streams) into a repository (database or file system) for later processing. You can think of a server-based tool functioning as a VCR: it sees and records all the events and media generated during a BigBlueButton session without affecting the session itself. Ingest and Process PhaseThe Ingest and Process Phase involves one or more tools that process the recorded events and media into a format for later playback. A tool may process all or a subset of the recorded events and media. For example, a tool can extract and process only the slides, slide transition events, and audio to create one of the following output formats:
The vision for this phase includes giving the moderator (or teacher or administrator) the ability to
Publish PhaseThe Public Phase provides one or more tools to manage the publication and access to the recorded sessions. For example, a Distribution Management tool could upload a video file of a recorded session to external sites like YouTube, iTunesU, and others. The vision for this phase includes the ability for an administrator to
Playback PhaseIn the Playback Phase, the user loads a client tool -- such as video player, custom Flash client, or custom HTML5 client -- to playback a recorded session. For example, the client tool could be an HTML interface the allows the user to do keyword searching through past recordings. A student could enter the keyword "ecosystem" and the tool would search through all recorded session, display thumbnails of slides that contain that specific keyword, and start playback on a specific slide when the user clicks a thumbnail. High Level ArchitectureRecord and Playback core directory/usr/local/bigbluebutton/
└── core
├── Gemfile
├── Gemfile.lock
├── lib
│ ├── recordandplayback
│ │ ├── audio_archiver.rb
│ │ ├── deskshare_archiver.rb
│ │ ├── events_archiver.rb
│ │ ├── generators
│ │ │ ├── audio_processor.rb
│ │ │ ├── audio.rb
│ │ │ ├── events.rb
│ │ │ ├── matterhorn_processor.rb
│ │ │ ├── presentation.rb
│ │ │ └── video.rb
│ │ ├── presentation_archiver.rb
│ │ └── video_archiver.rb
│ └── recordandplayback.rb
└── scripts
├── archive
│ └── archive.rb
├── bbb-rap.sh
├── bigbluebutton.yml
├── cleanup.rb
├── process
│ ├── README
│ └── slides.rb
├── publish
│ ├── README
│ └── slides.rb
├── rap-worker.rb
└── slides.ymlCapture
Raw Recording Directory The directories below are where the different subsystems will write the recordings:
BBB Web API
BBB - Apps
Deskshare
Raw ArchivingDuring archiving, scripts will copy the raw recordings into the following directories:
Archive Scripts In /usr/local/bigbluebutton/scripts/archive, there will be a master (master.rb) script. This master script will be invoked when the meeting ends. The master script will look into the archive/steps sub-directory and run all the scripts inside it. The archive/steps sub-dir will contain the following scripts archive-events.rb, archive-audio.rb, archive-video.rb, archive-presentation.rb, archive-deskshare.rb The archive-events.rb will extract from redis the meeting info and the recorded events. These will be written into /var/bigbluebutton/archive/<meeting-id>/events.xml The archive-.rb scripts will copy all raw recordings into /var/bigbluebutton/archive/<meeting-id>/ archive.done The archive.done file is a status file where the scripts can store the archive status steps. This way, if something goes wrong on the first pass of archiving, another process (a cron job) can take a look at the archive.done file and attempt to continue archiving. After several attempts, if there are still problems, the administrator needs to be notified. Sample archive.done with convention attempts status events.xml <recording>
<meeting>
<title>Business Ecosystem</title>
<subject>TTMG 5001</subject>
<description>How to manage your product's ecosystem</description>
<creator>Richard Alam</creator>
<contributor>Tony B.</contributor>
<language>En-US</language>
<identifier>TTMG5001-Week2-20110121</identifier>
</meeting>
<event timestamp="1296681157242" module="PARTICIPANT"
name="ParticipantJoinEvent">
<status>{raiseHand=false, hasStream=false, presenter=false}</status>
<userId>1</userId>
<role>MODERATOR</role>
</event>
…
</recording>Ingest and Processing to EngageIn this phase, scripts are provided to take the raw recordings from the archive and process them into a format required for playback In this release of BigBlueButton, we will provide 2 playback formats: simple playback and matterhorn The output of the process phase should be stored in
There should be a process.done file to keep the status of each process step. Properties# Default maximum number of users a meeting can have. # Doesn't get enforced yet but is the default value when the create # API doesn't pass a value. defaultMaxUsers=20 # Default duration of the meeting in minutes. # Current default is 0 (meeting doesn't end). defaultMeetingDuration=0 # Remove the meeting from memory when the end API is called. # This allows 3rd-party apps to recycle the meeting right-away # instead of waiting for the meeting to expire (see below). removeMeetingWhenEnded=false # The number of minutes before the system removes the meeting from memory. defaultMeetingExpireDuration=1 # The number of minutes the system waits when a meeting is created and when # a user joins. If after this period, a user hasn't joined, the meeting is # removed from memory. defaultMeetingCreateJoinDuration=5 RequirementsThese sections capture the more specific requirements for the first iteration of Record and Playback (BigBlueButton 0.8). System RequirementsThe system requirements are
Support RequirementsThe support requriements are
Testing RequirementsThe support requirements are
Limitations and AssumptionsThe limitations and assumptions are as follows: Capture
| |
|
|