Broadcast management system

A broadcast management system creates, manages, and streams a broadcast of an event from videos captured from multiple cameras. A video capture system comprising multiple cameras captures videos of the event and transmits the videos to a broadcast management server. The broadcast management server generates a website or other graphical interface that simultaneously displays the captured videos in a time-synchronized manner. A broadcast manager user creates a broadcast by selecting which video to output to the broadcast at any given time. A broadcast map is stored for each broadcast that includes all of the broadcast decisions made by the broadcast manager user such that the broadcast can be recreated at a later time by applying the broadcast map to the raw videos. Using a viewer client, viewers can browse or search for broadcasts and select a broadcast for viewing.

BACKGROUND

1. Technical Field

This disclosure relates to a broadcast management system, and more specifically, to an application for creating customized broadcasts from multiple video streams.

2. Description of the Related Arts

In recent years, the creation and distribution of digital videos has become increasingly popular. Improvements in digital camera technology has made high quality video cameras both affordable and easy to operate. Video editing software provides convenient tools for editing video files or stitching together multiple video files. Furthermore, numerous video sharing websites allow users to easily share video content with any number of viewers.

Despite these advances in video technology, conventional systems are not well-suited for creating and sharing amateur broadcasts of live events such as sports or concerts. These events are ideally captured using multiple video cameras recording simultaneously. For example, at sports events cameras are commonly placed at different locations around a playing field or arena. Different cameras may focus on different portions of the playing field, follow different players or participants, or capture the event from various angles. Although some video sharing websites allow users to stream a video in real-time, conventional solutions do not provide tools for real-time control, editing, and management of multiple video streams.

In professional broadcast systems, multiple camera feeds are fed to a director's room and displayed on panels of monitors. A broadcast director simultaneously views all of the different camera feeds, and at any given time, selects a feed for broadcasting. However, these professional broadcast systems are extremely expensive and rely on dozens of trained employees working concurrently to manage the broadcast. Thus, these broadcast systems are feasible only for large network or cable broadcasting corporations and are not compatible with the needs of an amateur broadcaster.

DETAILED DESCRIPTION

Overview

A broadcast management system (and method) provides broadcasters, professional and amateur, a configuration for creating, managing, and streaming broadcasts from multiple cameras. The cameras are consumer grade and the system configuration allows for an inexpensive production configuration without the expense of professional grade equipment.

The broadcast management system could be used to produce low-cost broadcasts of local events (or activities), including sporting events, theater performances, concerts, weddings, or other events that are not typically covered by professional broadcast companies. Examples of such local events include grade school or high school events, and performances, family gatherings, recreational activities, and business organization activities. In one example embodiment, live broadcasts can be created and streamed to any number of viewers in real-time as the event is happening, such as a high school basketball game or football game or a grade school recital concert. In another example embodiment, users can create broadcasts from previously stored video files, such as a wedding, an anniversary party, a birthday celebration, or business team building event.

In one example embodiment of a broadcast management system and method, a broadcast management system receives a plurality of videos comprising at least a first video and a second video. The broadcast management system generates a broadcast management interface comprising a first stream window for playing the first video and a second stream window for playing the second video concurrently with the first video. The first and second videos are played in synchronization with respect to a universal clock. Responsive to receiving a selection of the first stream window while the first video is playing, the broadcast management system streams the first video to a broadcast viewer client. Responsive to receiving a selection of the second stream window while the second video is playing, the broadcast management system streams the second video stream to the broadcast viewer client.

In one embodiment, the broadcast is created from previously received video files. The received first and second video files include timestamps representative of capture start times of the first and second video files relative to the universal clock. The broadcast management system determines replay start times for the first and second video files according to the timestamps such that relative timing of the replay start times matches relative timing of the capture start times.

In one embodiment, a computer-readable storage medium stores computer-executable program instructions for executing the method of the broadcast management system described above.

Unlike professional broadcast systems, users can create high quality broadcasts using low cost digital cameras and a user-friendly broadcast management application. Advantageously, the broadcast management system is well-suited for amateur broadcasters without requiring the personnel, resources, or budgets of traditional professional broadcast systems.

