As an avid live event watcher I'd like to go to our University's Matterhorn-based video portal and see the live events that are scheduled for today, and the near future, in addition to the video on demand for past events that have been captured, ingested, processed and published by Matterhorn.
For instance, my university's video portal shows me that an event is scheduled for today at 1 pm. Great! At exactly 1 pm, I'll be able to watch the live event in our video portal (the live event is produced by a cameraman + Wirecast + Wowza + some video player, based on Matterhorn metadata). After the live event is over, I'd be able to watch the event('s) recording(s) which has/have been uploaded to the portal by the cameraman.
Because the live event metadata and recording metadata are both handled by Matterhorn, the live and captured events would not be individual entries in the video portal's calendar but a joint entry, which would give me as a video watcher a nice user experience.
Alexander Bias' kiz - Media Department at University of Ulm is experimenting with the following setup:
A live streaming session is scheduled in Matterhorn with a special MH workflow (without processing instructions)
Our NCast CAs get the scheduled live streaming dates and start an appropriate NCast channel with does live streaming instead of recording
The live stream is sent to Wowza where it is fetched by a web based video player (FlowPlayer) which is hosted separately
As the CA does not return a recording to Matterhorn, there will be an error message about no CA upload in the MH backend which has to be ignored actively
The following is a suggestion for a potentially more integrated Matterhorn solution.
The following requires API enhancements between Matterhorn and the student facing system, and Matterhorn and capture agents (or live stream redirecting, capture agent emulating, WOWZA servers).
1. If the capture agent, or smart WOWZA server, can live stream and retrieve scheduled event metadata from Matterhorn, modify the Matterhorn Scheduling workflow to accept two booleans, one for "capture-to-live-stream" and one for "capture-to-file". Pass the live/file capture flags to the capture agent in the manner that the capture agent can properly interpret (Capture Agent API).
2. Provide a way for the Matterhorn mediapackage manifest to reference live-streamed media "track" versus physical media. (presenter/live, presentation/live?)
3. Ensure that the publish-engage workflow operation handler allows publishing a manifest with a live-stream "track" without actually distributing physical media files.
4. Add a new publish-engage operation to the (currently hardcoded) Schedule Workflow, between the current schedule and capture operations. Add an if/then to skip the new publish-engage operation if there is no live event. The Workflow will enter the usual capture hold state after either skipping or executing the publish of the live event.
5. Because the live-event is now included in the search engine index, ensure the client facing media player or calendar Ui can distinguish between isLive and captured events. The UI could provide a proper message to the user before and after the live stream is active and can play a live-stream "track". For example: "the live event has not started" or "the live event has completed, the published material is coming soon".
6. After the captured media is ingested for this event, and before it is published, remove the live-stream references from the media package. The usual publish with materials occurs.
If this is a live-ony event, with no media to ingest, allow the workflow to skip over the "ingest" operation from the Schedule Workflow into a neutral hold operation. Provide a cron/quartz job that appends a workflow with retract and cleanup operations to the scheduling workflow instances that are live-only and are past the stop time of the event.