Method and system for peer-to-peer operation of multiple recording devices

In an embodiment, a method includes receiving a first status message from a first recording device. The first status message includes a first recording identifier. The method further includes determining to initiate a second recording on a particular recording device based, at least in part, on the first status message and configuration settings. In addition, the method includes initiating a second recording on the particular recording device. Furthermore, the method includes creating a second recording identifier. The method also includes storing information related to the first recording identifier and the second recording identifier in a metadata file. Additionally, the method includes transmitting a second status message for receipt by other recording devices. The second status message includes the second recording identifier.

BACKGROUND

Technical Field

The present disclosure relates generally to media capture and more particularly, but not by way of limitation, to systems and methods for peer-to-peer operation of multiple recording devices.

History of Related Art

It has recently become desirable to record video and audio of encounters between police and members of the public. For example, video and/or audio recordings of a traffic stop by an officer may be recorded by one or more cameras and microphones associated with the officer's car. In some instances, video and audio recordings are also collected from an officer's vantage point by a device associated with the officer. For example, a camera device may be attached to the officer to record what the officer sees and hears. As the number of recording devices increases, the complexity and difficulty to obtain relevant portions of video and audio recordings from all of the available devices also increases.

SUMMARY OF THE INVENTION

In an embodiment, a method is performed by a particular recording device in a peer-to-peer recording system comprising a plurality of networked recording device. The method includes receiving a first status message from a first recording device of the plurality of networked recording devices. The first status message includes an indicator of a decision by the first recording device to initiate a first recording and a first recording identifier that is specific to the first recording. The method further includes determining to initiate a second recording on the particular recording device based, at least in part, on the first status message and configuration settings stored in memory on the particular recording device. The configuration settings include a parameter related to whether the particular recording device will participate in group event recording. In addition, the method includes initiating a second recording on the particular recording device responsive to the determining. Furthermore, the method includes creating a second recording identifier that is specific to the second recording. The method also includes storing information related to the first recording identifier and the second recording identifier in a metadata file for the second recording. Additionally, the method includes transmitting a second status message for receipt by other recording devices of the plurality of networked recording devices. The second status message includes an indicator of a decision by the particular recording device to initiate the second recording and the second recording identifier.

In one embodiment, a network device includes a computer processor and memory such that the computer processor and memory in combination are operable to implement a method. The method includes receiving a first status message from a first recording device of a plurality of networked recording devices. The first status message includes an indicator of a decision by the first recording device to initiate a first recording and a first recording identifier that is specific to the first recording. The method further includes determining to initiate a second recording on the network device based, at least in part, on the first status message and configuration settings stored in memory on the network device. The configuration settings include a parameter related to whether the network device will participate in group event recording. In addition, the method includes initiating a second recording on the network device responsive to the determining. Furthermore, the method includes creating a second recording identifier that is specific to the second recording. The method also includes storing information related to the first recording identifier and the second recording identifier in a metadata file for the second recording. Additionally, the method includes transmitting a second status message for receipt by other recording devices of the plurality of networked recording devices. The second status message includes an indicator of a decision by the network device to initiate the second recording and the second recording identifier.

In one embodiment, a computer-program product includes a non-transitory computer-usable medium having computer-readable program code embodied therein. The computer-readable program code is adapted to be executed to implement a method on a particular recording device in a peer-to-peer recording system comprising a plurality of networked recording devices. The method includes receiving a first status message from a first recording device of the plurality of networked recording devices. The first status message includes an indicator of a decision by the first recording device to initiate a first recording and a first recording identifier that is specific to the first recording. The method further includes determining to initiate a second recording on the particular recording device based, at least in part, on the first status message and configuration settings stored in memory on the particular recording device. The configuration settings include a parameter related to whether the particular recording device will participate in group event recording. In addition, the method includes initiating a second recording on the particular recording device responsive to the determining. Furthermore, the method includes creating a second recording identifier that is specific to the second recording. The method also includes storing information related to the first recording identifier and the second recording identifier in a metadata file for the second recording. Additionally, the method includes transmitting a second status message for receipt by other recording devices of the plurality of networked recording devices. The second status message includes an indicator of a decision by the particular recording device to initiate the second recording and the second recording identifier.

DETAILED DESCRIPTION

Various embodiments of the present disclosure will now be described more fully with reference to the accompanying drawings. The invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein.

FIG. 1illustrates an example of a distributed multi-peer recording-device management system100. The system100is adapted to enable recording of an event by one or more recording devices. As used herein, an event describes a period of time that is recorded by one or more recording devices of the system100. An event may be, for example, a traffic stop by an officer, a high-speed pursuit of a suspect, an interview of a suspect or witness, a stakeout, surveillance, and the like. In some embodiments, the system100facilitates creation of a group recording of an event. As used herein, a group recording, or group event recording, is a collection of audio and/or video recordings created by two or more recording devices of the system100. For example, a group recording may include audio and/or video recordings from a recording device worn by an officer, a recording device installed in a police vehicle, a recording device in an interrogation room, a recording device positioned for a stakeout, a recording device positioned for surveillance, and the like.

In a typical embodiment, the system100includes a base system101and one or more mobile devices102, mobile devices102(1) and102(2) being explicitly shown. In a typical embodiment, the base system101is installed in a vehicle. When the base system101is installed in a vehicle, the base system101may include an audio/video recording system104, a mobile device base106, a switch108, and a radio110. In some embodiments, the audio/video recording system104may be omitted. The radio110enables the system100to communicate with other systems. For example, the radio110may communicate with a system112via a wireless network111. The system112may be, for example, a police station or another vehicle. Communication between the audio/video recording system104and the mobile device base106may be facilitated by the switch108. The switch108may be, for example, a power over Ethernet (POE) switch that provides power to the mobile device base106.