System Architecture

A broadcast management system100allows a user to produce a broadcast of an event captured from multiple time-synchronized video cameras.FIG. 1is a high level block diagram of the broadcast management system100according to one embodiment.FIG. 1illustrates a video capture system110, a broadcast management server120, a broadcast management client130, and a viewer client140, all connected by a network150. Only one video capture system110, broadcast management server120, broadcast management client130, and viewer client140are shown inFIG. 1in order to simplify and clarify the description. However, embodiments of the broadcast management system100can have thousands or millions of clients130,140, as well as multiple broadcast management servers120and video capture systems110.

The video capture system110captures videos and provides the captured videos to the broadcast management server120. In a typical broadcast situation, the video capture system110comprises two or more cameras positioned at different locations to simultaneously capture video footage of an event. For example, at a sporting event, the video capture system110may comprise two or more cameras positioned at different locations around a playing field to capture the action from multiple angles. Furthermore, different cameras may be used to focus on different portions of the playing field. Additional cameras may be mounted on helmets or bodies of the participating athletes. Other cameras may be used to capture additional relevant footage in areas around the playing field such as, for example, the sidelines or the crowd. An example embodiment of a video capture system110is described in more detail below with respect toFIG. 3. Although the examples noted are in the context of sporting events, they may be applied to other settings where multiple cameras may be present, for example, theatrical productions, concerts, and educational seminars.

The broadcast management server120provides broadcast management tools that allow a user (e.g., a broadcast manager) to create and manage a video broadcast using the videos captured by the video capture system110. In one embodiment, the broadcast management server120hosts a broadcast management website accessible using a broadcast management client130or viewer client140. The broadcast management server120receives captured videos from the video capture system110via the network150, generates a broadcast according to instructions provided by the broadcast manager user via the broadcast management client130, and serves the broadcast to a viewer client140. An example embodiment of a broadcast management server120is described in more detail below with respect toFIG. 4.

The broadcast management client130comprises a computer or other electronic device operated by a broadcast manager user to create and control broadcasts using the broadcast management server120. For example, in one embodiment, the broadcast management client130comprises a personal computer executing a web browser that can access a broadcast management website hosted by the broadcast management server120. In other embodiments, the broadcast management client130is an electronic device other than a personal computer, such as a personal digital assistant (PDA), a smartphone, a mobile telephone, a tablet computer, a television “set-top box,” or the like. After accessing the broadcast management server120, a broadcast manager user can use the tools provided by the broadcast management server120to create, view, and manage video broadcasts.

The viewer client140is a computer or other electronic device used by one or more users to view broadcasts generated and served by the broadcast management server120. Like the broadcast management client130, the viewer client140can comprise a personal computer executing a web browser or another electronic device. A user (e.g., viewer) can access the broadcast management server120using the viewer client140, and use the available tools to browse and/or search for available broadcasts, and view a selected broadcast. Although illustrated separately for the purpose of clarity of description, a single client device is typically capable of acting as either a viewer client140or a broadcast management client130. In one embodiment, the viewer client140comprises a display at the event being broadcasted (e.g., a scoreboard or big screen) that is coupled to the broadcast management client130. For example, the broadcast management system100could be used to display real-time action or replays of action at a sports event on big screen or scoreboard.

The network150enables communications among the entities connected to it. In one embodiment, the network150is the Internet and uses standard communications technologies and/or protocols. Thus, the network150can include links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), long term evolution (LTE), 3G, digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc. Similarly, the networking protocols used on the network150can include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the network150can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In addition, all or some of links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc. In another embodiment, the entities use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

At least a portion of the network150can comprise a mobile (e.g., cellular or wireless) data network such as those provided by wireless carriers, for example, VERIZON, AT&T, T-MOBILE, SPRINT, O2, VODAPHONE, and other wireless carriers. In some embodiments, the network150comprises a combination of communication technologies. For example, in one embodiment, communication between the video capture system110and the video server120occurs over a cellular data network, while communication between the video server120and the clients130,140occurs over the Internet using an internet protocol. In another embodiment, the viewer client140comprises a television, and the broadcast management client130communicates with the client140using cable, satellite, or over-the-air television protocols.

