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