In a typical embodiment, the base system101is installed in a vehicle, such as, for example, a police car. In other embodiments, the base system101may be used without a vehicle. For example, the base system101may be used in a police station (e.g., in an interrogation room), as part of a remote base of operations (e.g., a temporary police presence at a public gathering, such as, for example, a parade, a fair, and the like), and the like. As shown inFIG. 1, the system100includes the mobile device102(1) and the mobile device102(2). In some embodiments, the system100may include one mobile device102. In some embodiments, the system100may include mobile devices102(1)-102(n). In some embodiments, one or both of the mobile devices102(1) and102(2) may be docked with the mobile device base106while not in use. In a typical embodiment, docking the mobile devices102(1) and102(2) enables the devices to be charged, to receive updates to a configuration file, and to transfer files to and from the audio/video recording system104. In a typical embodiment, one or more of the mobile devices102(1) and102(2) may be removed from the mobile device base106to position the mobile devices102(1) and102(2) for the capture of audio and/or video at a location remote from the base system101. For example, the mobile device102(1) or102(2) may be worn by a police officer to capture audio and/or video from the officer's perspective. In some embodiments, the mobile device102may be positioned for surveillance, in which case the mobile device102may not be worn by an officer.

In some embodiments, the mobile devices102(1) and102(2) communicate via a wireless network103. In a typical embodiment, the wireless network103is separate from the wireless network111used by the radio110. Separating the wireless network103from the wireless network111can serve to increase the security of communications between the mobile devices102(1) and102(2). In some embodiments, the wireless network103is “undiscoverable” to recording devices unless a recording device has been preprogrammed with information that allows the recording device to connect to the wireless network103. For example, in some embodiments, to connect each of the mobile devices102(1) and102(2) to the wireless network103, each of the mobile devices102(1) and102(2) must be preprogrammed with appropriate network information, credentials, certificates, and the like. In some embodiments, the mobile devices102(1) and102(2) may be programmed with the appropriate network information by docking the mobile devices102(1) and102(2) in the mobile device base106.

In a typical embodiment, the radio110is coupled to the switch108to enable communication between the system112, the audio/video recording system104, and each of the mobile devices102(1) and102(2). In some embodiments, each of the mobile devices102(1) and102(2) may communicate with the system112by sending messages to the mobile device base106, which messages are then routed to radio110via the switch108. In some embodiments, the system100may not include the switch108. In such an embodiment, the radio110may instead be directly coupled to the audio/video recording system104or the mobile device base106.

In a typical embodiment, the system100is adapted to enable each recording device of the system100to send and receive status messages to and from other recording devices within the system100and to facilitate identification of group recordings. An example of a recording device will be described in greater detail with respect toFIG. 3. In general, the recording devices of the system100can include the one or more mobile devices102and the audio/video recording system104. A status message can be a communication sent by a recording device within the system100to inform other recording devices within the system100about a current status of the recording device that sent the status message. Status messages may be configured as desired to include various information about a condition or a status of a recording device. In a typical embodiment, a status message may include one or more of the following types of information: recording status (e.g., “on” or “off,” recording duration), a unique recording identifier that provides a unique tag for each video recording made by the system100, global positioning system (GPS) location information, battery level, memory availability, device status (e.g., operational, malfunctioning), last-heard-from (LHF), and the like. In some embodiments, LHF includes a time stamp or the like to track when a recording device of the system100last communicated with another recording device in the system100.

In a typical embodiment, each time a recording device within the system100receives a status message, the status message is analyzed. In a typical embodiment, the status message is analyzed to determine if a change to a recording status of the recording device that received the status message should be made (i.e., start recording, continue recording, or stop recording). Status messages are not themselves instructions for a recording device within the system100to begin, continue, or stop recording. Instead, each recording device within the system100analyzes a received status message as a part of its determination regarding whether or not to make a change to its recording status. In a typical embodiment, when a recording device within the system100receives a status message, the recording device analyzes the received status message and uses its own logic tree to determine whether any action should be taken in response to the status message, such as, for example, whether recording should be initiated, continued, or stopped. A logic tree of a given recording device can represent conditions under which that recording device will change its recording status. In some cases, the logic tree can be expressed using software, parameters of a stored configuration file, a combination of the foregoing, and/or the like. Examples of the logic tree will be described in greater detail with respect toFIGS. 2A-Band3. In some embodiments, the status message may be analyzed to make additional determinations, such as, for example: if an alert should be sent to other recording devices in the system100(e.g., an officer needs assistance), if GPS location information should be shared with other recording devices in the system100(e.g., location information may be shared to alert users of the system100as to the location of officers during a pursuit to help prevent friendly fire incidents and the like), and the like.

In a typical embodiment, each mobile device102of the system100is adapted to record audio and/or video of an event. In a typical embodiment, each mobile device102includes various modules and systems to enable recording of at least one of audio and video. For example, in some embodiments, the mobile devices102may include: a processor such as a central processing unit (CPU), memory, a camera module, an audio module, a radio module, battery module, GPS module, accelerometer and one or more input buttons.

In a typical embodiment, the processor of each of the mobile devices102is adapted to control operation of the mobile device102. For example, the processor may control one or more of a camera module, audio module, radio module, battery module, and GPS module. The processor is also adapted to read and write to the memory. In various embodiments, the memory may include volatile and/or non-volatile memory. For example, the memory may include SD cards, hard disk drives, EEPROM, flash memory, and the like. The memory may be used to store captured audio and/or video data. The memory module may also store various software modules and configuration files for the operation of the mobile device102. For example, the memory may include a device-specific configuration file that is interpreted by the processor to make decisions based upon status messages received from other recording devices in the system100.

In a typical embodiment, each of the mobile devices102(1) and102(2) is configured to communicate via its radio module with each of the other recording devices associated with the system100. In a typical embodiment, each of the mobile devices102(1) and102(2) is configured to send status messages regarding changes to its status/operating state and to receive status messages from other recording devices within the system100. For example, in a typical embodiment, when the mobile device102(1) becomes visible to the mobile device base106(e.g., when the device is powered on after being powered off or comes into range of the mobile device base106), the mobile device102(1) sends a status message via its radio module to the other devices in the system100to inform the other recording devices that the mobile device102(1) is online. Other changes to operating status that result in the mobile devices102(1) and102(2) sending status messages include, for example, information that a mobile device102has started recording, stopped recording, a low battery, low memory, an operating fault, a user has indicated that assistance is needed, and the like. In other embodiments, each of the mobile devices102(1) and102(2) may be configured to send status messages as desired.

In some embodiments, communication between the mobile devices102(1) and102(2) is facilitated by the mobile device base106. For example, the mobile device102(1) may send a status message to other devices of the system100via the radio module of the mobile device102(1). The status message may be received by the mobile device base106, which then relays the status message via a radio module of the mobile device base106to the mobile device102(2) and/or other devices associated with the system100. For example, in some embodiments, the mobile device base106may also relay the status message to the audio/video recording system104and/or the system112.