In alternative embodiments of the broadcast management system100, two or more of the entities can be directly coupled by means other than the network150. For example, in one alternative embodiment, the video capture system110is coupled directly to the broadcast management server120. In another alternative embodiment, the broadcast management client130and broadcast management server120comprises a single machine. In this embodiment, a broadcast manager user manages a broadcast using tools provided by a locally executing application rather than a web-based application or website.

Turning now toFIG. 2, it is a high-level block diagram illustrating a typical computer200for use as a broadcast management server120, broadcast management client130, and/or viewer client140. Illustrated are a processor202coupled to a data bus204. Also coupled to the bus204are a memory206, a storage device208, an input device210(e.g., a keyboard and/or a mouse), a graphics adapter212, and a network adapter216. A display218is coupled to the graphics adapter212.

The processor202may be any general-purpose processor. The processor202is configurable to execute instructions, for example, instructions corresponding to the processes described herein. The storage device208is, in one embodiment, a hard disk drive but can also be any other device capable of storing data, such as a writeable compact disk (CD) or DVD, or a solid-state memory device. The memory206may be, for example, firmware, read-only memory (ROM), non-volatile random access memory (NVRAM), and/or RAM. The storage device208and/or the memory206are configured to store instructions and data that can be executed by the processor202. The input device214may be a keyboard, a mouse, track ball, or other type of pointing device, or a combination of devices used to input data into the computer200. The graphics adapter212displays images and other information on the display218. The network adapter216couples the computer200to the network202.

As is known in the art, the computer200is adapted to execute computer program modules. As used herein, the term “module” refers to computer-readable program instructions and/or data for providing the specified functionality. A module can be implemented in hardware, firmware, and/or software. In one embodiment, the modules are stored on the storage device208, loaded into the memory206, and executed by the processor202.

The computer system200is an example structure used for the devices illustrated inFIG. 1. However, it is noted that the types of computer systems200utilized by the entities ofFIG. 1may vary depending upon the embodiment and the processing power utilized by the entity. For example, a viewer client140that is a mobile telephone typically has a processor that may have limited processing power and a smaller display218. In contrast, a computer system200used as the broadcast management server120might have a processor with relatively greater processing power, but may lack a graphics adapter212, display218, and input device210.

Referring now toFIG. 3, it is a block diagram illustrating an example embodiment of a video capture system110. The video capture system110comprises one or more cameras302-1. . .302-n(collectively referenced herein as cameras302). Each camera302comprises a video capture unit304, a storage306, a communications interface308, and a universal clock310. The video capture unit304comprises components for capturing and processing video such as a lens, optical components, an image processor, and other conventional camera elements. The storage306is storage devices similar to storage device208. The storage device306stores the captured video data, metadata associated with video files, and/or other data used by the video capture system110. In various embodiments, the storage306can comprise internal camera memory, a removable memory card, an external storage unit, or a combination of storage mediums.

The communications interface308transmits the captured video to the broadcast management server120via the network150. In one embodiment, the communications interface308operates over a wireless protocol such as, for example, WiFi, WiMax, 3G/4G, and so on. Alternatively, the communications interface308can be configured to directly transfer video to the broadcast management server120using a wired interface such as, for example, a Universal Serial Bus (USB). In various embodiments, the communications interface308can be configured to stream captured video to the network150as it is being recorded (e.g., live streaming), or can transmit video at a later time after recording and storing a complete video file. In various embodiments, the communications interface308can be integrated with the camera body, or can be part of a removable expansion module that plugs into an existing camera. An example of a camera configuration with a removable expansion module is described in more detail in U.S. patent application Ser. No. 12/498,890 to Nicholas D. Woodman filed Jul. 7, 2009 entitled “Camera Housing with Integrated Expansion Module,” the contents of which is incorporated by reference herein.

