System and method for storing segmented video in a database

A method of storing segmented video in a database is provided. The method includes obtaining, by one or more computing devices, data indicative of a segment of a video captured by a camera. The method includes storing, by the one or more computing devices, the data indicative of the segment as a record in the database. The method includes determining, by the one or more computing devices, the record has expired based, at least in part, on a timestamp associated with the record. The method includes modifying, by the one or more computing devices, the record in response to determining the record has expired.

FIELD

The present disclosure relates generally to video streaming and, more particularly, methods for storing segmented video in a database.

BACKGROUND

Databases can be used to store a variety of data. For instance, databases can be used to store video data obtained from one or more image capture devices. However, databases have a finite storage capacity. As such, maintenance must be performed on databases from time to time to remove data that no longer needs to be stored on the database. However, performing maintenance on databases can be burdensome.

SUMMARY

In one aspect, a method of storing segmented video in a database is provided. The method includes obtaining, by one or more computing devices, data indicative of a segment of a video captured by a camera. The method includes storing, by the one or more computing devices, the data as a record in the database. The method includes determining, by the one or more computing devices, the record is expired based, at least in part, on a timestamp associated with the record. The method includes modifying, by the one or more computing devices, the record in response to determining the record is expired.

In another aspect, a system for storing segmented video in a database is provided. The system includes a camera and one or more computing devices communicatively coupled to the camera. The one or more computing devices can be configured to obtain data indicative of a segment of a video captured by the camera. The one or more computing devices can be further configured to store the data indicative of the segment as a record in the database. The one or more computing devices can be even further configured to determine the record has expired based, at least in part, on a timestamp indicative of when the record was created. Furthermore, in response to determine the record has expired, the one or more computing devices can be configured to modify the record.

In yet another aspect, a computer readable medium that includes computer readable instructions for carrying out a method of storing segmented video in a database is provided. The method can include obtaining, by one or more computing devices, data indicative of a segment of a video captured by a camera. The method can include storing, by the one or more computing devices, the data indicative of the segment as a record in the database. Furthermore, in response to determining the record has expired, the method can include modifying, by the one or more computing devices, the record.

Other examples aspects of the present disclosure are directed to apparatus, methods, electronic devices, non-transitory computer-readable media, and systems.

DETAILED DESCRIPTION

Example aspects of the present disclosure are directed to a system for storing segmented video in a database. In some implementations, the system can include a camera configured to capture video. The camera can include one or more computing devices. The one or more computing devices can be configured to compress the video using any suitable video compression algorithm. In some implementations, the one or more computing devices can be configured to parse the video into a plurality of segments. It should be appreciated, however, that the one or more computing devices can be configured to parse the video such that each segment of the plurality of segments spans any suitable amount of time. For instance, in some implementations, the one or more computing devices can be configured to parse the video such that each segment of the plurality of segments spans about 2 seconds. In alternative implementations, the one or more computing devices can be configured to parse the video such that each segment of the plurality of segments spans about 10 seconds.

In some implementations, the camera can be required to obtain a token to establish communications with a server of the system. For instance, the camera can be configured to provide a data packet to the server to obtain the token. The data packet can include a cloud storage identification (CSID) that uniquely identifies the camera. In some implementations, the camera can be configured to generate the CSID based, at least in part, on a human-readable content name assigned to the camera via a user. For instance, the human-readable content name can be established during installation of the camera.

In some implementations, the data packet can include an authorization key (e.g., coin, Proof of Work (POW), derived coin, etc.). The authorization key can allow the camera to write data to a database implemented by the server and/or read data from the database. In some implementations, the data packet can be encrypted with a public key associated with the server. Alternatively or additionally, the camera can be configured to communicate the data packet over the one or more networks to the server using any suitable communications protocol (e.g., UDP).

In some implementations, the server can include one or more computing devices. The one or more computing devices of the server can be configured to issue a token to the camera based, at least in part, on the data packet received from the camera. For instance, the one or more computing devices can be configured to determine whether the authorization key included in the payload of the data packet is valid. If the one or more computing devices determine the authorization key is valid, the one or more computing devices can communicate a data packet to the camera. The data packet can include the token that permits the camera to write data to the database implemented on the server and/or read data stored on the database. In some implementations, the data packet that includes the token can be encrypted. It should be appreciated that the data packet can be encrypted using any suitable encryption method. For instance, the data packet can be encrypted based, at least in part, on the data packet that includes the token.