In some embodiments, communication between the mobile devices102(1) and102(2) may be direct (i.e., the mobile devices102(1) and102(2) may communicate with each other without relaying messages through the mobile device base106). For example, each of the mobile devices102(1) and102(2) may pass messages directly to each other using its radio module. Wireless networks, such as, for example, ad hoc, Wi-Fi direct, Bluetooth, and the like may be used to enable direct communication between the mobile devices102(1) and102(2).

In some embodiments, status messages may be communicated through each of the mobile devices102(1) and102(2) in a daisy-chain or multi-hop network arrangement. For example, if the mobile device102(1) has lost communication with the mobile device base106(e.g., the mobile device102(1) has moved too far away from the mobile device base106, the radio signal is too weak, the radio signal is blocked or obstructed, etc.), the mobile device102(1) will lose communication with the mobile device base106. However, if the mobile device102(2) is positioned such that the mobile device102(2) can communicate with both the mobile device102(1) and the mobile device base106, status messages may be relayed or daisy-chained between the mobile device102(1), the mobile device102(2), and the mobile device base106, effectively increasing a communication range of the mobile device102(1).

In some embodiments, the mobile device base106periodically monitors the wireless network103to keep track of devices that are connected to the wireless network103. For example, the mobile device base106may monitor the wireless network103to confirm that each of the mobile devices102(1) and102(2) is still in range/communication with the mobile device base106. In a typical embodiment, the mobile device base106uses LHF information to keep track of the last time a particular device was heard from. In some embodiments, each of the mobile devices102(1) and102(2) monitors its own connection status to confirm if its connection to the wireless network103is still active.

In some embodiments, each of the mobile devices102(1) and102(2) may be able to communicate with additional mobile devices associated with a second distributed multi-peer recording-device management system (not shown). For example, the base system101may be installed in a first car and the second system may be installed in a second car or may be a part of a remote base of operations. When the mobile devices102(1) and102(2) are in communication range with mobile devices from the second system, one or both of the mobile devices102(1) and102(2) can communicate with the mobile devices from the second system or a mobile device base of the second system. For example, such communication may occur directly between each of the mobile devices, may be routed via the mobile device base106or the device base of the second system, or via a combination of these communication methods.

The mobile device base106may include one or more docking ports to receive each of the mobile devices102(1) and102(2). The one or more docking ports may serve several purposes. For example, the one or more docking ports may act as a power source for recharging each of the mobile devices102(1) and102(2). The one or more docking ports may also be able to initialize or program each of the mobile devices102(1) and102(2). For example, when the mobile device102(1) is docked in one of the one or more docking ports, the mobile device base106can transfer configuration information to the mobile device102(1). In some embodiments, the configuration information includes information regarding the wireless network (e.g., network identifier (ID), Internet Protocol (IP) addresses, credentials, a list of other devices associated with the network that the mobile devices can communicate with, and the like) that is used to enable communication between the mobile device102(1), the mobile device102(2), and the mobile device base106. In some embodiments, some or all of the configuration information for each of the mobile devices102(1) and102(2) may be performed by a docking or transfer station that is outside of the system100. For example, a docking or transfer station may be housed in a police station. When a user receives a mobile device102for use, the mobile device102may first be docked with the docking or transfer station to upload a configuration file for that user. The configuration file may be customized for each user or may be a default configuration for all users. For example, each user in a unit or squad may use the same configuration file.

In some embodiments, docking the mobile devices102with the mobile device base106permits the mobile device102to connect directly with an event library to upload recordings stored on the mobile device102. The event library is a central storage repository for recordings captured by recording devices of the system100. In a typical embodiment, the event library comprises one or more storage devices, such as, for example, hard drives and the like. In a typical embodiment, the event library is located at a police station. In other embodiments, the event library may reside, for example, in the audio/video recording system104, in the system112, in cloud storage, and the like. In some embodiments, the event library may be a stand-alone device. In a typical embodiment, the event library may include recordings from a single system100, a squad comprising more than one system100, each system100associated with a police station, and the like. Recordings may be uploaded to the event library in various ways. For example, recordings may be uploaded from the system100when the system100is in wireless communication range with the event library. In other embodiments, the system100may be connected to the event library via a cable to transfer recordings.

In a typical embodiment, when a recording is made by the mobile device102(1), the mobile device102(2), or the audio/video recording system104, a unique recording identifier is created by the recording device and associated with the recording. In a typical embodiment, the unique recording identifier includes information that is unique to the recording device that made the recording. For example, the unique recording identifier may include the recording device's serial number, media access control (MAC) address, and the like. The unique recording identifier enables someone browsing the event library to access a specific recording so that, at a later time, the specific recording can be coordinated/synchronized with other recordings from a group recording. In a typical embodiment, each recording includes a metadata file that includes various metadata regarding the recording. For example, the metadata file may include the unique recording identifier, information that identifies which recording device made the recording, information that identifies other recording devices that were in communication with the device that made the recording, and the like. The information from the metadata file can be used by the event library to associate each recording from a group recording together so that the entire group recording can be recalled at a later time.

In a typical embodiment, each of the mobile devices102(1) and102(2) determines whether or not to start recording, continue recording, or stop recording by following its own logic tree. In some embodiments, each of the mobile devices102(1) and102(2) makes such a determination each time a new status message is sent and/or received. In some embodiments, each of the mobile devices102(1) and102(2) makes such a determination periodically (e.g., not necessarily in response to sending or receiving a status message). In some embodiments, each of the mobile devices102(1) and102(2) makes such a determination in response to a change in its own status. For example, a mobile device102may determine that recording should be stopped when the mobile device102determines that a battery level is low, when storage is running low, and the like.

In a typical embodiment, the audio/video recording system104is a system for recording video and/or audio relating to an event. A typical audio/video recording system104includes a processor such as a CPU, memory, at least one recording device to capture audio and/or video, and at least one sensor. In a typical embodiment, the one or more sensors may include: siren status, light bar status, vehicle speed, auxiliary sensor status (e.g., removal of a weapon from a weapon rack), actuation of a manual record button, and the like. In a typical embodiment, the audio/video recording system104may use various criteria to determine when an event has begun or ended. For example, the criteria may include information from one or more sensors or analysis of a status message that was received from one of the mobile devices102(1) and102(2).