The universal clock310maintains a universal time that can be read by the camera302to maintain time synchronization between captured videos. For example, the universal clock310may track a time standard such as Coordinated Universal Time (UTC). To compensate for potential drift between clocks310of the different cameras302, the clocks310can periodically re-synchronize to the time standard. This synchronization can occur, for example, via the network150at periodic intervals, or when the camera302is plugged into to a web-enabled computing device. In one embodiment, the camera302checks the universal clock310at predefined time intervals whenever it starts recording video. A timestamp indicating the capture start time is stored together with each recorded video file. The timestamp may correspond to a particular 24-hour clock start time, e.g., 4:32 pm, which can be further synchronized with another clock, such as a mobile phone tower clock, a GPS clock, or an atomic clock, for greater accuracy.

In an alternative embodiment, the universal clock can be an elapsed time from a particular event, such as, for example, the time the first camera in the video capture system110starts recording (i.e. the start of the broadcast). For example, a first camera of the video capture system110starts recording and a timestamp 0:00:00 (hh:mm:ss) is stored as a capture start time together with the first recorded video. A second camera starts recording 1 minute and 42 seconds later and a timestamp 0:01:42 is stored as a capture start time together with the second recorded video, indicating the elapsed time since the start of the broadcast. Other variations are also possible, but in each case, the universal clock310tracks and stores timing information such that the capture start times between the different cameras300of the video capture system110can be determined when the videos are transferred to the broadcast management server120. In embodiments where the broadcast management system100is only used for live streaming, the universal clock310may be absent from the video capture system110.

Next,FIG. 4is a block diagram illustrating an example embodiment of the broadcast management server120. The broadcast management server120comprises a broadcast manager interface module402, a video management module304, a broadcast viewer interface module406, a video database408, a broadcast map database410, and a user account database412. The components of the broadcast management server120are illustrated as functional modules for the purpose of clarity and convenience. In practice, the functional modules can be implemented in hardware, software, firmware, or a combination of these elements. For example, in one embodiment, the broadcast management server120comprises one or more computer readable-storage mediums (e.g., storage208) that stores computer-executable program code for carrying out the functions of the broadcast management server120. In operation, the program instructions are loaded from memory206and executed by a processor202to carry out the described functions.

The video database408stores video received from the video capture system110. Optionally, the video database408also stores broadcasts generated using the broadcast management system100. In one embodiment, video files in the video database408are stored in a storage, e.g., storage208, and indexed such that the video database408can be queried to find and retrieve videos. For example, videos may be indexed by author, event associated with the video, time, camera used, or other video characteristics.

The broadcast map database410stores “broadcast maps” for broadcasts created using the broadcast management system100. A broadcast map comprises a file that stores a sequence of instructions indicative of the timing of transitions between the different video files that are combined to create the broadcast. The broadcast map provides all the information needed to re-create a broadcast from a set of raw (or unedited) video files. Advantageously, if multiple broadcasts are created for the same event (using the same set of raw video files), the broadcast management server120need only store (e.g., in storage208) a new broadcast map for each broadcast instead of storing the entire broadcast video file. Examples of broadcast maps are described in further detail below.

The user account database412stores account information for users of the broadcast management system100. Account information can include, for example, a user profile, references to videos uploaded by the user, broadcasts created by the user, customized user settings, or other information associated with a particular user of the broadcast management system100. Typically, a broadcast manager user signs into his/her user account in the broadcast management system100prior to creating a broadcast. Viewers may also utilize a user account, for example, to customize search results or viewing preferences. In other embodiments, viewers can view public broadcasts without logging into any personal user account.

The broadcast manager interface module402provides tools that allow a broadcast manager user to create a broadcast using the broadcast management system100. For example, in one embodiment, the broadcast manager interface module402provides a web-based graphical interface (e.g., a website or web-based application) accessible by a web browser on the broadcast management client130. The broadcast manager interface module402allows a user to generate broadcasts from live streaming videos or videos in the video database408, manage or edit previously created broadcasts, or manage other information associated with the user's account. An example of a user interface provided by the broadcast manager interface module402is illustrated and described below with respect toFIG. 5.

