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