Once the audio/video recording system104has determined that an event has begun, an additional determination is made by the audio/video recording system104to decide whether or not to begin recording audio and/or video of the event. In a typical embodiment, the audio/video recording system104uses its logic tree to determine whether or not to record. For example, if the event is a traffic stop, the audio/video recording system104may use the light bar status as the criteria to recognize that the traffic stop has begun. The audio/video recording system104then determines if recording should begin. The determination of whether or not to record the event is based upon an analysis of the logic tree of the audio/video recording system104. The logic tree may be configured as desired. Illustrative logic to begin a recording includes: start recording if storage is not full; start recording if camera is operational; and the like. If a recording is begun by the audio/video recording system104, a determination to stop recording is similarly made by the audio/video recording system104by following its logic tree. Illustrative logic to stop a recording includes: stop recording if an officer manually indicates that the recording should be stopped; stop recording if camera is not operational; stop recording if storage is full; and the like.

In a typical embodiment, the audio/video recording system104sends out a status message in response to a change in the audio/video recording system104's status/operating state. For example, a status message may be transmitted in response to a change in status of one or more of the sensors, a change of the audio/video recording system104's recording status, and the like. In other embodiments, the audio/video recording system104may be configured to transmit status messages as desired.

In some embodiments, the audio/video recording system104is always recording (e.g., to a buffer in either volatile or non-volatile memory). In such an embodiment, the audio/video recording system104marks the beginning of an event with a start flag. An end of the event is marked with an end flag. By marking a recording with start and end flags, it is possible to identify and extract only the portion of the audio/video recording system104's recorded video that relates to the event for uploading to the event library.

In various embodiments, the radios and radio modules described above may be any of various known types of wireless communication devices. For example, the radios and radio modules may use Wi-Fi, Bluetooth, cellular, satellite, and the like.

Referring now toFIGS. 2A and 2B, an illustrative message sequence of a distributed multi-peer device management system200is shown.FIG. 2Bis a continuation of the illustrative message sequence that begins inFIG. 2A. The system200includes a mobile device202(1), a mobile device202(2), an audio/video recording system204, an officer230, and an officer231. In the embodiment shown inFIGS. 2A and 2B, the system200does not include a mobile device base. It should be understood that the system200could be modified to include a mobile device base without departing from the principles of the invention.

The illustrative message sequence ofFIGS. 2A and 2Bshows a scenario where the mobile device202(1) is the first device to record. The message sequence begins when the officer230presses a record button on the mobile device202(1). The message sequence would be similar for other scenarios where the mobile device202(1) was the first to record, such as, for example, if the mobile device202(1) began recording in response to a decision based on its internal logic tree. When the record button of the mobile device202(1) is pressed, a status message240is created by the mobile device202(1). The status message240may include a variety of information regarding a status of the mobile device202(1). For example, the status message240may include an identification of the message sender, recording status (e.g., “on” or “off,” recording duration), a unique recording identifier, device location, battery level, memory availability, device status (e.g., operational, malfunctioning), LHF, time information (e.g., a timestamp, time information from GPS data), GPS location information, and the like.

After the status message240has been created by the mobile device202(1), the status message240is transmitted by a radio module of the mobile device202(1). The transmitted status message240is then available to be received by other devices associated with the system200. For example, as shown inFIG. 2A, the transmitted status message240is received by the audio/video recording system204and the mobile device202(2). In some embodiments, a device that receives a status message may send an acknowledgement to the device that sent the status message for each status message that is received (not shown).

Each device that receives the status message240analyzes the status message240to determine if, based on an internal logic tree of the receiving device, a change to its recording status should be made. For example, as shown inFIG. 2A, the audio/video recording system204analyzes the status message240at step241and decides to begin recording at step242. Similarly, at step243, the mobile device202(2) analyzes the status message240and determines at step244that a recording should be started. In other scenarios, the audio/video recording system204and/or the mobile device202(2) may decide not to record based on its logic tree. In some embodiments, in response to a decision to record, the mobile device202(1) and/or the mobile device202(2) can perform additional processing to determine whether local conditions thereon, such as insufficient memory or a low battery level, should at least temporarily override the recording decision. Examples of the additional processing will be described in greater detail with respect toFIG. 5.

In response to the decision by the audio/video recording system204to begin recording, a status message245is created by the audio/video recording system204and transmitted to the mobile device202(1) and the mobile device202(2) to inform the mobile device202(1) and the mobile device202(2) that the audio/video recording system204has begun recording. Similarly, the mobile device202(2) creates and transmits a status message250to inform the audio/video recording system204and the mobile device202(1) that the mobile device202(2) has begun recording. In a typical embodiment, the status messages245and250are created and sent by the audio/video recording system204and the mobile device202(2), respectively, substantially simultaneously.

At step246, the mobile device202(1) analyzes the status message245to determine, using its internal logic tree, whether a change to its recording status should be made. At step247, the mobile device202(1) decides to continue recording. Similarly, at step248, the mobile device202(2) analyzes the status message245to determine whether a change to its recording status should be made. At step249, the mobile device202(2) decides to continue recording. In other scenarios, the mobile device202(1) and/or202(2) may decide to stop recording based on its logic tree as that tree is expressed in software and/or configuration file settings. At step251, the mobile device202(1) analyzes the status message250. At step252, the mobile device202(1) decides, using its internal logic tree, to continue recording. Similarly, at step253, the audio/video recording system204analyzes the status message250. At step254, the audio/video recording system204decides to continue recording. In other scenarios, the mobile device202(1) and/or the audio/video recording system204may decide to stop recording based on its logic tree.