The broadcast viewer interface module406provides tools that allow a user to find and view broadcasts using the broadcast management system100. For example, in one embodiment, the broadcast viewer interface module406provides a web-based graphical interface accessible by a web browser on the viewer client140. A user can search for broadcasts using, for example, a keyword search. Alternatively, the user can browse through all available broadcasts. Once a broadcast is selected for viewing, the broadcast viewer interface module406streams the video using, for example, an embedded video player, a pop-up video player, or other video viewing application viewable on the viewer client140.

The video management module404manages incoming videos and outgoing video broadcasts. For example, the video management module404interfaces with the video capture system110to receive raw videos and store the videos to the video database408. Furthermore, the video management module404interfaces with the broadcast manager interface module402to enable a broadcast manager user to create broadcasts from the raw videos, and provides the broadcasts to the broadcast viewer interface module406to stream to the client viewer140. In one embodiment, the video management module404creates a broadcast map for each broadcast based on input provided by the broadcast management client130.

FIG. 5is an example embodiment of a broadcast manager user interface500generated by the broadcast manager interface module402. The broadcast manager user interface500is, for example, a website, web-based application, or locally executed application that provides tools and controls for creating and streaming a video broadcast. In the example user interface500, a broadcast is created from four video streams of an event, typically corresponding to four different cameras. In different variations, any number of video streams can be included in the broadcast manager user interface500.

The broadcast manager user interface500includes multiple stream windows501, each displaying a different video stream (e.g., stream windows W1, W2, W3, and W4). Each video stream window501is synchronized in time, i.e., the various viewed streams displayed in each stream window501are played with the same relative timing as the videos were captured. A user can create a video broadcast by simultaneously viewing the multiple video streams as they are playing, and at any given time, selecting one of the video stream windows to broadcast. This feature allows the broadcast manager user to switch between the different cameras used to capture the event to create cuts from one camera to another in the broadcast. In one embodiment, the display includes an output preview window502that shows the currently selected stream window501. Thus, the video in the preview window502lets the broadcast manager user view the actual broadcast as it is being created.

In one embodiment, the broadcast manager user interface500includes a replay slider510for generating replays in the broadcast. The replay slider510comprises a timeline512and a sliding bar514. The timeline512represents a spectrum of time of the broadcast. For example, in one embodiment, the right end of the timeline512represents the current time (e.g., live time), and the left end of the timeline512represents the beginning of the broadcast. Alternatively, the left end of the timeline512can represent some fixed amount of time prior to the current time. For example, the timeline may represent the past 5 or 10 minutes of the broadcast. Generally, when no replay is being broadcasted, the sliding bar514is positioned on the right end of the timeline512indicating that the broadcast is live.

To invoke a replay, the broadcast manager user can slide the sliding bar514backwards on the timeline512to a desired point in time. The replay preview window518replays the broadcast beginning at the selected point in time. The broadcast manager user can use the preview window518to find the point in time for the desired replay prior to actually outputting the replayed video to the broadcast. When the broadcast manager user finds the right point in time, he/she can select the replay preview window518to output the replay to the broadcast. In one embodiment, a slow motion slider519can be used to create a slow motion replay. For example, the replay is played at full speed when the slider519is all the way up, and the replay speed decreases as the broadcast manager user slides the slider519lower. When the desired replayed portion is over, the broadcast manager user can return to live broadcasting by selecting the “Go Live” button516, or alternatively, sliding the sliding514back to the right end of the timeline512.

In one embodiment, the broadcast manager user interface500allows the broadcast manager user to add voiceover audio to the video broadcast using, for example, a microphone coupled to the broadcast management client130. The voiceover audio is streamed in real-time to the client viewer140together with the broadcast video. In this embodiment, the broadcast manager user interface500can include volume controls tools520. For example, the volume controls tools520can comprise a first volume slider522to control the volume level of the currently selected video stream window501and a second volume slider524to control volume of the voiceover audio.

