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] _______________________________________________