In a typical embodiment, subsequent to steps252and254, the mobile device202(1), audio/video recording system204, and the mobile device202(2) create status messages255,256,257, respectively. The status message255is transmitted to the audio/video recording system204and the mobile device202(2). The status message256is transmitted to the mobile devices202(1) and202(2). The status message257is transmitted to the mobile device202(1) and the audio/video recording system204. The status messages255,256, and257are summary reports that provide up-to-date information regarding the status of the sender of the message. For example, the status message255provides the audio/video recording system204and the mobile device202(2) with information regarding the current status of the mobile device202(1) and also resends the status information regarding the audio video/recording system204and the mobile device202(2) that was previously sent to the mobile device202(1) by the audio video/recording system204and the mobile device202(2), respectively. By resending the last reported status of the mobile device202(2) and the audio/video recording system204to the mobile device202(2) and the audio/video recording system204, each of the mobile device202(2) and the audio/video recording system204can independently confirm that the information is up-to-date and current. Such a confirmation is particularly useful when a device has gone out of range of the system200and then comes back into communication range with the system200. When a device that has lost communication with the system200regains communication with the system200, status messages, such as the status messages255,256, and257, provide an up-to-date summary report of the status of the other devices in the system200. Once the up-to-date information has been received by a device that has regained communication with the system200, that device can reevaluate whether or not it should be recording. In some embodiments, when a new status message is received by a device, the device can compare its current status information to the status information contained in the status message. If the status information is incorrect, the device can send out an updated status message to correct the information. In this way, the system200uses status messages to “self-heal.”

Continuing on toFIG. 2B, the officer231has pressed a button to stop the mobile device202(2) from recording. Stopping the mobile device202(2) from recording results in a change to the status of the mobile device202(2), which further results in the mobile device202(2) creating a status message258that is transmitted to the mobile device202(1) and the audio/video recording system204. At step259, the mobile device202(1) analyzes the status message258. At step260, the mobile device202(1) decides, using its internal logic tree, to stop recording, which further results in the mobile device202(1) creating a status message263that is transmitted to the mobile device202(2) and the audio/video recording system204. Similarly, at step261, the audio/video recording system204analyzes the status message258. At step262, the audio/video recording system204decides to continue recording, which further results in the audio/video recording system204creating a status message264that is transmitted to the mobile device202(1) and the mobile device202(2). In other scenarios, the mobile device202(1) may decide to continue recording and the audio/video recording system204may decide to stop recording.

In the embodiment ofFIGS. 2A and 2B, the outcomes of the various analysis steps are dependent upon each device's particular configuration settings and operating status. It should be understood that the various decisions above by the mobile device202(1), the mobile device202(2), and the audio/video recording system204to begin recording, continue recording, or stop recording could have different outcomes based upon different configuration settings or operating status. For example, if in step243the mobile device202(2) determines that its battery level is low, the mobile device202(2) may instead decide not to record or to enter a holding state as described in greater detail with respect toFIG. 5.

Although not shown inFIGS. 2A and 2B, it should be understood that each time the mobile device202(1), the mobile device202(2), and the audio/video recording system204receive a status message, the mobile device202(1), the mobile device202(2), and the audio/video recording system204may make other determinations in addition to determining whether to make a change to its recording status. For example, in response to receiving a status message, one or more of the mobile device202(1), the mobile device202(2), and the audio/video recording system204may determine whether or not to send out an alert that an officer needs assistance or may share GPS location information. Various other determinations could be incorporated into a device's configuration file as desired.

FIG. 3illustrates an example of a recording device322. The recording device322can be implemented, for example, as one of the mobile devices102and/or the audio/video recording system104ofFIG. 1. The components of the recording device322may comprise any suitable physical form, configuration, number, type and/or layout. As an example, and not by way of limitation, the recording device322may comprise an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a wearable or body-borne computer, a personal digital assistant (PDA), a server, or a combination of two or more of these. Where appropriate, the recording device322may include one or more computer systems; be unitary or distributed; span multiple locations; span multiple machines; or reside in a cloud, which may include one or more cloud components in one or more networks.

In the depicted embodiment, the recording device322includes a processor309, memory313, storage315, interface317, and bus319. Although a system is depicted having a particular number of particular components in a particular arrangement, this disclosure contemplates any system having any suitable number of any suitable components in any suitable arrangement. Processor309may be a microprocessor, controller, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other components, (e.g., memory313) wireless networking functionality. Such functionality may include providing various features discussed herein. In particular embodiments, processor309may include hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor309may retrieve (or fetch) instructions from an internal register, an internal cache, memory313, or storage315; decode and execute them; and then write one or more results to an internal register, an internal cache, memory313, or storage315.

In particular embodiments, processor309may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor309including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor309may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory313or storage315and the instruction caches may speed up retrieval of those instructions by processor309. Data in the data caches may be copies of data in memory313or storage315for instructions executing at processor309to operate on; the results of previous instructions executed at processor309for access by subsequent instructions executing at processor309, or for writing to memory313, or storage315; or other suitable data. The data caches may speed up read or write operations by processor309. The TLBs may speed up virtual-address translations for processor309. In particular embodiments, processor309may include one or more internal registers for data, instructions, or addresses. Depending on the embodiment, processor309may include any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor309may include one or more arithmetic logic units (ALUs); be a multi-core processor; or any other suitable processor.

Memory313may be any form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), flash memory, removable media, or any other suitable local or remote memory component or components. In particular embodiments, memory313may include random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM, or any other suitable type of RAM or memory. Memory313may include one or more memories313, where appropriate. Memory313may store any suitable data or information utilized by the recording device, including software embedded in a computer readable medium, and/or encoded logic incorporated in hardware or otherwise stored (e.g., firmware). In particular embodiments, memory313may include main memory for storing instructions for processor309to execute or data for processor309to operate on. In particular embodiments, one or more memory management units (MMUs) may reside between processor309and memory313and facilitate accesses to memory313requested by processor309.

As an example and not by way of limitation, the recording device322may load instructions from storage315or another source (such as, for example, another computer system) to memory313. Processor309may then load the instructions from memory313to an internal register or internal cache. To execute the instructions, processor309may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor309may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor309may then write one or more of those results to memory313. In particular embodiments, processor309may execute only instructions in one or more internal registers or internal caches or in memory313(as opposed to storage315or elsewhere) and may operate only on data in one or more internal registers or internal caches or in memory313(as opposed to storage315or elsewhere).

In particular embodiments, storage315may include mass storage for data or instructions. As an example and not by way of limitation, storage315may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage315may include removable or non-removable (or fixed) media, where appropriate. Storage315may be internal or external to the recording device322, where appropriate. In particular embodiments, storage315may be non-volatile, solid-state memory. In particular embodiments, storage315may include read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. Storage315may take any suitable physical form and may comprise any suitable number or type of storage. Storage315may include one or more storage control units facilitating communication between processor309and storage315, where appropriate.