In some implementations, the token provided to the camera can be valid for a predetermined amount of time. For example, the token may only be valid for twenty-four hours. It should be appreciated, however, that the token can be valid for any suitable amount of time. For instance, in some implementations, the token can be valid for greater than twenty-four hours. In alternative implementations, however, the toke can be valid for less than twenty-four hours.

In some implementations, the camera can provide a data packet to the server subsequent to obtaining the token from server. More specifically, the camera can provide the data packet to the server to write one or more segments of the video captured by the camera to the database. It should be appreciated that the data packet can include a header and a payload.

In some implementations, the header can include a variable indicative of whether the camera requests the server acknowledge receipt of the data packet. For instance, if the variable has a first value (e.g., a “C”), the server can be configured to provide an acknowledgement packet to the camera to indicate receipt of the data packet. Conversely, if the variable has a second value (e.g., a “P”), an acknowledge packet will not be provided. Alternatively or additionally, the data packet the camera provides to the server can include a cloud record key (CRK). In some implementations, the CRK can include the CSID which, as mentioned above is unique to the camera. In addition, the CRK can include a unique record identification (URID).

In some implementations, the header of the data packet can include the token previously issued to the camera. Alternatively or additionally, the header can include a timestamp indicative of when the data packet was generated. It should be appreciated, however, that the header of the data packet can include any suitable combination of the variable, CRK, token, and timestamp indicative of when the data packet was generated.

In some implementations, the payload of the data packet can include one or more segments of the video captured via the camera. It should be appreciated that the camera can be configured to communicate the data packet to the server using any suitable communication protocol. For instance, in some implementations, the camera can be configured to communicate the data packet using a hyper-text transfer protocol (HTTP) based media protocol, such as HTTP live streaming (HLS). As will be discussed below in more detail, the plurality of segments of video data can be stored as a record in the database.

In some implementations, the one or more computing devices of the server can be configured to implement a database engine. When the one or more computing devices execute the database engine, the one or more computing devices can be configured to store segments of the video as a record in the database. It should be appreciated that one segment can be provided to the server via a plurality of data packets, such as the data packets discussed above that the camera sends the server subsequent to obtaining the token needed to authenticate communication between the two devices.

In some implementations, the database can include a directory space and a segment space, both of which are specific to the camera. The directory space can include a plurality of slots (e.g., 2048 slots). For instance, the plurality of slots can span from URID 0 to URID 2047. It should be appreciated, however, that the directory space can include more or fewer slots. The segment space can begin after the directory space. For instance, the segment space can begin at URID 2048 and include all available slots thereafter (e.g., up to URID 224−1).

In some implementations, each directory entry can include an over-writeable record describing a plurality of segments of a continuous segment group (CSG). The record can include a header. In some implementations, the header can include a variable (e.g., a flag) indicative of whether the record is complete or live. Alternatively or additionally, the header can include the number of segments included in the record. For instance, in some implementations, the CSG can include up to 156 individual segments. As discussed above, each segment of the plurality of segments can be stored as a record in the segment space of the database.

In some implementations, each segment of the plurality of segments included in the CSG can include the URID (e.g., address) of the oldest (e.g., first recorded) segment included in the CSG. In addition, each segment can include the timestamp associated with the initial frame of the oldest segment. In this manner, each segment can reference back to the initial frame of the oldest segment included in the CSG.

In some implementations, directory entries can be retained in the database for a predetermined amount of time (e.g., 4 hours). As such, a directory entry that has been retained in the database for greater than the predetermined amount of time can be overwritten with a new directory entry. In some implementations, the one or more computing devices of the server can be configured to write the new directory entry into the first available slot in the directory space of the database. In alternative implementations, the header associated with each directory entry included in the database can include a variable indicative of a status (e.g., available vs. occupied) of each slot in the directory space is available. In this manner, use of the variable in the header can eliminate reads of non-existent records.