Other embodiments of the broadcast manager user interface500can include different or additional tools and features for creating and managing a broadcast. For example, the interface500can provide additional tools similar to those found in traditional video editing software such as tools for controlling video contrast, brightness, color, etc. Additionally, the broadcast manager user interface500can provide tools to manage the user's account settings and/or place restrictions on who can view the broadcast. For example, the broadcast manager user can make the broadcast public to anyone who wants to view it, or can restrict viewing to subscribers only. In another embodiment, the broadcast manager user can choose to only store the broadcast to a file and make it available at a later time, rather than stream it live to viewer clients140.

The example provided above illustrates that a broadcast can be configured to be live, therefore manipulating the streams in real time (or “on the fly”) or may be configured for storage for subsequent manipulation of the streams to create a broadcast. Further, it may be configured to be a combination thereof, e.g., broadcast live with manipulation of streams in real time, but later broadcast using a different combination of saved video streams. In this latter example, an event viewed live from a first set of camera views can be experienced later from a second (or different) set of camera views, thereby giving a different perspective (or vantage point) of an event.

Operational Configurations

Turning now toFIG. 6, it illustrates a flowchart of one embodiment of a process for producing a broadcast of an event using the broadcast management system100. The video capture system110captures602video content of an event for broadcasting. In one embodiment, the captured video content comprises a set of n videos of the event (e.g., n comprising an integer value). Typically, each video comprising footage of a different aspect of the event or footage from a different location or camera angle. In one embodiment, each video file includes a timestamp indicating the capture start time of the video with respect to a universal clock, and an identifier identifying the specific camera on which the video was captured. The timestamp and identifier can be encoded as metadata associated with the video file, or can be encoded directly into the video file. For example, the information can be displayed in text on an initial frame of the video.

The video capture system110transmits604the n captured videos of the event to the broadcast management server120. In one embodiment, the captured videos are streamed to the broadcast management server120as the videos are being captured, e.g., in real-time or with a brief delay. Alternatively, video can be captured and stored locally (e.g., in storage306), and transferred to the broadcast management server120at a later time. For example, a user could transfer video files from storage306to a networked computing device, and then upload the video files to the broadcast management server120over the network150. In one embodiment, the video capture system110utilizes a video buffer to ensure that no data is lost in the event that the connection to the network150is disrupted while streaming.

The broadcast management server120receives606the set of captured videos of the event. In one embodiment, the broadcast management server120pre-processes608the received video files. Pre-processing may include preparing the video for further processing, for example, converting video files to a uniform file format, compressing the file in a particular format, adjusting the frame rate, resolution, color space, and the like. If the videos are received as a set of complete video files instead of a real-time stream, pre-processing608may also include time-synchronizing the video files. This time-synchronizing step extracts timestamps and camera identification information from the video files and generates a sequence of video load instructions that tell the broadcast management server120in which stream window501to display each video file and when to begin playback of each video file. This time-synchronization process allows the video files to be played back with the same relative timing as when they were captured, even when the video files have different start and end times. An example of the time synchronization process is described in more detail below with respect toFIG. 7. In some embodiments where the broadcast management server120receives608the video streams in real-time, the pre-processing step can be omitted.

The broadcast management server120generates610the broadcast management user interface (e.g., the user interface500ofFIG. 5) and provides the display to the broadcast management client130. The broadcast management client130displays618the captured videos in a time-synchronized manner using the broadcast manager interface500. During playback of the videos, a broadcast manager user can simultaneously view all the video streams, and at any given time, select one of the streams for broadcasting. Thus, the broadcast manager user can switch between the different cameras used to capture the event. The broadcast management client130processes620the broadcast decisions entered by the broadcast manager user (e.g., which video to broadcast at any given time). The broadcast management client130transmits the decisions to the broadcast management server120.