In particular embodiments, interface317may include hardware, encoded software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) among the recording device322, other recording devices similar to the recording device322, any networks, any network devices, and/or any other computer systems. As an example and not by way of limitation, interface317may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network and/or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network.

In some embodiments, interface317comprises one or more radios coupled to one or more physical antenna ports. Depending on the embodiment, interface317may be any type of interface suitable for any type of network with which the recording device322is used. As an example and not by way of limitation, the recording device322can communicate with an ad-hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, the recording device322can communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, an LTE network, an LTE-A network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or any other suitable wireless network or a combination of two or more of these. The recording device322may include any suitable interface317for any one or more of these networks, where appropriate.

In some embodiments, interface317may include one or more interfaces for one or more I/O devices. One or more of these I/O devices may enable communication between a person and the recording device322. As an example and not by way of limitation, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touchscreen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. Particular embodiments may include any suitable type and/or number of I/O devices and any suitable type and/or number of interfaces317for them. Where appropriate, interface317may include one or more drivers enabling processor309to drive one or more of these I/O devices. Interface317may include one or more interfaces317, where appropriate.

Bus319may include any combination of hardware, software embedded in a computer readable medium, and/or encoded logic incorporated in hardware or otherwise stored (e.g., firmware) to couple components of the recording device322to each other. As an example and not by way of limitation, bus319may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or any other suitable bus or a combination of two or more of these. Bus319may include any number, type, and/or configuration of buses319, where appropriate. In particular embodiments, one or more buses319(which may each include an address bus and a data bus) may couple processor309to memory313. Bus319may include one or more memory buses.

Herein, reference to a computer-readable storage medium encompasses one or more tangible computer-readable storage media possessing structures. As an example and not by way of limitation, a computer-readable storage medium may include a semiconductor-based or other integrated circuit (IC) (such, as for example, a field-programmable gate array (FPGA) or an application-specific IC (ASIC)), a hard disk, an HDD, a hybrid hard drive (HHD), an optical disc, an optical disc drive (ODD), a magneto-optical disc, a magneto-optical drive, a floppy disk, a floppy disk drive (FDD), magnetic tape, a holographic storage medium, a solid-state drive (SSD), a RAM-drive, a SECURE DIGITAL card, a SECURE DIGITAL drive, a flash memory card, a flash memory drive, or any other suitable tangible computer-readable storage medium or a combination of two or more of these, where appropriate.

Particular embodiments may include one or more computer-readable storage media implementing any suitable storage. In particular embodiments, a computer-readable storage medium implements one or more portions of processor309(such as, for example, one or more internal registers or caches), one or more portions of memory313, one or more portions of storage315, or a combination of these, where appropriate. In particular embodiments, a computer-readable storage medium implements RAM or ROM. In particular embodiments, a computer-readable storage medium implements volatile or persistent memory. In particular embodiments, one or more computer-readable storage media embody encoded software.

Herein, reference to encoded software may encompass one or more applications, bytecode, one or more computer programs, one or more executables, one or more instructions, logic, machine code, one or more scripts, or source code, and vice versa, where appropriate, that have been stored or encoded in a computer-readable storage medium. In particular embodiments, encoded software includes one or more application programming interfaces (APIs) stored or encoded in a computer-readable storage medium. Particular embodiments may use any suitable encoded software written or otherwise expressed in any suitable programming language or combination of programming languages stored or encoded in any suitable type or number of computer-readable storage media. In particular embodiments, encoded software may be expressed as source code or object code. In particular embodiments, encoded software is expressed in a higher-level programming language, such as, for example, C, Python, Perl, Structured Query Language (SQL), or a suitable extension thereof. In particular embodiments, encoded software is expressed in a lower-level programming language, such as assembly language (or machine code). In particular embodiments, encoded software is expressed in scripting or command language that can be interpreted by a command-line interpreter (e.g., BASH in a UNIX environment). In particular embodiments, encoded software is expressed in JAVA. In particular embodiments, encoded software is expressed in Hyper Text Markup Language (HTML), Extensible Markup Language (XML), or other suitable markup language.

Additionally, the recording device322can include a media capture component320. The media capture component320can include video-capture hardware and/or software (e.g., a camera), audio-capture hardware and/or software (e.g., a microphone), combinations of same, and/or the like. In a typical embodiment, the media capture component320enables the recording device322to capture audio and/or video for processing and storage.

Operation of the recording device322can be facilitated by an application321. In certain embodiments, the application321can access data store318on storage315. The data store318can include, for example, one or more databases, one or more flat files, and/or the like. In an example, the data store318can store configuration settings that govern when group event recording is to occur. For example, the configuration settings of the data store318can be expressed as parameters. Furthermore, the application321can operate to store audio and/or video captured, for example, using the media capture component320, as individual recordings in the data store318. In addition, or alternatively, in some embodiments, metadata related to each recording can be stored in the data store318in relation to the recording as a metadata record or file.

In certain embodiments, the application321and the configuration settings stored in the data store318can, in combination, serve as an internal logic tree of the recording device322. For example, the application321can include conditions under which the recording device322should initiate recording, continue recording, and/or stop recording. In various embodiments, the application321can use the configuration settings stored in the data store318as inputs for evaluating those conditions and taking appropriate recording action based thereon. For example, the configuration settings stored in the data store318can include parameters such as, for example, the parameters listed in Table 1 below.

In an example, with reference to Table 1 above, if the application321determines that “Group_Member_Start” is set to “true,” the application321can configurably decide to initiate a recording upon receipt of a status message indicating that another recording device in the same multi-peer recording-device management system has made a decision to initiate a recording. Similarly, if the application321determines that “Group_Member_Stop” is set to “true,” the application321can configurably decide to stop such a recording upon receipt of a status message indicating that another recording device in the same multi-peer recording-device management system has made a decision to stop its recording. In certain embodiments, the application321can include logic that only initiates or stops recordings in the fashion described above for status messages received from specific devices, specific types of devices, or combinations of devices.

