Ruben, While your are still strongly thinking on this subject, consider how the following situation would benefit from the proposal or a modified proposal. In short we are trying archive the final product that is distributed, but the distribution protocol should not, and can not, be used by the archive process.
Situation: A Matterhorn ingests raw media input, processes it, and distributes it to a streaming server. The distribution stream protocol is RTMP. The Matterhorn media package now only knows about the raw input files and the final distribution. The distribution is accessible by students via a streaming server through a flash player via the RTMP protocol. The RTMP protocol only streams through something that can play it, no file download possible (totally different topic of conversation!). This (customized) workflow may be missing some critical step, because the media package does not remember where it copied the actual transcode files. It only knows the transcoded files ended up accessible via RTMP, which means they fell off the edge of the Earth for Matterhorn. So, we have 2 issues 1) How can the final distribution be played from the Matterhorn UI via RTMP through our flash server, without Matterhorn trying to download the file. 2) How do we identify and store (archive) media files that distributed and accessible to others via RTMP, but accessible to Matterhorn as regular files from the directory where it saved them, without making lots of extra copies. Cordially, Karen > I agree and disagree as we were discussing presentation vs. distribution as > well. The reason for sticking with "presentation" in the proposal was that > distributing a file (e. g. to the download server) is different from > presenting it (e. g. on a video portal or in feeds). In fact, multiple > representations may be based on the same distribution. > > 3) I have just realized of the "channel" argument in the second example given > by Tobias. Shouldn't we make a difference between elements distributed as > "downloads" and as "streaming"? In that case, "engage" would be an ambiguous > term, and we should specify 'channel="engage-download"' or > 'channel="engage-streaming"' (or, at least, 'channel="download"' or > 'channel="streaming"'). I know those are mere examples, and not "real" pieces > of xml, but I think it's good to point this out and make it clear. > > Again, the presentations should be differentiated from the file distribution. > If this proposal is accepted, it would probably be up to the presentation > services (e. g the search service aka engage) to use the distribution > services to place the files rather than the workflow randomly throwing files > onto the download server. Every presentation instance would need to make sure > that the files or streams they are representing is in the right place (and > removed if retracted). So as a result, distribution would be a responsibility > of each presentation channel. > > I think the workflows are no more "randomly throwing files onto the download > server" than the Youtube service is "randomly storing files at some external > server who-knows-where". The distribution service knows which elements are > distributed simply by inspecting their URL. That doesn't mean we cannot be > more explicit about the state of "distribution" of the Mediapackage elements, > but it doesn't make it "random" either. > > That being say, I think the proposal is lacking a clear way of defining > relationships between published elements. If we agree that the URL that opens > a certain Mediapackage in the engage player is a presentation, then we must > agree that the URL from where the media is fetched in the download server is > also a presentation, because any user can download the files directly without > using the Engage player at all, or maybe stream them directly using, say, VLC. > > For instance, we should end up with, at least, three presentations if we > publish a Mediapackage at the engage server via download: one entry for the > presenter file at the download server, another for the slides video at the > download server, and another one for the URL to the video in the Engage > server. But this last presentation depends on both the others in order to be > available. > > Therefore, no matter if the publishing services take care of triggering the > distribution of the relevant media (which involves modifying the current > services and implement ways to decide which type(s) of distribution they will > use) or the workflows distribute the media explicitly, we must be exhaustive > with all the kinds of presentations a MediaPackage has, or at least state > explicitly that the Engage Service (or rather the download and streaming > services) are an exception. > > And, still, in the case we go with the refactoring of the publishing services > to manage the distribution of the media, we need a way to coordinate between > different publishing systems using the same distributed media (several > publications accessing the same resources via the download server, for > instance). >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