In some implementations, a user can manipulate a user device (e.g., smartphone, tablet, laptop, etc.) to request playback of the video captured by the camera. For instance, the user can demand playback starting from a particular segment of the video. In some implementations, the demanded starting point for playback of the video may not correspond to the most recent segment of the video. In such implementations, the one or more computing device can be configured to obtain a segment corresponding to the requested starting point along with one or more additional segments occurring after the segment corresponding to the demanded starting point. In this manner, the user device can request to playback the video from any desired starting point.

In some implementations, the segment requested by the user can correspond to the most recent segment of the video. In such implementations, the one or more computing devices can be configured to obtain the most recent segment (e.g., live segment) and additional segments captured by the video and stored as the record in the database.

The system according to example aspects of the present disclosure provides numerous technical benefits. For instance, auto-expiring records eliminates the need for performing maintenance (e.g., defragmenting, purging, etc.) on the database. In addition, use of CSIDs to identify a source providing segmented video eliminates the need for the source (e.g., camera) to communicate with the database server to obtain keys to authenticate communication between the source and the sever. In this manner, the system of the present disclosure is well-suited for large numbers of users accessing records with limited lifespan, such as Internet of Things (IOT) devices.

Referring now to the FIGS.,FIG.1depicts a system100for streaming video according to example embodiments. As shown, the system100can include a camera110. It should be appreciated, however, that the system100can include any suitable number of cameras110. As shown, the camera110can include one or more computing devices112. The one or more computing devices112can be configured to process video captured via the camera110. For instance, the one or more computing devices112can be configured to compress the video using any suitable video compression algorithm. Alternatively or additionally, the one or more computing devices can be configured to parse the video into a plurality of segments.

It should be appreciated, however, that the one or more computing devices112of the camera110can be configured to parse the video such that each segment of the plurality of segments spans any suitable amount of time. For instance, in some implementations, the one or more computing devices can be configured to parse the video such that each segment of the plurality of segments spans about 2 seconds. In alternative implementations, the one or more computing devices can be configured to parse the video such that each segment of the plurality of segments spans about 10 seconds.

In some implementations, the system100can include a server120that is communicatively coupled with the camera110. For instance, the server120can be communicatively coupled with the camera110over one or more networks130. Alternatively, the server120can be in direct communication with the camera110. When the server120is communicatively coupled to the camera110, the server120can obtain data (e.g., segmented video) from the camera110.

It should be appreciated that the one or more networks130can include any suitable type of network, such as a local area network (e.g., intranet), a wide area network (e.g., internet), a low power wireless network (e.g., Bluetooth Low Energy (BLE), Zigbee, etc.), cellular network, or some combination thereof and can include any number of wired or wireless links. In general, communication over the one or more networks130can be implemented via any type of wired or wireless connection, using a wide variety of communication protocols (e.g., TCP/IP, HTTP, SMTP, FTP), encodings or formats (e.g., HTML, XML, HLS), and/or protection schemes (e.g., VPN, secure HTTP, SSL).

Examples of communication protocols can include, for instance, Bluetooth low energy, Bluetooth mesh networking, near-field communication, Wi-Fi (e.g., IEEE, 802.11), Wi-Fi Direct (for peer-to-peer communication), Z-Wave, Zigbee, Halow, cellular communication, LTE, or low-power wide area networking. Other suitable wired and/or wireless communication protocols can be used without deviating from the scope of the present disclosure.

In some implementations, the server120can include one or more computing devices122configured to implement a database engine124. The one or more computing devices122can, when executing the database engine124, be configured to store segments of the video in a database implemented by the server120. As will be discussed below in more detail, the segments of the video can be stored as an over-writeable record in the database.

In some implementations, the system100can include a plurality of user devices140(only one shown) communicatively coupled to the server120via the one or more networks130. Example user devices140can include, without limitation, smartphones, tablets (e.g., iPad, Microsoft Surface Pro, etc.), laptop computers, or desktop computers. As shown, each user device of the plurality of user devices140can include one or more computing devices142. The one or more computing device(s)142can be configured to implement an application (e.g., mobile app, web-based app) to allow a user to stream the video captured via the camera110. For instance, in some implementations, the video can be displayed via a display device144, such as a LCD display.