For example, the application321could include logic that only initiates or stops a recording when a non-mobile device, such as the audio/video recording system104ofFIG. 1, sends a status message indicates a decision to start or stop recording. In another example, the application321could include logic that only stops a recording when a specific recording device, such as the recording device whose status message originally initiated a recording decision-making process, sends a status message indicating a decision to stop recording. In yet another example, if the recording device322is an audio/video recording system such as the audio/video recording system104ofFIG. 1, the application321could include logic that only starts recordings for particular event types such as, for example, activation of vehicle emergency lights, activation of vehicle sirens, activation of a wireless microphone or auxiliary input, vehicle crash detection, vehicle speed in excess of a threshold, combinations of same and/or the like. In still another example, if the recording device is a mobile device similar to the mobile devices102ofFIG. 1, the application321could include logic such that, if the mobile device goes out of range of the other recording devices while recording, stops recording and then later comes back in range of the other recording devices, the mobile device neither resumes recording nor starts a new recording, even if those other recording devices are still recording when the mobile device comes back in range.

In addition, or alternatively, in certain embodiments, the functionality described with respect to any of the foregoing examples can be turned on or off via corresponding parameters in the configuration settings. For example, configuration parameters can be established for specific event types such that recording should be initiated or not initiated based on whether the corresponding parameter is “true” or “false.” Other examples of configurably initiating and stopping recordings will be apparent to one skilled in the art after reviewing the present disclosure.

It should be appreciated that various implementations of the recording device322can include other components not explicitly shown or described with respect toFIG. 3. For example, if the recording device322is a mobile device similar to the mobile devices102ofFIG. 1, the recording device322can include a battery that provides a limited power source to the recording device322. The recording device322can also include any of the components described above with respect to the audio/video recording system104and/or the mobile devices102, such as a GPS module, an accelerometer, etc. Other examples of variations will be apparent to one skilled in the art after reviewing the present disclosure.

FIG. 4illustrates an example of a process400for implementing peer-to-peer group event recording on a recording device such as, for example, the recording device322ofFIG. 3. In certain embodiments, a process similar to the process400can be initiated when the recording device is powered on or in response to another stimulus. In various embodiments, the process400can be executed, in whole or in part, by a computer system such as, for example, one or more of the mobile devices102, the audio/video recording system104, the mobile device202(1), the mobile device202(2), the audio/video recording system204, the recording device322, and/or a component of the foregoing. Although any number of computer systems can be involved in executing the process400, for simplicity of description, the process400will be described with respect to the recording device322ofFIG. 3. For purposes of illustration, the recording device322is assumed to begin the process400in an idle state such that, at the start of the process400, the recording device322is not recording.

At block402, the recording device322monitors status messages received from other recording devices of the same multi-peer recording-device management system for decisions by those recording devices to initiate a recording. For example, the multi-peer recording-device management system can be similar to the system100ofFIG. 1. At decision block404, the recording device322determines whether a new status message that indicates a decision to initiate recording has been received. If not, the process400returns to block402and continues to monitor status messages as described previously. Otherwise, if it is determined at decision block404that the recording device322has received a new status message that indicates a decision to initiate recording, the process400proceeds to decision block406.

At decision block406, the recording device322determines whether to initiate a recording on the recording device322based, at least in part, on the configuration settings and the new status message. The new status message can include, for example, an indicator of a decision by the sending recording device to initiate a recording on that device (e.g., an indicator of “on”) and a unique recording identifier that is specific to the recording on the sending recording device. In addition, or alternatively, the new status message can include any of the other example data described above with respect toFIGS. 1, 2A-B, and3such as, for example, GPS location information, battery level, memory availability, device status (e.g., operational, malfunctioning), last-heard-from (LHF), combinations of same and/or the like. In general, the decision to initiate a recording can be based on any of the example conditions and criteria described above in relation toFIGS. 1, 2A-B, and3.

If no determination to initiate a recording is made at decision block406, the process400returns to block402and continues to monitor status messages as described previously. Otherwise, if it is determined at decision block406to initiate a recording on the recording device322, the recording device322initiates a recording at block408. The recording can be initiated, for example, by starting to record captured audio and/or video in the storage315of the recording device322. Although not explicitly illustrated inFIG. 4, in some embodiments, in response to a decision to initiate recording, the recording device322can perform additional processing to determine whether local conditions thereon, such as insufficient memory or a low battery level, should at least temporarily override the recording decision. Examples of the additional processing will be described in greater detail with respect toFIG. 5.

At block410, the recording device322creates metadata for the initiated recording. In general, the created metadata can include any of the example data described above that can be included in a status message as well as other data. For example, as part of the block410, the recording device322can create a unique recording identifier that is specific to the recording initiated on the recording device322. In a typical embodiment, each recording device that initiates a recording in the context of group event recording creates and maintains its own recording identifier that is distinct from the identifier of any other device participating in group event recording at a given time.

At block412, the recording device322stores metadata for the recording in a metadata file for the recording. As described with respect toFIG. 3, the metadata file can reside, for example, in the data store318or in other memory. The stored metadata can include, for example, some or all of the data in the new status message that initiated the recording decision-making logic at decision block406, some or all of the metadata created at block410, and/or other data. By way of more specific example, the recording device322can store all known unique recording identifiers related to this particular instance of group event recording. In general, at the block412, the recording device322may know of its own unique recording identifier (created at block410) and of the unique recording identifier that was previously created by the recording device that sent the new status message (identified at decision block404as described above). Both unique recording identifiers can be stored in the metadata file and serve to identify the two recordings as related, although the two recordings are initiated on two different recording devices. As will be described in greater detail below, the recording device322can update the metadata file as it learns about additional recording devices that decide to record the event.

At block414, the recording device322transmits a status message for receipt by other recording devices of the same multi-peer recording-device management system. The transmitted status message can include any of the example data described above with respect to other example status messages. For example, the transmitted status message can include an indicator of a decision by the recording device322to initiate the recording (e.g., an indicator of “on”) and the unique recording identifier created, for example, as part of block410. In certain embodiments, the other recording devices can process and react to the transmitted status message using, for example, a process similar to the process400. Such a process can include creating and storing metadata as described above with respect to blocks410-412and updating metadata as will be described in greater detail below.