The broadcast management server120receives612the broadcast decisions and generates614the broadcast based on the decisions. The broadcast management server120stores the broadcast management decisions to the broadcast map. The broadcast map stores all of the broadcast decisions in such a way that the broadcast can be completely recreated from the original video files by applying the broadcast map. For example, in one embodiment, the broadcast map includes an entry every time the broadcast manager user switches the selection of the video for broadcasting from the multiple stream windows501. In one embodiment, for example, each entry in the broadcast map includes a timestamp indicating how far into the broadcast the selection occurred, and an identifier referencing which video was selected. In one embodiment, the broadcast management server120also stores voiceover audio together with the broadcast map for the broadcast so that the broadcast can be recreated at a later time.

In one embodiment, the broadcast map is formatted as a set of instructions that allow the broadcast management server120to recreate the broadcast at a later time. For example, in one embodiment, a broadcast timer starts at the beginning of the broadcast to track how much time has elapsed. After a time period t1has elapsed, the broadcast manager user selects stream window W1, which is playing a video file V1and is at a frame F1when the selection occurs. The broadcast management server120stores an instruction to the broadcast map indicating that at an elapsed time t1from the start of the broadcast, load a video file V1beginning at frame F1. Additional broadcast map instructions may indicate, for example, at an elapsed time t2into the broadcast, load video file V2beginning at frame F2; at elapsed time t3, load video file V3beginning at frame F3, and so on.

In an alternative embodiment, the broadcast management server120stores only the elapsed time into the broadcast and the video file identifier. In this embodiment, the beginning frame can be computed from the elapsed time into the broadcast and the capture start time stored with the video file. In other alternative embodiments, the broadcast management server120can store a time into the video file (e.g., 25 seconds into the video) instead of a frame number.

The broadcast map may also include other instructions associated with the broadcast. For example, at time T4change the voiceover volume to a volume level L, etc. In general, each action made by the broadcast manager user while creating the broadcast is stored to the broadcast map in the form of an instruction that can later be used to completely recreate the broadcast from the raw video files.

In one embodiment, more than one broadcast can be created from the same set of raw video files. For example, different broadcast manager users can each create their own personal broadcast of an event from the same set of video files, or one broadcast manager user can create more than one broadcast. Each broadcast is stored as a separate broadcast map that specifies the transitions between video streams such that the broadcast can be completely recreated by applying the broadcast map to the raw video files. Beneficially, the broadcast management system100need not store a new video file for each broadcast that is created. Instead only the initial set of raw videos (e.g., unedited videos) are stored, and only a new broadcast map is stored for each created broadcast. This storage configuration is beneficial because the broadcast map would require far less storage space than a full video file. The broadcast map could be implemented, for example, as a small text file storing the set of broadcast decisions.

The viewer client140displays622the broadcast viewer interface. The viewer client624receives a selection of a broadcast for viewing and displays626the selected broadcast. In various embodiments, viewers can view “live” broadcasts streamed in real-time as they are created by the broadcast management system100, or the user can view past broadcasts stored by the broadcast management system100. A process for replaying a previously created broadcast is described below with respect toFIG. 8.

FIG. 7illustrates an example of a technique for pre-processing a set of video files so that they can be broadcasted in a time-synchronized manner. This technique can be applied when a broadcast manager user wants to create a broadcast from previously captured video files of an event. In this example, the broadcast management server120receives a set of video files from four different cameras (CAM1, CAM2, CAM3, and CAM4). Multiple video files can be received from a single camera. This occurs because cameras typically store a separate video file for each continuous stream of captured. For example, a camera may record video continuously for a first time period, stop recording for a second time period, and record continuously again for a third time period. The videos from the first and third time periods are typically stored as separate video files, while no data is stored during the second time period when the camera is not recording. In the example ofFIG. 7, the broadcast management server120receives four different video files from CAM1, one video file from CAM2, two different video files from CAM3, and one video file from CAM4.