In some implementations, the user can manipulate the user device140to request playback of the video starting from a particular segment of the video. It should be appreciated that, in some implementations, the demanded starting point for playback of the video may not correspond to the most recent segment of the video. In such implementations, the one or more computing device122of the server120can be configured to obtain a segment corresponding to the demanded starting point along with one or more additional segments occurring after the segment corresponding to the demanded starting point. In this manner, the user can request playback of the video from any desired starting point.

Referring now toFIG.2, a flow diagram of a method200for authenticating communications between a camera and a server is provided according to example embodiments of the present disclosure. It should be appreciated that the method200can be implemented using the system discussed above with reference toFIG.1.FIG.2depicts steps performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that various steps of the method200may be adapted, modified, rearranged, performed simultaneously or modified in various ways without deviating from the scope of the present disclosure.

At (202), the method200can include sending a token request to the server. For instance, the one or more computing devices of the camera can generate a data packet indicative of a request for a token that is needed to authenticate communications between the camera and the server. Referring briefly now toFIG.3, an example data packet300associated with the request for a token is provided according to example embodiments of the present disclosure. As shown, the data packet300can include a CSID310generated based, at least in part, on a human-readable content name assigned to the camera via a user. In some implementations, the one or more computing devices of the camera can be configured to implement a hash function to generate the CSID310. It should be appreciated that the CSID310is unique to the camera. As such, it should be appreciated that no two cameras included in the system can have the same CSID310. As shown, the data packet300can further include an authorization key320. Examples of the authorization key320can include, without limitation, a coin, a Proof of Work (POW), or any other suitable type of key or code that can be used to authenticate communications between the camera110and the server120.

In some implementations, the authorization key320can allow the camera to write data to a database implemented by the server. In alternative implementations, the authorization key320can allow the camera to read data from the database. In still other implementations, the authorization key320can allow the camera to write data to the database and read data from the data base. It should be appreciated that the data packet300can, in some implementations, be encrypted with a public key associated with the server. Alternatively or additionally, the camera can be configured to communicate the data packet300over one or more networks to the server using any suitable communications protocol. For instance, the camera can be configured to communicate the data packet300over the one or more networks using a user datagram protocol (UDP).

Referring again toFIG.2, the method200can include, at (204), determining, by one or more computing devices of the server, whether the authorization key320(FIG.3) included in the data packet300(FIG.3) the camera communicates to the server at (202) is valid. In some implementations, the one or more computing devices can be configured to compare the authorization key320against a plurality of authorization keys stored in a lookup table. It should be appreciated that each authorization key of the plurality of authorization keys included in the lookup table can be associated with a corresponding IoT device, such as the camera. If the server (e.g., one or more computing devices thereof) determines the authorization key320corresponds to one of the authorization keys included in the lookup table, the method200proceeds to (206). Otherwise, the method200reverts to (202).

At (206), the method200includes providing, by the one or more computing devices, a token to the camera. In some implementations, the token can be included in a data packet the server sends to the camera. Referring briefly now toFIG.4, an example data packet400the server provides to the camera is provided according to example embodiments of the present disclosure. As shown, the data packet400can include the CSID310associated with the camera and the token420generated by the server. In some implementations, the data packet400can further include a timestamp410indicative of when the server communicated the data packet400to the camera. Finally, the data packet400can include data indicative of the token420.

Referring again to theFIG.2, the method200can include, at (208), providing a request to write data to a record in the database implemented on the server. In some implementations, the request to write data to the record in the database can be associated with a data packet the camera sends to the server. Referring briefly now toFIG.5, an example data packet500the camera sends to the server is provided according to example embodiments of the present disclosure. As shown, the data packet500can include a header502and a payload504.

In some implementations, the header502can include an acknowledgement variable510. The acknowledgement variable510can indicate whether the camera requests the server acknowledge receipt of the data packet500. For instance, if the acknowledgement variable510has a first value (e.g., a “C”), the server can be configured to provide an acknowledgement packet to the camera to indicate receipt of the data packet. Conversely, if the variable has a second value (e.g., a “P”), no acknowledge packet will be provided to the camera.

