As usual, I won't go into the technical details, but from my understanding, we have to look at this from the distribution end of things. Unless you want some "picture-in-picture" solution (covering part of the relevant information), there will always be a distribution channel with just one video which should be "video-presentation" (aka slides, presentation) plus audio - chop off the talking head if you have one. Those with two videos will have to argue for a selection to be possible.
O > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:matterhorn- > [email protected]] Im Auftrag von Judy Stern > Gesendet: Dienstag, 15. März 2011 18:46 > An: Opencast Matterhorn > Betreff: Re: [Opencast Matterhorn] multifile upload #proposal > > This is an excellent question, Olaf. We certainly didn't think through what > was > going to happen with those "limited" distribution channels. (Do we need to > provide > options for admin to decide which tracks get published to individual > distribution > channels? Does Matterhorn have built in rules?) It is, of course, a question > that is > bigger than multi-file upload. What happens with scheduled captures, too, > which > could have multiple audio channels? Chris, Josh, Tobias, Adam, anybody: has > this already been discussed/solved? > > Judy > > On Mar 13, 2011, at 3:05 PM, Schulte Olaf A. wrote: > > > Just to round this off, at ETH we would be happy with the scenarios > > described > for UCB. A question to disclose my lack of knowledge of processing probably, > but > if the user was to upload "video-presenter & video-presentation (either or > both > could have muxed audio)", would the system automatically demux audio from the > video-presenter in order for it to be muxed with the video-presentation sans > audio > in distribution channels where this was necessary? Not sure whether this was > part > of the caveat you formulated, Judy. > > > > O > > > >> -----Ursprüngliche Nachricht----- > >> Von: [email protected] [mailto:matterhorn- > >> [email protected]] Im Auftrag von Christopher Brooks > >> Gesendet: Freitag, 11. März 2011 23:02 > >> An: Opencast Matterhorn > >> Betreff: Re: [Opencast Matterhorn] multifile upload #proposal > >> > >> I could live without it. > >> > >> (would write scripting to put it in). > >> > >> But pretty critical for a 1.3 I think, to do (ideally), n-way upload of > >> video of different types (any number of videos would be perfect). > >> > >> Chris > >> > >> On Fri, 11 Mar 2011 13:59:51 -0800 > >> Judy Stern <[email protected]> wrote: > >> > >>> Thanks, guys. Not surprising; we've talked about this set-up a bunch > >>> in the past. Question is "how important?". Current default workflow > >>> can't handle this scenario, but maybe we should revisit in upcoming > >>> team or PO meeting, if you consider it critical for 1.2. Adam, can > >>> you add to agenda? > >>> > >>> Judy > >>> > >>> On Mar 11, 2011, at 9:11 AM, Bruce Sandhorst wrote: > >>> > >>>> We have several rooms like that. > >>>> > >>>> Bruce > >>>> > >>>> On Mar 11, 2011, at 10:31 AM, Christopher Brooks wrote: > >>>> > >>>>> Judy, > >>>>> > >>>>> We have a room with two video-presentations, no video-presenter > >>>>> (that we use), and one audio. > >>>>> > >>>>> Chris > >>>>> > >>>>> On Thu, 10 Mar 2011 15:39:25 -0800 > >>>>> Judy Stern <[email protected]> wrote: > >>>>> > >>>>>> Adam and I came up with a simple solution for dealing with > >>>>>> mutlifile upload in this iteration. To do this we have scoped it > >>>>>> to handle only the scenarios that we believe will be most common: > >>>>>> 1) video-presenter & video-presentation (either or both could > >>>>>> have muxed audio) 2) single video and audio file 3) video > >>>>>> (video-presenter), audio (audio-presenter), screen > >>>>>> (video-presentation), i.e. what we're currently expecting from > >>>>>> capture agent. In all cases, the assumption will be that the > >>>>>> files are already synched; in this iteration (and likely in 1.2) > >>>>>> we will provide no synching tools. > >>>>>> > >>>>>> If we are missing scenarios that you anticipate, please let us > >>>>>> know asap. > >>>>>> > >>>>>> A sketch is here: > >>>>>> http://opencast.jira.com/wiki/display/MH/Multistream+ingest+for+MH- > >> 2680+March2011 > >>>>>> > >>>>>> Some notes: > >>>>>> Though there are many examples of multifile upload out there, our > >>>>>> designs aren't so simple because of the current "one file per > >>>>>> flavor" limitation/feature. We considered providing the ability > >>>>>> to upload two audio files (knowing that they *could* be processed > >>>>>> if they were different flavors) but couldn't come up with a > >>>>>> likely scenario where this was necessary, so have kept the design > >>>>>> even simpler by providing the ability to upload only one > >>>>>> audio-only file. Adam's recollection of the default workflow was > >>>>>> that if there was an audio-presenter track, that it would be the > >>>>>> one processed (rather than any audio that that was muxed with > >>>>>> video-presenter) so text in the UI reflects this; if we are > >>>>>> wrong, please let us know asap. As always, wording to adequately > >>>>>> describe flavors is tricky; happy to hear any better suggestions. > >>>>>> > >>>>>> I've also put together a very rough sketch (with all the caveats > >>>>>> above) for a design that's more dynamic, i.e. "slots" for files > >>>>>> to be uploaded are added at the user's request. I like it because > >>>>>> it's a little leaner for 2-file uploads, but requires a lot more > >>>>>> logic to implement. > >>>>>> > >> > <http://opencast.jira.com/wiki/display/MH/Alternative+Multistream+ingest+for+MH- > >> 2680+March2011> > >>>>>> I know it's not perfect either....maybe there's something that's > >>>>>> yet another variation to consider. > >>>>>> > >>>>>> > >>>>>> regards, > >>>>>> Judy > >>>>>> > >>>>>> Judy Stern > >>>>>> Educational Technology Services, UC Berkeley > >>>>>> [email protected] > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> 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] > >>>> _______________________________________________ > >>> > >>> Judy Stern > >>> Educational Technology Services, UC Berkeley > >>> [email protected] > >>> > >>> > >>> > >>> _______________________________________________ > >>> Matterhorn mailing list > >>> [email protected] > >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn > >>> > >>> > >>> To unsubscribe please email > >>> [email protected] > >>> _______________________________________________ > >> > >> > >> > >> -- > >> 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] > > _______________________________________________ > > Judy Stern > Educational Technology Services, UC Berkeley > [email protected] > > > > _______________________________________________ > 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] _______________________________________________
