On 13-01-30 10:52 AM, Christopher Brooks wrote: > Whats the impact on migrating our big pre 1.4 mediapackages to 1.4 if > this changes the media package format? Will old ones without this > element still ingest all right?
I think those would be ok since they're being reprocessed. What worries me is what happens with the mediapackages which were already processed. I'm assuming that the upgrade path/script from 1.3 to 1.4 will add the required elements? G > Chris > > On Wed, 30 Jan 2013 10:47:06 -0800 Greg > Logan <greg.lo...@usask.ca> wrote: > >> On 13-01-30 05:53 AM, Michelle Ziegmann wrote: >>> As far as I understand your proposal, big +1 on this from Berkeley. >>> We could really use this functionality. >> >> I assume this goes into 1.4? I'm not a huge fan of introducing new >> (arguably) functionality into 1.4 at this point, but at the same time >> if it gets rid of the bugs then I'll let it pass. Assuming this >> proposal passes, do you have a timeline to getting this implemented? >> >> G >> >>> Thanks! >>> Michelle >>> >>> On 1/30/13 12:51 AM, Tobias Wunden wrote: >>>> Looking at the current list of bugs in Jira, it becomes obvious >>>> that a number of them is centered around archival. One problem is >>>> that the archive service, unless correctly configured, will try to >>>> archive things that shouldn't be archived, such as the files that >>>> have been copied to the streaming server featuring an rtmp:// url. >>>> But to allow for retraction some elements--namely those that >>>> represent distributions--have to be retained in the media package >>>> even though their content is not subject to archival. >>>> >>>> Then at the moment it is very difficult for the archive to figure >>>> out whether a media package has been distributed, and if so, to >>>> which distribution channels. In order to move Matterhorn towards a >>>> media management system it is an indispensable feature to make >>>> this clearly determinable. >>>> >>>> Another goal of this proposal is to unify the concept of >>>> distribution. In the current situation Engage is handled quite >>>> differently than e.g. YouTube where separate steps for copying and >>>> publishing to search have to be done. The goal is to have a 1:1 >>>> relationship between a distribution channel, its distribution >>>> service and associated workflow operation handler and the >>>> corresponding entry in the media package. >>>> >>>> PROBLEM >>>> >>>> The reason for these problems is that we are currently using a >>>> concept called "derived tracks" to detect distribution status, for >>>> example if there is a track, that is derived from the source track >>>> (the ingested media), and whose url starts with the download url, >>>> then we know that the media package has been distributed to the >>>> download server. This is not ideal for many reasons, with the most >>>> prominent ones being: >>>> >>>> - the download artifact may be used by different presentations of >>>> the mediapackage, e. g. the Media Module, a video repository >>>> connected through OAI-PMH metadata harvesting, RSS/ATOM feeds etc. >>>> So what does retracting this mediapackage really mean, or what >>>> does it mean for the representations if the media is removed from >>>> the download server? >>>> >>>> - the admin ui that wants to provide the administrator with the >>>> link to the "final product" (i. e. the representation of the media >>>> package on the Engage UI or on YouTube) needs to have in depth >>>> knowledge about these representations, for example it needs to >>>> know that youtube tracks have a URL starting with youtube.com, so >>>> it would determine distribution status to youtube by going through >>>> the mediapackage, looking at all tracks to find one with a >>>> matching url. >>>> >>>> PROPOSED SOLUTION >>>> >>>> We are proposing a solution to all these problems that allows >>>> Matterhorn to indicate to the administrator which channels a >>>> certain MediaPackage has been distributed to without the need for >>>> the admin ui to have knowledge about specific track properties for >>>> a given distribution channel. >>>> >>>> A new element is introduced to the Mediapackage called >>>> "<presentation>" that identifies the distribution channel as well >>>> as the url that is used to consume the distributed artifact. This >>>> url can point to e.g. a web page with the embedded video in case >>>> of channels like Engage/Player or YouTube or a feed URL in case of >>>> an RSS feed. >>>> >>>> Which elements have been actually used to make up a distribution >>>> and to keep track of them in order to allow for retraction now lies >>>> completely whithin the responsibility of the distribution channel. >>>> To support some simple data storage right in the media package the >>>> new element features a simple key/value dictionary. These >>>> key/value pairs may also be used to implement efficient storage >>>> and retraction strategies. >>>> >>>> <mediapackage> >>>> ... >>>> <presentations> >>>> >>>> <presentation id="p-1" channel="youtube"> >>>> <uri>http://www.youtube.com/watch?v=D1R-jKKp3NA</uri> >>>> <mimetype>text/html</mimetype> >>>> <!-- the dictionary is freely managed by the distribution >>>> channel and may take arbitrary key/value data --> >>>> <dict> >>>> <value key="access-token">D1R-jKKp3NA</value> >>>> </dict> >>>> </presentation> >>>> >>>> <presentation id="p-2" channel="engage"> >>>> >>>> <uri>http://downloads.myinstitution.edu/engage/ui/watch.html?id=123123s</uri> >>>> >>>> <mimetype>text/html</mimetype> >>>> </presentation> >>>> >>>> <presentation id="p-3" channel="feeds"> >>>> <uri>http://downloads.myinstitution.edu/feeds/entries/342345</uri> >>>> <mimetype>application/rss+xml</mimetype> >>>> </presentation> >>>> >>>> </presentations> >>>> -- >>>> </mediapackage> >>>> >>>> By adding this element to a media package, it would immediately be >>>> obvious to which channels it has been distributed to (and how it >>>> can be reached in that channel), and rather than creating data >>>> structures in the mediapackage and using those to derive the >>>> distribution status and guess the actual representation, the entry >>>> points into consumption of the mediapackage are clearly defined. >>>> >>>> This change doesn't touch existing data structures and will >>>> therefore not impact existing functionality. But it will allow us >>>> to close out all of the remaining bugs that are related to >>>> archival and retraction. >>>> >>>> Looking forward to your +/-1's and/or comments. >>>> >>>> Tobias >>>> _______________________________________________ >>>> Matterhorn mailing list >>>> Matterhorn@opencastproject.org >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>> >>>> >>>> To unsubscribe please email >>>> matterhorn-unsubscr...@opencastproject.org >>>> _______________________________________________ >>> >> >> > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