In some implementations, the header502can include a cloud record key (CRK)512. The CRK512can include the CSID310(FIGS.3and4) which, as mentioned above is unique to the camera. In addition, the CRK512can include a unique record identification (URID). As will be discussed below in more detail, the URID can identify a location (e.g., address of memory element) within the database implemented by the server.

In some implementations, the header of the data packet can include the token420the server previously issued to the camera. Alternatively or additionally, the header502can include a timestamp514indicative of when the data packet was generated. It should be appreciated, however, that the header502of the data packet500can include any suitable combination of the acknowledgement variable510, the CRK512, the token420, and the timestamp514.

In some implementations, the payload504of the data packet500can include data520indicative of one or more segments of video captured via the camera. It should be appreciated that the camera can be configured to communicate the data packet to the server using any suitable communication protocol. For instance, in some implementations, the camera can be configured to communicate the data packet using a hyper-text transfer protocol (HTTP) based media protocol, such as HTTP live streaming (HLS).

Referring again toFIG.2, the method200can include, at (210), determining whether the token issued at (206) remains valid. If the token is no longer valid, the server can ignore the write request received at (208) and proceed to (218). Otherwise, the method200can proceed to (212).

At (212), the method200can include storing, by the one or more computing devices, the data packet500(FIG.5) received as part of the write request at (208). In some implementations, a portion of the data packet500can be provided to the database. For instance, the CRK512(FIG.5), timestamp514(FIG.5) and payload504of the data packet500can be stored in the database as an over-writeable record.

At (214), the method200can include determining whether receipt of the data packet500(FIG.5) provided to the server at (208) needs to be acknowledged. For instance, the one or more computing devices of the server can be configured to determine whether receipt of the data packet500needs to be acknowledged based, at least in part, on the acknowledgment variable510included in the header502of the data packet500. If the acknowledgement variable510(FIG.5) indicates the camera requests acknowledgement of receipt of the data packet500, the method200can proceed to (216). Otherwise, the method200can proceed to (218).

At (216), the method200includes providing, by one or more computing devices, an acknowledgment packet to the camera. In example embodiments, the acknowledgement packet can include the CRK512(FIG.5) and a timestamp indicative of when the acknowledgement packet was generated.

Referring now toFIG.6, a flow diagram of a method600for storing segmented video in a database is provided according to example embodiments of the present disclosure. It should be appreciated that the method600can be implemented using the system discussed above with reference toFIG.1.FIG.6depicts steps performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that various steps of the method600may be adapted, modified, rearranged, performed simultaneously or modified in various ways without deviating from the scope of the present disclosure.

At (602), the method600includes obtaining, by one or more computing devices, data indicative of a segment of video captured by a camera. In some implementations, the data indicative of the segment can include a plurality of video frames (e.g., I-frames, P-frames, B-frames, etc.) captured via the camera. It should be appreciated that the segment of video can be any suitable length. For instance, the segment can correspond to between about 2 seconds and about 10 seconds of video.

At (604), the method600includes storing, by the one or more computing devices, the data obtained at (602) as a record in a database implemented by the server. In some implementations, the data can include a continuous segment group (CSG) that includes a plurality of segments of video data. In such implementations, storing the data obtained at (602) can include storing data indicative of the CSG as a record in the database. In addition, storing the data obtained at (602) can include storing data indicative of each segment of the plurality of segments included in the CSG as a record in the database. In this manner, the database can include a record indicative of the CSG and a record indicative of each segment included in the CSG.

At (606), the method600includes determining, by the one or more computing devices, whether the record has been stored for a predetermined amount of time. It should be appreciated that the predetermined amount of time can correspond to any suitable amount of time. For instance, in some implementations, the predetermined amount of time can correspond to about four hours. It should also be appreciated that a timestamp indicating when the record was created can be used to determine whether the record has been storing the data obtained at (602) for greater than the predetermined amount of time. If the one or more computing devices determine the record has been storing the data obtained at (602) for greater than the predetermined amount of time, the method600proceeds to (608). Otherwise, the method600process to (610).

At (608), the method600includes modifying the record stored in the database. For instance, in some implementations, modifying the record can include setting a flag associated with the record to indicate that the record can be overwritten. Alternatively, modifying the record can include overwriting the record with another segment of the video captured via the camera. In this manner, maintenance actions performed on conventional databases do not need to be performed on the database of the present disclosure.

