The primary constituents of the system are,
- User-facing (video covered, login and LMS integration is not)
- Processing (not covered in detail)
- Storage (not covered at all)
We have discussed, and decided, to use a web-interface first. One of the core features of the product is video capture.
The most appealing technology for online video capture is WebRTC.
WebRTC is supported by Google, Opera, Mozilla, and Ericsson.
WebRTC is designed for high-performance, high quality communication of video, audio and arbitrary data. In other words, for applications that allow video, audio and text. Although primarily intended for chat services that have a peer-to-peer structure a peer could theoretically be a server.
WebRTC apps need a service via which they can exchange network and media metadata, a process known as signaling. However, once signaling has taken place, video/audio/data is streamed directly between clients, avoiding the performance cost of streaming via an intermediary server. Notice the lack of emphasis on the server.
Is supported on most mainstay browsers such as Chrome, Firefox, and native Android browsers.
Is open-source!
WebRTC not only supports live-streaming
WebRTC also supports recorded video that's asynchronous
Ziggeo supports asynchronous, WebRTC video to record video
(source: Ziggeo)
Ecosystem wise:
Has wrappers that simplify the development process, for instance easyRTC which works on any device (Android, Iphone)
There is also SimpleWebRTC that lets you build cool stuff with WebRTC in five minutes. and it has been around for a long time, and is now getting a bit more focus from its original developers; making it a compelling framework as well.
It provides a WebRTC server infrastructure that allows you to
record from a WebRTC feed and much more. You can also find some
examples for the application you are planning here. It is really
easy to add recording capabilities to that demo, and store the
media file in a URI (local disk or wherever).
Has unoffical Jetty (a Java Web server framework) ports.
WebRTC is available on fewer browsers than Websockets
WebSocket on the other hand is designed for bi-directional communication between client and server. It is possible to stream audio and video over WebSocket (see here and here for an example). However, the technology and APIs are not inherently designed for efficient, robust streaming in the way that WebRTC is. But that is okay, since we are not streaming anyway.
Jetty, a Java Web server framework, supports Websockets out of the box.
Seemingly places
Both are relatively well-documented technologies with a strong StackOverflow prescence so getting outside help is fairly easy as these technologies are becoming ubiquitous in the online videocapture and streaming space. Uses JavaScript.
Both require node.js which is probably unfamiliar to most students participating on the project. It is also unfamiliar technology to us and is JavaScript-based, which may also be new.
Both are JavaScript frameworks.
Could, assuming a good interface between teams, hand over its data readily to the processing stage, hence decoupling the two domains.
Processing includes transferring asynchronously uploaded video-data, getting thumbnails from each submission, and returning it to the end-user when he or she wishes to view material, it also needs to be compressed for database storage, and decompressed to make it viewable on demand. The database must also store thumbnails and other metadata.
This step is tightly coupled with database design!
This requires a semi-robust server, as we probably lack the technical expertise to run a distributed service. There is a lot of content to keep in RAM and video processing is CPU/GPU intensive. However, once processed no additional work is required.