Each stored video file Vfile1-VfileN includes metadata indicating an identifier of the camera from which the video originated (e.g., CAM1, CAM2, CAM3, CAM4) and a timestamp indicating a capture start time when the video recording started (e.g., t0, t1, t2. . . ). For example, video file Vfile1was recorded on CAM1starting at a capture start time t0, Vfile2was recorded on CAM1starting at a capture start time t2, and so on. During pre-processing, the broadcast management server120extracts the metadata from the video files and generates a set of video file load instructions. These instructions indicates a replay start time when a particular video file should be loaded to the broadcast management user interface500, and to which stream window501the video file should be loaded. For example, at a replay start time t0, the broadcast management server120begins playback of Vfile1in stream window W1and simultaneously begins playback of VfileS to stream window W2, at replay start time t1, the broadcast management server120begins playback of Vfile6to stream window W3, and so on. Accordingly, the process enables synchronized display of the multiple video streams to allow a user to create a broadcast.

In one embodiment, the broadcast management server120displays a predefined default display in a stream window501when no video is currently playing. For example, in the example above, CAM3has no video footage between time t0and t1. During this time, the broadcast management server120displays the default display in the stream window W3. Similarly, if there is a time gap between the end of a first video file and the start of a second video file, the broadcast management server120displays the default display in the appropriate stream window501. In one embodiment, the default display screen simply comprises a black screen. In another embodiment, the default screen can include a message such as, for example, “No video available.”

FIG. 8illustrates an embodiment of a process performed by the broadcast management server120for replaying a broadcast to a viewer client140that has previously been created and stored as a broadcast map. The broadcast management server120receives802a selection of a previously stored broadcast for viewing on a viewer client140. The broadcast management server120retrieves the broadcast map associated with the selected broadcast from the broadcast map database410. The broadcast management server120executes806the first instruction in the broadcast map. For example, the instruction may specify loading a particular video file beginning at a particular time point or frame number within the video file. The broadcast management server120also starts a timer to track the amount of time progressed into the broadcast. The broadcast management server120then waits808until the time that the next instruction in the broadcast map is reached and executes810the instruction. Steps808,810then repeat812until the broadcast is complete.

FIG. 9is a flowchart illustrating one embodiment of a process for operating the video capture system110according to one embodiment. In this example process, the video capture system110is configured to operate over a wireless data network150(e.g., a cellular network). The communications interface308can be turned on902(or off) with a button, for example, or it could be turned on automatically when the camera302is turned on. When the camera302and communications interface308are turned on, the communications interface308connects904to the network150. The camera302begins recording906. While recording, the camera302can either stream910the captured video to the broadcast management server120via the communications interface308, store910the video locally to storage306, or both. In one embodiment, the streamed and/or stored video data includes an indication of a specific broadcast management account to associate with the streamed data so that the user can later retrieve the files. The streamed and/or stored video data also includes an identifier identifying the camera302and a timestamp indicating the start time of the video recording.

When the user presses a “stop” button on the camera302to stop912recording, the video data in storage306is saved as a video file. Similarly, the broadcast management server120stores any streamed video data to a video file on the server120. The saved video files are then accessible when the user logs in to his broadcast account on the broadcast management website.

If the communications interface308loses its connection to the data network150, the camera302can buffer recorded video to storage306until the connection is re-established. Once re-established, the communications interface308transmits the buffered data to the broadcast management server120. Alternatively, if no data network150is available, or if the user chooses not to live stream the data, the entire video can be stored to storage306, and the user can later upload the files to the broadcast management server120using the communications interface308or via a web interface.

The described embodiments beneficially provide a broadcast management system100(and method) that allows a user to store or stream a plurality of videos of an event, and create a broadcast of the event from the videos. By using multiple video streams, the broadcast management system100can create broadcasts that include multiple camera views. Unlike professional broadcast systems, which are limited to managing live video feeds, one embodiment of the broadcast management system100allows a user to create a broadcast from previously recorded video files. By time-stamping video files relative to a universal clock, the broadcast management system100can subsequently resynchronize the video files, and replay the videos concurrently to a broadcast management user interface500that allows a user to easily create a broadcast by selecting between videos as they are being replayed. Furthermore, unlike professional broadcast systems, an embodiment of the broadcast management system100provides a user-friendly web-based interface for managing and/or viewing broadcasts.