At (610), the method600continues. For instance, in some implementations, the one or more computing devices can be configured to perform step (606) at predetermined intervals of time. As an example, the one or more computing devices can be configured to determine perform step (606) once every hour. It should be appreciated, however, that the one or more computing devices can be configured to perform step (606) more or less often.

FIG.7illustrates flow of data within the system100(FIG.1) for streaming video according to example embodiments of the present disclosure. The camera110can be configured to parse video into plurality of segments, such as a first segment710, a second segment712, and a third segment714. It should be appreciated that each segment710,712,714of the plurality of segments can include data indicative of a plurality of video frames.

As an example, the first segment710, second segment712, and third segment714can each correspond to video captured during 10 second intervals of time. For instance, the first segment710of the video can include a plurality of video frames captured from 9:00:00 AM to 9:00:10. The second segment712of the video can include a plurality of video frames captured from 9:00:11 to 9:00:20. The third segment714of the video can include a plurality of video frames captured from 9:00:21 to 9:00:30. Since the first segment710, second segment712, and third segment714occur one after the other without any intervening segments, the first segment710, second segment712, and third segment714can be collectively referred to as a continuous segment group720.

In some implementations, each segment of the continuous segment group720can be provided to the server120for storage. For instance, the continuous segment group720can be stored in a record730of a plurality of records associated with a database implemented by the server120. In some implementations, the record730can be configured to accommodate a continuous segment group having156separate segments. It should be appreciated, however, that the record730can be configured to accommodate continuous segment groups having more or fewer segments.

Referring briefly now toFIG.8, the record730can include a header740and a payload742. As shown, the header740can include a flag750. In some implementations, the one or more computing device122(FIG.1) of the server120(FIG.1) can adjust the flag750to indicate whether one of the segments included in the continuous segment group720corresponds to the most recent (e.g., live) segment of video captured by the camera110. For instance, if the third segment714of the continuous segment group720corresponds to the most recent segment of video captured by the camera110, the one or more computing devices122(FIG.1) can set the flag750to have a first value. Otherwise, the one or more computing devices122can set the flag750to have a second value that is different than the first value and indicates the continuous segment group720does not include the most recent segment of video captured by the camera110.

In some implementations, the header740can include data752indicative of the number of segments included in the continuous segment group720described by the record730. As an example, since the continuous segment group720depicted inFIG.7only includes three separate segments, the data752would indicate that the continuous segment group720includes three separate segments (e.g., first segment710, second segment712, third segment714). However, as discussed above, it should be appreciated that the record730can be configured to accommodate a continuous segment group having any suitable number of segments.

In some implementations, the payload742can include data indicative of a start time for each segment included in the continuous segment group. For instance, the record730can include data760indicative of the start time (e.g., 9:00:00 AM) of the first segment710(FIG.7). In addition, the record730can include data770indicative of the start time (e.g., 9:00:11 AM) of the second segment712(FIG.7). Still further, the record730can include data780indicative of the start time (e.g., 9:00:21 AM) of the third segment714. In some implementations, the data760,770,780indicative of the start time of the first segment710, second segment712and third segment714, respectively, can be generated via the one or more computing devices112(FIG.1) of the camera110.

In some implementations, the record730can include data indicative of an end time for each segment included in the continuous segment group. For instance, the record can include data indicative of the end time (e.g., 9:00:10 AM) of the first segment710, data indicative of the end time (e.g., 9:00:20 AM) of the second segment712, and data indicative of the end time (e.g., 9:00:30 AM) of the third segment714. In some implementations, the data indicative of the end time of the first segment710, second segment712and third segment714, respectively, can be generated via the one or more computing devices112(FIG.1) of the camera110.

In some implementations, the record730can include data indicative of a unique record identification (URID) of a record associated with each segment included in the continuous segment group720. For instance, the record730can include data762indicative of the URID of a record associated with the first segment710of the continuous segment group720. In addition, the record730can include data772indicative of the URID of a record associated with the second segment712of the continuous segment group720. Still further, the record730can include data782indicative of the URID of a record associated with the third segment714of the continuous segment group720.

