Extracted from this thread<http://opencast.3480289.n2.nabble.com/Joint-efforts-by-NCast-and-Entwine-to-deliver-episode-service-td6743644.html>in the Matterhorn mail list * * *Tobias Wunden said:*
> I am happy to announce that NCast (ncast.com/) and Entwine ( > entwinemedia.com) are working together to develop what we call an "episode > service" for Matterhorn. *Adam Hochman said:* > Fantastic! *Chris Brooks said:* > By episode service, does this really mean mediapackage service? *Tobias Wunden said:* > Right. We are usually talking about series vs. episodes or recordings, > which is the reason I propose "episode" as part of the service's name rather > than media packages. *Chris Brooks said:* > Looking forward to seeing an API for this service! I feel proud to share the vision of a great developer as Tobias. I'm just sorry my ideas are not as welcome as his (which is perfectly understandable, though :P). El 7 de septiembre de 2011 03:09, Rubén Pérez <[email protected]>escribió: > Hi, Chris: > > I'm glad to get your remarks. Comments are inline. > > 2011/9/6 Christopher Brooks <[email protected]> > >> Hi, >> >> Just a couple of thoughts, >> >> > I strongly believe that those migration problems are perhaps caused >> > by a too-twisted treatment of the recordings and the workflows in >> > matterhorn. In the current philosophy, "workflow" is just a certain >> > way of seeing a mediapackage, while the search results are another >> >> I wouldn't quite say this. I'd say that a media package is a >> data structure, a workflow is a function, the results of running a >> workflow are a bunch of other data structures, and that there is not a >> clear link between the input data structure (media package) and the >> output data structures (indicies, media files, distributed files, other >> service calls, etc). >> >> When you upgrade matterhorn you may change the workflow (intermediate >> function). >> >> Note that the function can take an identical mediapackage but result in >> different output data structures. There is no garuntee that the >> function is a one way mapping. >> > > I was trying to reproduce some words Josh wrote to me once, but I may have > failed to do so. Apologies to him I misunderstood, and, well, maybe not > everyone shares his vision anyway. > However, I agree with you in most part, except in that "there is not a > clear link between the input data structure and the output data structures". > There is not a clear link because Matterhorn is not designed for it to be, > but it would be clearly easier if there was. Matterhorn is about media, so > the most important thing are media files (and metadata files), and the rest > (indexes, function calls) are just means for the system to work. Therefore, > we should see a workflow as a black box where a mediapackage comes in and > goes out modified somehow. For instance, a raw mediapackage with source > files (and metadata, I insist) goes in, and a *complete* mediapackage with > media files for downloading, watching online, etc. AND the original media > files (or not, depending on what we want) goes out. The distributed media > files should still be a part of the mediapackage BECAUSE they are a > different version of the same source media. > > >> > relates all the files of a mediapackage--, so that you just cannot >> > get a complete picture of the mediapackage altogether. I strongly >> > believe that we should see the mediapackage as a list of related >> > files including media, metadata and attachments TO WHICH you can >> >> I think the episode service is looking to do some of this. That said, >> I don't think anyone has suggested that published media is tied in any >> way to the originally ingested media package. Without this things like >> URLs will continue to change, and that remains a pain point for folks. >> > > I am suggesting that. If distributing to some channels, like iTunes, > requires submitting a copy of the video to somewhere out of our control, at > least Matterhorn should be aware that there's a distributed copy and allow > synchronization of that copy with any changes that are made within our > system. I don't think this is a lot to ask: some proposals and suggestions > have already been made to being able to synchronize, for instance, a change > in a certain recording title with the title in some or all of the channels > where it's distributed. It makes sense if we stick to the abstraction that > all related media files (sources and files derivated from them) ARE in the > same mediapackage. > > >> > mediapackages at the system, to which you can apply different >> > workflows, thus modifying the number, type, flavor, metadata, etc. of >> > the files in the mediapackage. 2) Everything is centralized: the >> > mediapackage flavors can tell you which files were the originally >> >> How do you manage distributed artifacts as part of the media package? >> E.g. something we publish to itunes? >> > > How do you manage distributed artifacts now? As far as I know, you can't -- > I mean, you can't *from Matterhorn* (obviously you can go to iTunes and > manage them from there). But, let's say we have a mediapackage with some > distributed files, which ARE actually there (somehow you inspect the > mediapackage and you can see some files distributed to iTunes, for instance > with the flavour "presentacion/itunes" --remember that a file in a > mediapackage is little more than an URL in an .xml file or in an index--). > Then you want to modify the title. You go to your mediapackage and modify > it, and that should trigger a workflow that, using the > ITunesDistributionService REST services will modify the title in iTunes > accordingly. If, instead, the workflow results are different files scattered > along different distributing channels with no relation between them, it is > really tricky to get to the distributed files from the source mediapackage, > if for instance you want to make modifications in ALL the channels to which > a certain recording is distributed. > > > Chris >> -- >> Christopher Brooks, BSc, MSc >> ARIES Laboratory, University of Saskatchewan >> >> Web: http://www.cs.usask.ca/~cab938 >> Phone: 1.306.966.1442 >> Mail: Advanced Research in Intelligent Educational Systems Laboratory >> Department of Computer Science >> University of Saskatchewan >> 176 Thorvaldson Building >> 110 Science Place >> Saskatoon, SK >> S7N 5C9 >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