At block416, the recording device322monitors status messages from other recording devices of the same multi-peer recording-device management system for recording decisions. The recording decisions can include, for example, other decisions to initiate recording, decisions to stop recording, and/or like decisions. At decision block418, the recording device322determines whether a new status message that indicates a recording decision has been received. If not, the process400returns to block416and continues to monitor status messages from other recording devices as described previously. Otherwise, if it is determined at decision block418that a new status message that indicates a recording decision has been received, the process400proceeds to block420.

At block420, the recording device322updates the metadata file. For example, if the new status message identified at decision block418indicates a decision by a particular recording device to initiate or stop recording, the recording device322can extract, from the new status message, a unique recording identifier that was created by the particular recording device to identify its recording. The recording device322can store the extracted unique identifier in the metadata file as a known unique recording identifier related to this particular instance of group event recording. The block420can be omitted in cases where there is no metadata to update. For example, in some implementations, if the recording device322has previously seen another status message that contains the same unique recording identifier, the recording device322may not update the metadata file.

At decision block422, the recording device322determines whether to change its recording status based, at least in part, on its configuration settings and the new status message identified at the decision block418. If no determination to change the recording status is made at decision block422, the process400returns to block416, where the recording device322continues to record and continues to monitor status messages as described previously. In some embodiments, a status message indicating the decision to continue recording can be transmitted in connection with the return to block416. Otherwise, if it is determined at decision block422to change the recording status of the recording device322, the process400proceeds to block424. At block424, the recording device322stops the recording and transmits a status message to other recording devices of the same multi-peer recording-device management system. In general, the transmitted status message can be of a similar format to that described above with respect to block414, except that the status message transmitted at block424typically includes an indicator of a decision by the recording device322to stop the recording (e.g., an indication of “off”). From block424, the process400returns to block402and proceeds as described above.

In general, the process400can continue to execute iteratively until a suitable termination criterion is satisfied. Although not explicitly illustrated, various implementations can include exit conditions that cause or allow the process400to terminate at any point. For example, in some implementations, user input can be used to terminate the process400and/or stop recordings. Also, in some implementations, the process400and/or recordings can be stopped automatically after the expiration of a specified period of time. In addition, although the process400is described and illustrated as being executed in a particular sequence, the blocks of the process400need not be executed in that sequence. For example, although the creation of metadata at block410is illustrated as occurring subsequent to the recording being initiated, some or all of the metadata can also be created before or in parallel to initiating the recording. By way of further example, although status messages are illustrated as being transmitted after a recording is initiated or stopped, such status messages can also be sent before or in parallel to initiating or stopping the recording. Other rearrangements of the blocks ofFIG. 4will be apparent to one skilled in the art after reviewing the present disclosure.

Advantageously, in certain embodiments, execution of the process400can result in the metadata file of each initiated recording identifying a set of related recordings that occurred at a plurality of different recording devices of the same multi-peer recording-device management system. As described above, each recording of each recording device may later be transmitted to an event library. In certain embodiments, the identification of related recordings in the metadata file enables each specific recording to be coordinated/synchronized with other recordings as relating to the same group event recording. In these embodiments, the metadata file can advantageously enable subsequent synchronization and coordination of recordings without any need for a central event identifier across all recording devices of the multi-peer recording-device management system. Rather, in certain implementations, each recording device can generate its own unique recording identifier for each recording it initiates and maintain a metadata file for each recording that includes recording identifiers of related recordings initiated on other recording devices.

FIG. 5illustrates an example of a process500for initiating recording on a recording device such as, for example, the recording device322ofFIG. 3. In certain embodiments, a process similar to the process500can be triggered whenever the recording device decides, based on its own internal logic tree, to initiate recording, for example, as a result of receiving a status message indicating that another recording device either is or soon will be recording. For example, in certain embodiments, the process500could replace, or be included as part of, steps241-242and243-244ofFIG. 2A. By way of further example, the process500could replace, or be included as part of, blocks406-408ofFIG. 4.

In various embodiments, the process500can be executed, in whole or in part, by a computer system such as, for example, one or more of the mobile devices102, the audio/video recording system104, the mobile device202(1), the mobile device202(2), the audio/video recording system204, the recording device322, and/or a component of the foregoing. Although any number of computer systems can be involved in executing the process500, for simplicity of description, the process500will be described with respect to the recording device322ofFIG. 3.

At block502, the recording device322determines to initiate a recording as described, for example, with respect to steps241-242and243-244ofFIG. 2Aand with respect to decision block406ofFIG. 4. At decision block504, the recording device322determines whether local conditions are acceptable for initiating a recording. For example, in certain embodiments, the recording device322can look for fault conditions on the recording device322such as a battery level below a threshold (e.g., if the recording device322is a battery-powered device), available capacity in the storage315that is below a threshold, combinations of same and/or the like. In certain embodiments, the recording device322can treat fault conditions as unacceptable local conditions for recording.

If it is determined at decision block504that local conditions are acceptable for initiating recording, the process500proceeds to block510and a recording is initiated. Otherwise, if it is determined at decision block504that at least one local condition is not acceptable for initiating recording, the process500proceeds to block506. At block506, the recording device322maintains a holding state without initiating recording. While in the holding state, the recording device322can periodically check whether the unacceptable condition(s) identified at decision block504have been resolved so that recording can be initiated. In an example, if the storage315lacks sufficient capacity, sufficient capacity may later become available. In another example, if a battery level of the recording device322is below a threshold, the recording device322may later be provided an alternative or additional power source (e.g., another battery).

At decision block508, the recording device322checks whether the unacceptable local condition(s) identified at decision block504have been resolved. If it is determined at decision block508that the unacceptable local condition(s) have been resolved, the process500proceeds to block510and a recording is initiated. Otherwise, if it is determined at decision block508that the unacceptable local condition(s) have not been resolved, the process500returns to block506and the recording device322remains in the holding state. In various embodiments, the process500can be terminated manually by a user or automatically, for example, upon the expiration of a period of time, in response to receiving a status message that all other recording devices in the system have stopped recording, or whenever other suitable stop criteria is satisfied.

In some embodiments, the process500can be modified such that there is no holding state when there is an unacceptable local condition on the recording device322. In these embodiments, once an unacceptable local condition is determined to exist, the recording device322can elect not to participate in the group event recording. In these embodiments, the recording device322can omit the above-described periodic checking to determine whether unacceptable local condition(s) have been resolved.