In some implementations, the one or more computing devices122can be configured to implement a hash table to map a key (e.g., first segment710, second segment712, third segment714, etc.) to a value (e.g., URID of first segment710, URID of second segment712, URID of third segment716). For instance, the first segment710may be assigned a key value of 101, the second segment712may be assigned a key value of 102, and the third segment714may be assigned a key value of 103. In this manner, the key values for the segments710,712,714can be sequential. Additionally, the first segment710, second segment712, and third segment714may be stored in the database such that the segments710,712,714are physically close(e.g., stored in adjacent memory locations of the database) to one another within the database. In this manner, the database can be search in a more efficient manner when the user device140demands playback of the video or at least a portion thereof.

Referring briefly toFIG.9, an example record800associated with the first segment710of the continuous segment group720(FIG.7) is provided according to example embodiments of the present disclosure. As shown, the record800can include a data field810indicative of a timestamp associated with the initial video frame of the first segment710. The record800can further include a data field812indicative of a timestamp associated with the last video frame of the first segment710. In some implementations, the record800can include a data field indicative814of the number of records associated with the first segment710. For instance, the record800indicative of the first segment710can include a plurality of records820indicative of transport stream (TS) payloads included in the first segment710of the video captured by the camera110(FIG.7).

It should be appreciated that the record800can include data field indicative of any suitable parameter. For instance, in some implementations, the record800can include a data field816indicative of metadata associated with the first segment710. Also, although the record800ofFIG.9is discussed with reference to the first segment710of the continuous segment group720(FIG.7), it should be appreciated that records associated with the second segment712and third segment714, respectively would be the same or similar to the record800associated with the first segment710.

Referring again toFIG.7, the one or more computing devices122(FIG.1) of the server120can be configured to update a root record732of the database based, at least in part, on the record730of the continuous segment group720. It should be appreciated that the root record732is updated each time a record is added to the database. In particular, the root record732is updated to indicate the URID (e.g., address) of the record that was just added. In this manner, the root record732can be accessed to identify the record indicative of a segment that was most recently added to the database. It should also be appreciated that the root record732is not subject to expiration. Thus, the root record732will remain even after the record800associated with the continuous segment group720has expired.

In some implementations, the user device140can demand playback of the video. For instance, the user device140can demand playback of the video starting from the first segment710. As such, the one or more computing devices122(FIG.1) of the server120can be configured to obtain the first segment710of the continuous segment group720. In addition, the one or more computing devices122can be configured to obtain the second segment712of the continuous segment group720and the third segment714of the continuous segment group720. In this manner, the video can be reconstructed and provided to the user device104for viewing.

FIG.10illustrates one embodiment of suitable components of a computing device112,122,142. As shown, the one or more computing devices112,122,142can include one or more processors902configured to perform a variety of computer-implemented functions (e.g., performing the methods, steps, calculations and the like disclosed herein). As used herein, the term “processor” refers not only to integrated circuits referred to in the art as being included in a computer, but also refers to a controller, microcontroller, a microcomputer, a programmable logic controller (PLC), an application specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), and other programmable circuits.

As shown, the one or more computing devices112,122,142can include a memory device904. Examples of the memory device904can include computer-readable media including, but not limited to, non-transitory computer-readable media, such as RAM, ROM, hard drives, flash drives, or other suitable memory devices. The memory device234can store information accessible by the processor(s)902, including computer-readable instructions906that can be executed by the processor(s)902. The computer-readable instructions906can be any set of instructions that, when executed by the processor(s)902, cause the processor(s)902to perform operations. The computer-readable instructions906can be software written in any suitable programming language or can be implemented in hardware.

In some implementations, the computer-readable instructions906can be executed by the processor(s)902to perform operations. For instance, the one or more computing devices122of the server120(FIG.1) can be configured to perform operations associated with storing data indicative of a segment of a video captured by a camera as a record in a database. The one or more computing devices122can be further configured to determine whether the record has expired based, at least in part, on a timestamp indicative of when the record was created. In this manner, the one or more computing devices122can overwrite the record with data indicative of another segment of the video captured by the camera.