Hi Brandon, Good questions, responses in-line below:
Kindest Regards, Benjamin Hubbard ETS | webcast.berkeley 510 812-7018 On Dec 14, 2011, at 4:08 PM, Brandon Muramatsu wrote: > Ben, two followup questions. > > 1. For past semesters of video, what sort of data transfer are you seeing on > videos from webcast.berkeley? > > So all of the UCB video goes to YouTube + webcast. We publish video to YouTube, we host RSS feeds for both audio and video (video webcast and screencast) on our own servers and submit those feeds to iTunes U. webcast.berkeley simply aggregates those distribution channels back to a local site. In that way, traffic on our servers is mitigated by A.) YouTube's hosting of our content and B.) iTunes U's Akamai network which, will cache content that is being frequently accessed to ensure performance for Apple's customers (I assume). > And didn't you put all that older stuff back online after the community > complained?. We restored about 170 courses that were inadvertently taken down during the transition from our old site to the new one over the summer. These 170 courses were already in a non-real format with all the associated metadata in the RSS feed. We have planned (and continue to plan) to make the real files that were taken down available for a brief period of time so users who wish to access them can download them. Our top priority, of course, is continuing to server our currently enrolled students so that is where most of our effort is going. > What sort of data transfer are you seeing for that older stuff (however you > choose to report the data, monthly data transfer rates for the last few > months, whatever) for a sense of scale? It'd be really hard to say what the data transfer rate or total data transferred for a period of time would be since we don't carry the burden for our YouTube content and the most popular content on iTunes U isn't being accessed directly from our servers (due to the akamaization..). Last Spring we were headed towards 400,000 visitors per month. I don't know what that translates to in data transfer because we haven't really tracked it (we don't pay for bandwidth through our central IT services group, who maintain the servers/storage we utilize). > > I ask because I'm wondering what, say, hosting that stuff through EC2 might > look like cost wise as part of a data migration/retention strategy. So > perhaps keep a copy of the raw stuff within a campus environment (tape / > disk) as has already been mentioned, keep the current term on a fully > accessible disk system, and put the older produced stuff in the cloud. We have been hosting our current semester's course lectures on Amazon for business resumption in the event of a major disaster/failure. It's a pretty light-weight way in which to ensure access for current semester enrolled students but probably wouldn't be practical for our entire catalog. > > 2. What's your current storage needs for the last couple of semesters > (similar to Chris' numbers)? And predicted growth? We're currently using over a TB for all the courses we deliver through iTunes U. Based on some back of the envelope calculations it seems like we are headed towards 500GB per semester. It will be interesting to see what the impact of non-public course capture (access behind authentication), dual capture in the major auditoriums, and the Matterhorn Media Module will have on our storage needs. My guess is that our local storage needs could double (or triple), depending on future participation in the webcast.berkeley program. > > > Brandon Muramatsu > <the non-video guy, really!, sitting next to Kris> > MIT Office of Educational Innovation and Technology > > On Wed, Dec 14, 2011 at 5:29 PM, <[email protected]> > wrote: > Message: 4 > Date: Wed, 14 Dec 2011 14:29:52 -0800 > From: Benjamin Hubbard <[email protected]> > To: Opencast Community <[email protected]> > Subject: Re: [Opencast] Do you have any policies for video? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Hi Kris, > > Info from UC Berkeley inline below. Hope this is helpful. > > Benjamin Hubbard > Manager, Production Services > UC Berkeley | ETS > > > On Dec 14, 2011, at 1:10 PM, Christopher Brooks wrote: > > > Hi Kris, > > > >> 1) What is the current storage amount per user? > > > > We don't measure this as we don't allow users to upload their own > > videos, we only do scheduled lecture recording and events at the moment. > > If a faculty member is teaching a course and in a lecture capture > > enabled room then it can be recorded for them regardless of how many > > other courses they might be teaching. > > UC Berkeley has more or less the same situation. In addition to our automated > lecture capture services, we also provide video production services for > campus events, scholarly activities, news and promotional pieces etc. In the > very earliest days of webcast.berkeley we charged our clients a hosting fee > that was $.40 per/MB. Obviously the cost of storage has come down > significantly since then and we are also offloading a major portion of our > hosting to YouTube. > > We are considering providing more services that empower the campus community > to produce and publish their own videos so I am interested in what you > discover. Would you be willing to share any responses from off-list? > > > > >> 2) What is the current retention policy - how long do files/videos > >> last? Is there an auto-destruction date or time? Is there the ability > >> to extend that? > > > > We keep the raw media that is captured by recording devices for at > > least 2 years unless the instructor asks for it to be destroyed before > > that. This time amount is an autodestruct, so they need to request > > that it be kept longer if they want it longer. > > > > We haven't offered the service for two years yet, but, my guess is that > > we'll keep data for users past this point only on a case by case basis, > > and that we will encourage users to export video to their local systems > > (in the case of a Department or College), or offer a minimal fee for > > the storage. This is pretty presumptuous on my part though. > > For published videos, we make no guarantees but rarely take anything offline. > This summer was a pretty major exception to that rule, given the fact that we > /finally/ retired our Real server and took a number of courses that were only > available in Real offline. > > All of our videos are archived indefinitely on data storage tape soon after > they are published. After the data is verified on tape we delete the working > files from our production environment. This is done by semester for courses > and more regularly for events and other productions. > > > > > >> 3) Is anything done in terms of archiving past > >> videos/courses and if so any restore possibilities? > > > > From the raw video we keep we can restore a video for student playback > > with 24-48 hour turn around time. > > > > We also keep videos in our playback tools for at least 30 days past the > > end of the course. We're considering at the moment what it would take > > to extend this (and plan to measure demand). > > > > Here are a couple of links to our published terms for faculty: > > > > http://www.usask.ca/its/services/e_learning/lecture-capture/frequently-asked-questions-faqs/index.php > > > > http://www.usask.ca/its/services/e_learning/lecture-capture/terms-of-service/index.php > > > > We do space estimates on a per course per semester basis. We have 13 > > weeks of courses at 3 hours per week. For engage we need > > 2.4GB/lecture, so this works out to roughly 100GB/course for storage. > > For working directories I think we're aiming for several hundred > > gigabytes, so that failures don't stop other lectures from processing. > > For archiving, believe it or not, it's actually less data. Roughly > > 1.5GB per lecture, so we use around 60 GB/course. > > > > We're doing a dozen courses/semester now, and thinking of doubling that > > next year. So we'll be using 6.5 terabytes of archive once the first > > lectures begin to expire from archives. Predicting doubled growth for > > three or so years of offering this service. > > > > Regards, > > > > Chris > > _______________________________________________ > > Community mailing list > > [email protected] > > http://lists.opencastproject.org/mailman/listinfo/community > > > > > > To unsubscribe please email > > [email protected] > > _______________________________________________ > > > > ------------------------------ > > _______________________________________________ > Community mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/community > > > End of Community Digest, Vol 31, Issue 3 > **************************************** > > _______________________________________________ > Community mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/community > > > To unsubscribe please email > [email protected] > _______________________________________________
_______________________________________________ Community mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/community To unsubscribe please email [email protected] _______________________________________________
