"Designing an Enterprise Video Capture System” - 2010 CCUMC Annual Conference, to Buffalo, New York October 6-10, 2010

1. Designing an Enterprise Video Capture System
Andy Wasklewicz
TECHNOLOGY ARCHITECT
Stanford University School of Medicine

2. Context

3. Overview
‣ World leader in medical research and training
‣ Emphasis on multi-disciplinary research
‣ Curriculum that melds the study of basic science and the clinical
practice of medicine

4. Basic Facts
‣ Medical School Students: 400
‣ Students in 5+ years Graduate Students: 820
‣ Postdoctoral Scholars & Clinical Fellows: 1418
‣ Undergraduate & graduate students outside the SoM served by
the school: 628
‣ Faculty: Practicing clinicians and researchers

5. Culture of Capture
‣ 1980’s - Capture on VHS - available for checkout
‣ 1998 - Streaming REAL media
‣ 2007 - REAL downloadable
‣ 2008 - H.264/.MP4 downloadable

6. Curriculum Changes
‣ Move to fewer lectures
‣ More small group and team-based learning
‣ More integrated approach - move away from discipline based
courses
‣ We still capture a lot!

7. Internal Drivers

8. Accreditation
‣ Shift to “measurable outcomes”
‣ Proven skill-based competencies
‣ Curriculum tracking (database)

9. Off Campus Growth
‣ Moving research departments
‣ Moving clinical departments
‣ Distribute content beyond MD curriculum

10. Video Beyond Lectures
‣ Public web video increasing
‣ Requests for special video
‣ People creating their own videos
(teaching and research)
‣ Students self-capturing for skills documentations

11. SoM Technology Trends
‣ Mobility
‣ 80% of student population reports regularly using portable media
device
‣ 75% have phones capable of playing media
‣ Median time spent on laptop 6-8 hours daily
Stanford School of Medicine. January 2009. Student Technology Ownership and Use Survey

12. Quality & Formats
‣ Student/Faculty expectations
‣ Mobile devices to HD screens
Stanford School of Medicine. January 2009. Student Technology Ownership and Use Survey

13. New Building
‣ Li Ka Shing Center for Learning and Knowledge
‣ Intersection between School of Medicine, Hospitals
Computer Science, Engineering

16. External Drivers

17. Storage
‣ Cheaper, faster, bigger
‣ Cloud storage

18. Capture & Encoding Hardware
‣ Cheaper, faster
‣ Efficiency
‣ Video quality

19. Mobile Capture Hardware
‣ Smaller, cheaper, faster
‣ Mobile consumer hardware
‣ Students can & will capture lecture themselves

20. Distribution Channels
‣ Home grown solutions
‣ Custom applications
‣ Learning Management Systems
‣ iTunesU
‣ Youtube

21. Stanford on YouTube - Views
8M
6M
5M
3M
2M
0M
2008 2009 2010
Stanford Office of Communications. March 2010.

22. Stanford on iTunesU - Downloads
10M
8M
6M
4M
2M
0M
2008 2009 2010
Stanford Office of Communications. March 2010.

23. Open Communities
‣ OpenCast
‣ Podcast Producer
‣ MediaCore

24. Policy & Conversations

25. Education and Discussion
‣ Listen to faculty concerns
‣ Engage in OPEN dialogue
‣ Partner with University Council

26. Releases and Rights
‣ University media release
‣ Stanford School of Medicine release
‣ Creative Commons Licensing

27. Student Responsibility
‣ Cover all course materials (electronic and hard copy)
‣ Provide students with more flexibility to access course materials
‣ Clarify policy on student sharing of course materials
‣ Address faculty concerns regarding redistribution of content

28. Content Access & Appropriate Use
Stanford University School of Medicine course materials are intended
for curriculum and course related purposes and are copyrighted by
the University. Appropriate access to this content is given for personal
academic study and review purposes only. Unless otherwise stated in
writing, this content may not be shared, distributed, modified,
transmitted, reused, sold, or otherwise disseminated.

29. Content Access & Appropriate Use
These materials may also be protected by additional copyright; any
further use of this material may be in violation of federal copyright law.
Violators of this policy will be referred to the Committee on
Professionalism, Performance and Promotion for disciplinary
purposes.

30. Archiving Policy
‣ How long to keep?
‣ Who decides?
‣ Retrieval

31. MediaFlow

32. MediaFlow

33. MediaFlow Goals
‣ Automate the capture of all core classes and events
‣ Consolidate event data
‣ Video from anywhere to anywhere
‣ 5pm same day deadline for delivery of all media
‣ Modular systems design

34. System Architecture
‣ Anywhere to anywhere
‣ Decoupled systems
‣ Plan for and accept obsolescence

35. MediaFlow - Core AV
‣ Two years of design/prototyping
‣ 500+ hardware components
‣ Eight miles AV fiber

36. MediaFlow - Core IT
‣ 16 Apple XServe cluster
‣ 220Ghz processing power
‣ 44TB SAN storage

37. AV Fiber
Custom/Podcast Producer
Camera Encoders Primary Master
External Fiber
Custom/Xgrid
Fiber Channel
Distribution
Shared Storage
Sakai
iTunesU RSS/ATOM
YouTube
Internal

38. MediaFlow - Core IT
Preflight
Archive Original Text2Speech Add Watermark Generate Bumpers
Merge Movies Merge Movies with
without transitions Transitions
Encode for iPod Encode for High Encode for iPod Encode for High
Audio Quality Video Video Quality Video
Add Chapters Generate Chapters Generate Chapters
OCR Chapters

39. MediaFlow - Maestro
‣ Front-end metadata capture
for course administrators
‣ Java, Tomcat, Oracle

40. MediaFlow - MediaFlowProxy
‣ Link between Maestro and core systems
‣ Provides data for digital signs
‣ Provides delay/start/stop/extend/flag functionality
‣ Collaboration with Apple
‣ Java, Tomcat, MySQL

42. MediaFlow - StreamGrabber
‣ Interface between MFP and network
encoders
‣ Collaboration between Stanford and
Telestream
‣ Objective C, C++, C

43. MediaFlow - Video Output
‣ H.264, MP4 wrapper
‣ Three different video “types”
‣ Playable on computer, mobile devices
‣ Output all Open and proprietary
formats simultaneously (WebM, Theora)

44. Content Page

45. MediaFlow - Media Asset Management
‣ Automated ingestion of assets
‣ Automated tagging of assets
‣ Multiple levels of categorization
‣ All metadata “lives with” asset

46. Maestro Design Process

47. Designing Maestro
‣ Use cases
‣ Flow diagrams
‣ UI wireframes (whiteboard, Omnigraffle)
‣ Iterations based on feedback from users

54. Maestro QA
‣ Team of four student QA Testers
‣ Developed test cases based on specifications
‣ Tested every test case on new features
‣ Fogbugz for case tracking
‣ Google Doc for test cases

56. Lessons Learned
‣ Plan for obsolescence
‣ Decoupled systems
‣ Vibrant lecture capture community
‣ Long term relationship

57. What’s Next
‣ Open Source all code/documentation
‣ Provide lessons learned to community
‣ Provide policies
‣ Planning version 2.0