WO2017062869A1 - Enregistrement de contenu vidéo segmenté - Google Patents

Enregistrement de contenu vidéo segmenté Download PDF

Info

Publication number
WO2017062869A1
WO2017062869A1 PCT/US2016/056133 US2016056133W WO2017062869A1 WO 2017062869 A1 WO2017062869 A1 WO 2017062869A1 US 2016056133 W US2016056133 W US 2016056133W WO 2017062869 A1 WO2017062869 A1 WO 2017062869A1
Authority
WO
WIPO (PCT)
Prior art keywords
segment
record
request
content
recordings database
Prior art date
Application number
PCT/US2016/056133
Other languages
English (en)
Inventor
Clint RICKER
Hoi-Tauw Chou
Gowdish KUMARASWAMY
David Stuart Morgan
Ivan V. LEGRAND
Original Assignee
Cisco Technology, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology, Inc. filed Critical Cisco Technology, Inc.
Priority to CN201680072258.XA priority Critical patent/CN108370449B/zh
Priority to EP16787640.8A priority patent/EP3360333B1/fr
Priority claimed from US15/288,000 external-priority patent/US10331738B2/en
Publication of WO2017062869A1 publication Critical patent/WO2017062869A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23103—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion using load balancing strategies, e.g. by placing or distributing content on different disks, different memories or different servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2747—Remote storage of video programs received via the downstream path, e.g. from the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present disclosure relates generally to storage systems, and in particular, to systems, methods and apparatuses enabling storage of video content data for multiple users.
  • Figure 1 is a block diagram of a storage system in accordance with some implementations.
  • Figure 2 is a block diagram of a recording request in accordance with some implementations.
  • Figure 3 is a flowchart representation of a method of handling a recording request in accordance with some implementations.
  • Figure 4 is a block diagram of an example recordings database in accordance with some implementations.
  • Figure 5 is a flowchart representation of a method of handling a received segment in accordance with some implementations.
  • Figure 6 is a flowchart representation of a method of handling a recording deletion request in accordance with some implementations.
  • Figure 7 is a flowchart representation of a method of handling a record modification request in accordance with some implementations.
  • Figure 8 is a flowchart representation of a method of handling a recording request in accordance with some implementations.
  • Figure 9 is a block diagram of a computing device in accordance with some implementations.
  • a method includes a method includes receiving a segment of content, determining that the segment is referenced by at least one active record of a recordings database, and, responsive to the determination, storing the segment.
  • policies may indicate that a single common copy be stored for consumption by any of the users (or at least a subset of the multiple users) or that a unique copy be stored for consumption by each individual user (or at least the users not in the subset). Such policies may be based on legal requirements associated with the content, limitations of the storage system (e.g., available storage space), or other factors.
  • the policies may vary by the location of the multiple users and the content. For example, in order to fit within fair use of copyright, a policy can dictate that a scripted drama television program be stored as a unique copy for each individual user. As another example, a policy can dictate that an educational program can be stored as a single common copy for consumption by any user. As another example, a policy can dictate that any programs from a public broadcasting channel can be stored as a single common copy for consumption by any user. As another example, a policy can dictate that particular programs or channels for which rights have been negotiated can be stored as a single common copy for consumption by any user.
  • a policy can indicate that a common copy be stored for consumption by any of a subset of the users (e.g., users in a first jurisdiction) and that a unique copy be stored for consumption for each individual user not within the subset.
  • a policy can dictate that a broadcast of a college sporting event can be stored as a single common copy for consumption by any user within the state of the college, but that unique copies of the sporting event be stored for consumption by individual users not in the state.
  • Various implementations described include a storage system that can simultaneously store content under different storage policies, such common copy storage or unique copy storage, and can map the wide variety of schedule requests to the underlying recordings such that all users, including users sharing the same content, have their own personalized view of the content based on their schedule request.
  • FIG. 1 is a block diagram of a storage system 100. While certain specific features are illustrated, those of ordinary skill in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity and so as not to obscure more pertinent aspects of the example implementations disclosed herein.
  • the storage system 100 includes an ingester module 110 that receives data 101, a recorder module 120 that receives requests 102 to store the data 101 for a user, and an object store 130 that stores the data 101.
  • the object store 130 includes a number of storage locations at which objects can be stored.
  • the object store 130 can store, among other things, a unique copy of the data 101 for each of a number of requesting users and a common copy of the data 101 that is shared between a number of requesting users.
  • Each of the modules 110, 120, 130 of the storage system can be implemented on the same or separate computing devices.
  • the object store 130 can be a distributed object store including multiple computing devices networked over multiple locations.
  • the storage system 100 is configured to store video data associated with multicast (e.g., broadcast) content and, thus, acts as a digital video recorder (DVR). As both the data 101 and the requests 102 can be received over a network, the storage system 100 can function as a cloud-based DVR.
  • DVR digital video recorder
  • a user can use the storage system 100 to record a television program within the storage system and watch the television program at a time later than the broadcast time.
  • the recorder module 120 receives a recording request 102 from a user indicating that the user desires to record a particular television program.
  • the recording request 102 can include a recording request identifier (ID) 210, a channel ID 220, and temporal data 230 indicative of a time span of the recording.
  • ID (referred to as a "request ID”) can be a unique identifier that is different for each recording request.
  • the request ID 210 can be a UUID (universally unique identifier).
  • the request ID 210 includes a user ID or, at least, indicates a user identifier or user device (such as a set-top box).
  • the channel ID 220 can be an identifier that indicates a broadcast channel or sub-channel (also referred to as profiles).
  • a broadcast channel can include sub-channels with multiple versions of the same broadcast.
  • the broadcast channel can include sub-channels (also referred to as channels) with video data at different bitrates or with different audio/subtitles.
  • the channel ID 220 indicates a broadcast channel and the recording request 102 further includes data indicating the sub-channel or profile.
  • the channel ID 220 indicates the sub-channel or profile.
  • the temporal data 230 can indicate the time span of the recording in a variety of ways. In some implementations, the temporal data 230 indicates a start time and an end time of the recording. In some implementations, the temporal data 230 indicates a start time and a recording length of the recording. In some implementations, the temporal data 230 indicates one or more standard programming slots (e.g., 8:00 pm to 8:30 pm and 8:30 pm to 9:00 pm) and the recorder module 230 determines the time span of the recording based on the programming slot.
  • standard programming slots e.g., 8:00 pm to 8:30 pm and 8:30 pm to 9:00 pm
  • the recording module 120 instructs the ingester module 110 to receive (or retrieve) data 101 from the indicated channel (or sub-channel) during the time span and return the data 101 to the recorder module 120.
  • the recorder module 120 stores the data 101 in the object store 130 for later access for the user according to a storage policy.
  • the recorder module 120 can handle the multiple requests in a number of ways to improve efficiency of the storage system 100.
  • the recorder module 120 can receive a first recording request (having a first request ID, a channel ID, and temporal data) and a second recording request (having a second request ID, the same channel ID, and the same, or at least overlapping, temporal data).
  • the recorder module 120 receives the data from the ingester module 110 and, for each recording request, instructs the object store 130 to store a unique copy of the data as a separate object in the object store 130.
  • the recorder module 120 can submit a first PUT command to the object store 130 including the data and can further submit a second PUT command to the object store 130 including the second request ID and the data.
  • the recorder module 120 can store metadata associating the first request ID with the object created by the first PUT command and associating the second request ID with the object created by the second PUT command.
  • implementations may be inefficient for large numbers of recordings. Nevertheless, storage policy may dictate that such an implementation be employed for at least some recording requests.
  • Such implementations include multiple PUT commands from the recorder module 120 increasing the overhead of the signaling.
  • Such implementations also include the recorder module 120 pushing identical data to the object store 130 multiple times, inefficiently using network bandwidth and increasing the overhead of transport. Further, creation of a large number of objects can create a sizable amount of metadata to be managed by the recorder module 120.
  • the recorder module 120 receives the data from the ingester module 110 and instructs the object store 130 to store a common copy of the data as a single object in the object store 130.
  • the recorder module 120 can store metadata associating the first request ID with the object created by the PUT command and associating the second request ID with the same object.
  • the recorder module 120 can, in some implementations (as described above) create a unique copy for each request.
  • the recorder module can create a copy from the earliest start time to the latest end time. For example, if the first request indicated 7:59 pm to 8:30 pm and the second request indicated 8:00 pm to 8:35 pm, the recorder module 120 can store an object including the content between 7:59 pm and 8:35 pm. Further, the recorder module 120 can include bookmarks in the content that represent the requested subsections of each request.
  • the data 101 received by recorder module 120 is video data broken into segments of approximately 2 seconds. In some implementations, the segments may be other lengths of time, e.g., between approximately 2 seconds and 10 seconds. In some implementations, the data 101 is received by the ingester module 110 as segments. In some implementations, the data 101 is converted by the ingester module 110 into segments before being sent to the recorder module 120.
  • the recorder module 120 in response to receiving a recording request, creates a database record including the request ID, data indicative of the channel (or sub-channel or other source), data indicative of the start time and end time, and data indicative of a storage policy.
  • the storage policy can signal directives such as common/unique copy storage per user, resiliency, and so forth.
  • the storage policy can indicate whether a unique copy of the content is to be stored for the user or whether a common copy of the content to be stored can satisfy the recording request.
  • the storage policy can be based on a number of factors, such as the location of the requestor of the recording request (e.g., the user), the source of the content, the nature of the content (e.g., educational or public domain), or rights to the content.
  • the recorder module 120 determines whether there is at least one recording scheduled for the segment (e.g., whether the time of the segment is between the start time and end time of a database record indicating the source of the segment).
  • the recorder module 120 will write the segment to the object store 130.
  • the recorder module 120 stores a unique copy of the segment for each recording scheduled for the segment with a storage policy indicating storage of a unique copy. Further, the recorder module 120 stores a common copy of the segment if there is at least one recording scheduled for the segment with a storage policy indicating storage of a common copy.
  • the recorded segments are written to the object store
  • the recorder module 120 can store a lookup table associating segment information (e.g., channel ID, start time, and end time) to an object identifier of the object store 130.
  • the table can, instead or additionally, be stored in the object store 130.
  • the recorder module 120 determines a set of objects to retrieve from the object store 130 (either using the lookup table or heuristics based on the deterministic key names). The recorder module 120 reads the set of objects from the object store 130 and returns them in response to the read request.
  • the recorder module 120 removes the request ID from its database (or marks it deleted, invalid, or inactive). Thus, such a recording request (or record in the database) is not considered when determining whether or how to store a received segment. Further, the recorder system 120 can periodically delete stored segments that are not referenced by any active recording requests in the database.
  • the recorder module 120 can receive a record modification request to modify the start time and end time of a recording request stored in the database. If the segments indicated by the modified start time and end times of the record modification request are stored in the object store, the recorder module 120 indicates that the request was successful and modifies the record of the database to include the modified start time and end time. Thus, a user can modify the timespan of a recording even after the start time and/or the end time of the recording has passed.
  • Figure 3 is a flowchart representation of a method of handling a recording request in accordance with some implementations.
  • the method 300 is performed by a recorder module, such as the recorder module 120 of Figure 1.
  • the method 300 is performed by processing logic, including hardware, firmware, software, or a combination thereof.
  • the method 300 is performed by a processor executing code stored in a non- transitory computer-readable medium (e.g., a memory).
  • the method 300 includes receiving a recording request and generating a database record corresponding to the recording request.
  • the method 300 begins, in block 310, with the recorder module receiving a recording request indicating content to be recorded.
  • the recording request includes data indicative of a source (e.g., a channel or sub-channel) and temporal data indicative of a time span of the recording.
  • a source e.g., a channel or sub-channel
  • temporal data can indicate the time span of the recording in a number of ways.
  • the recorder module 320 in response to receiving the recording request, the recorder module 320 generates a database record in a recordings database including a request ID, a source ID, data indicative of a start time, data indicative of an end time, and data indicative of a storage policy.
  • the data indicative of the start time and end time can be stored as temporal data in a variety of ways.
  • the recording request includes the request ID.
  • the recorder module assigns the request ID to the recording request and, optionally, returns the request ID to the requestor.
  • generating the database record includes determining a storage policy for the recording request.
  • the storage policy can indicate whether a unique copy of the content is to be stored for the user or whether a common copy of the content to be stored can satisfy the recording request.
  • the storage policy can be based on a number of factors, such as the location of the requestor of the recording request (e.g., the user), the source of the content, the nature of the content (e.g., educational or public domain), or rights to the content.
  • the method 300 returns to block 310 where additional recording requests can be received by the recorder module.
  • FIG 4 is a block diagram of an example recordings database in accordance with some implementations.
  • the recordings database 400 includes a plurality of records 401a-401b. Although only two records 401a-401b are illustrated in Figure 4, it is to be appreciated that the recordings database 400 can include any number of records.
  • Each record 401a-401b includes a request ID field 410a-410b that stores a request ID, a source field 420a-420b that stores data indicative of a source (e.g., a channel ID) of a recording, a start time field 430a-430b that stores data indicative of a start time of the recording, an end time field 440a-440b that stores data indicative of an end time of the recording, a policy field 450a-450b that stores data indicative of a storage policy and an active field 460a-460b that stores a flag indicative of whether or not the record is active.
  • a request ID field 410a-410b that stores a request ID
  • a source field 420a-420b that stores data indicative of a source (e.g., a channel ID) of a recording
  • a start time field 430a-430b that stores data indicative of a start time of the recording
  • an end time field 440a-440b that stores data indicative of an end time of the recording
  • Figure 5 is a flowchart representation of a method of handling a received segment in accordance with some implementations.
  • the method 500 is performed by a recorder module, such as the recorder module 120 of Figure 1.
  • the method 500 is performed by processing logic, including hardware, firmware, software, or a combination thereof.
  • the method 500 is performed by a processor executing code stored in a non- transitory computer-readable medium (e.g., a memory).
  • the method 500 includes receiving a segment and, if the segment is referenced by an active record, storing the segment.
  • the method 500 begins, in block 510, with the recorder module receiving a segment of content from a source.
  • the recorder module receives the segment from an ingester module which receives (or retrieves) the segment from the source.
  • the recorder module determines whether the segment is referenced by any active record in a recordings database (e.g., the recordings database 400 of Figure 4).
  • the segment can include metadata indicative the source of the segment and a time of the segment. If the source metadata of the data matches the source field 420a- 420b of an active record and the time of the segments falls within the start time and end time of the record, the segment is referenced by an active record and the method 500 continues to block 530. If not, the method 500 returns to block 510 where additional segments are received from the source (and/or other sources).
  • the recorder module stores the segment.
  • the recorder module stores the segment in an object store.
  • storing the segment includes storing the segment in the object store using a deterministic key name based on the source of the segment and the time of the segment (e.g., using the metadata).
  • storing the segment includes storing the source of the segment and the time of the segment (e.g., the metadata) in a lookup table in association with an object ID of the object stored on the object store containing the segment.
  • the recorder module stores a unique copy of the segment for each active record that references the segment and has a storage policy indicating storage of a unique copy. In some implementations, the recorder module stores a common copy of the segment if any active record references the segment and has a storage policy indicating storage of a common copy.
  • FIG. 6 is a flowchart representation of a method of handling a recording deletion request in accordance with some implementations.
  • the method 600 is performed by a recorder module, such as the recorder module 120 of Figure 1.
  • the method 600 is performed by processing logic, including hardware, firmware, software, or a combination thereof.
  • the method 600 is performed by a processor executing code stored in a non- transitory computer-readable medium (e.g., a memory).
  • the method 600 includes receiving a recording deletion request and marking a corresponding record inactive.
  • the method 600 optionally further includes deleting segments not referenced by active records.
  • the method 600 begins, in block 610, with the recorder module receiving a recording deletion request.
  • the recording deletion request can include a request ID of a record of a recording database stored by the recorder module (e.g., the recording database 400 of Figure 4).
  • the recorder module marks as inactive the record in the recording database indicated by the recording deletion request.
  • the recorder module changes a flag in an active field (e.g., the active field 460a-460b of Figure 4) to indicate that the record is inactive.
  • the recorder module determines whether to deduplicate the stored segments. In some implementations, the recorder module determines to deduplicate the stored segments in response to marking a record inactive. In some implementations, the recorder module determines to deduplicate stored segments in response to marking a threshold number of records inactive. For example, in some implementations, every tenth recording deletion request triggers deduplication. In some implementations, the recorder module determines to deduplicate stored segments periodically. For example, in some implementations, stored segments are deduplicated daily.
  • the recording module determines that a day has passed since the last deduplication, the recording module determines to deduplicate the stored segments and the method 600 proceeds to block 640. If the recording module determines not to deduplicate the stored segments, the method 600 returns to block 610 where the recorder module can receive additional recording deletion requests.
  • the recorder module deletes segments not referenced by active records.
  • the recorder module stores a table of all segments that are stored in the object store.
  • the recorder module request a list from the object store of the segments that are stored in the object store.
  • deleting segments includes sending a command to the object store to delete the segments.
  • the recorder module sends the recordings database to the object store and the object store deletes stored segments not referenced by any active record.
  • the recorder module sends the recordings database to the object store with inactive records removed or sends the recordings database in an otherwise compressed format.
  • the method 600 returns to block 610 where the recorder module can receive additional recording deletion requests.
  • Figure 7 is a flowchart representation of a method of handling a record modification request in accordance with some implementations.
  • the method 700 is performed by a recorder module, such as the recorder module 120 of Figure 1.
  • the method 700 is performed by processing logic, including hardware, firmware, software, or a combination thereof.
  • the method 700 is performed by a processor executing code stored in a non- transitory computer-readable medium (e.g., a memory).
  • the method 700 includes receiving a record modification request and, if the request can be granted, modifying a record corresponding to the request.
  • the method 700 begins, in block 710, with the recorder module receiving a record modification request.
  • the record modification request can include a request ID of a record of a recording database stored by the recorder module (e.g., the recording database 400 of Figure 4).
  • the record modification request can further include modified temporal data indicating a modified timespan for the recording.
  • the record modification request can include a modified start time, a modified end time, or both.
  • the recorder module determines whether the segments indicated by the modified temporal data are available (e.g., are recorded or are recordable due to the time of the segment being in the future). If the recorder module determines that the segments are not available, the method 700 continues to block 730 where the recorder module indicates that the request is denied before returning to block 710 where the recorder module can receive additional record modification requests. [0063] If the recorder module determines that the segments are available, the method
  • the recorder module continues to block 740 where the recorder module indicates that the request is granted before continuing to block 750 where the recorder module modifying the record according to the request.
  • the recorder module locates a record in a recordings database having the request ID of the record modification request stored in a request ID field. The recorder module then modifies the located record by replacing the data of the start time field and end time field with the modified temporal data.
  • the method 700 returns to block 710 where the recorder module can receive additional record modification requests.
  • the recorder module can determine that some, but not all, of the segments indicated by the modified temporal data are available. In response, the recorder module can indicate that the request is partially granted and modify the corresponding record to reference the segments indicated by the modified temporal data that are available.
  • Figure 8 is a flowchart representation of a method of handling a read request in accordance with some implementations.
  • the method 800 is performed by a recorder module, such as the recorder module 120 of Figure 1.
  • the method 800 is performed by processing logic, including hardware, firmware, software, or a combination thereof.
  • the method 800 is performed by a processor executing code stored in a non-transitory computer-readable medium (e.g., a memory).
  • the method 800 includes receiving a read request indicating a recording and returning one or more segments associated with the recording.
  • the method 800 begins, in block 810, with the recorder module receiving a read request indicating a recording.
  • the recorder module in response to receiving the read request, returns one or more segments associated with the recording.
  • the method 800 returns to block 810 where additional read requests can be received by the recorder module.
  • the read request includes a request ID and the recording module locates a record in a recordings database having the request ID of the read request stored in a request ID field.
  • the recorder module then retrieves (from the object store) segments referenced by the record (or at least those that have been recorded) and returns (to the requestor) the retrieved segments.
  • Figure 9 is a block diagram of a computing device 900 in accordance with some implementations.
  • the computing device 900 corresponds to the recorder module 120 of Figure 1 and performs one or more of the functionalities described above with respect to the recorder module 120. While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity, and so as not to obscure more pertinent aspects of the embodiments disclosed herein.
  • the computing device 900 includes one or more processing units (CPU's) 902 (e.g., processors), one or more output interfaces 903 (e.g., a network interface), a memory 906, a programming interface 908, and one or more communication buses 904 for interconnecting these and various other components.
  • CPU's processing units
  • output interfaces 903 e.g., a network interface
  • memory 906 e.g., a flash memory
  • programming interface 908 e.g., a programming interface
  • communication buses 904 for interconnecting these and various other components.
  • the communication buses 904 include circuitry that interconnects and controls communications between system components.
  • the memory 906 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and, in some implementations, include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices.
  • the memory 906 optionally includes one or more storage devices remotely located from the CPU(s) 902.
  • the memory 906 comprises a non-transitory computer readable storage medium.
  • the memory 906 or the non-transitory computer readable storage medium of the memory 906 stores the following programs, modules and data structures, or a subset thereof including an optional operating system 930 and a recording module 940.
  • one or more instructions are included in a combination of logic and non- transitory memory.
  • the operating system 930 includes procedures for handling various basic system services and for performing hardware dependent tasks.
  • the recording module 940 is configured to handle requests relating to recording segments of video data. To that end, the recording module 940 includes an interface module 941 and a database module 942. [0071] In some implementations, the interface module 941 is configured to receive a segment of content.
  • the interface module 941 includes a set of instructions 941a and heuristics and metadata 941b.
  • the database module 942 is configured to determine that the segment is referenced by at least one active record of a recordings database. To that end, the database module 942 includes a set of instructions 942a and heuristics and metadata 942b.
  • the interface module 941 is configured to, responsive to the determination, store the segment (e.g., in an object store).
  • the recording module 940, the interface module 941, and the database module 942 are illustrated as residing on a single computing device 900, it should be understood that in other embodiments, any combination of the recording module 940, the interface module 941, and the database module 942 can reside in separate computing devices in various implementations. For example, in some implementations each of the recording module 940, the interface module 941, and the database module 942 reside on a separate computing device.
  • Figure 9 is intended more as functional description of the various features which are present in a particular implementation as opposed to a structural schematic of the embodiments described herein.
  • items shown separately could be combined and some items could be separated.
  • some functional modules shown separately in Figure 9 could be implemented in a single module and the various functions of single functional blocks could be implemented by one or more functional blocks in various embodiments.
  • the actual number of modules and the division of particular functions and how features are allocated among them will vary from one embodiment to another, and may depend in part on the particular combination of hardware, software and/or firmware chosen for a particular embodiment.
  • the order of the steps and/or phases can be rearranged and certain steps and/or phases may be omitted entirely.
  • the methods described herein are to be understood to be open-ended, such that additional steps and/or phases to those shown and described herein can also be performed.
  • the computer system may, in some cases, include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, etc.) that communicate and interoperate over a network to perform the described functions.
  • Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium or device.
  • the various functions disclosed herein may be embodied in such program instructions, although some or all of the disclosed functions may alternatively be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located.
  • the results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips and/or magnetic disks, into a different state.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

Dans un mode de réalisation, un procédé consiste à recevoir un segment de contenu, à déterminer si le segment est référencé par au moins un enregistrement actif d'une base de données d'enregistrements, et, en réponse à la détermination, à enregistrer le segment.
PCT/US2016/056133 2015-10-09 2016-10-07 Enregistrement de contenu vidéo segmenté WO2017062869A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201680072258.XA CN108370449B (zh) 2015-10-09 2016-10-07 分段视频内容存储方法及系统
EP16787640.8A EP3360333B1 (fr) 2015-10-09 2016-10-07 Enregistrement de contenu vidéo segmenté

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201562239373P 2015-10-09 2015-10-09
US201562239379P 2015-10-09 2015-10-09
US62/239,373 2015-10-09
US62/239,379 2015-10-09
US15/288,000 US10331738B2 (en) 2015-10-09 2016-10-07 Segmented video content storage
US15/288,000 2016-10-07
US15/288,007 US10992965B2 (en) 2015-10-09 2016-10-07 Storage system for recording and retrieving data copy for multiple users
US15/288,007 2016-10-07

Publications (1)

Publication Number Publication Date
WO2017062869A1 true WO2017062869A1 (fr) 2017-04-13

Family

ID=57206401

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/056133 WO2017062869A1 (fr) 2015-10-09 2016-10-07 Enregistrement de contenu vidéo segmenté

Country Status (1)

Country Link
WO (1) WO2017062869A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011009055A2 (fr) * 2009-07-16 2011-01-20 Nagrastar, Llc Systèmes et procédés pour gérer un contenu en temps réel
US20120294591A1 (en) * 2011-05-20 2012-11-22 Echostar Technologies L.L.C. Systems and Methods for Recording Content
US20130142499A1 (en) * 2011-12-06 2013-06-06 DISH Digital L.L.C. Storage device management techniques for a remote storage digital video recorder that handles multiple bitrate content
US20140331103A1 (en) * 2009-12-29 2014-11-06 Cleversafe, Inc. Encoding multi-media content for a centralized digital video storage system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011009055A2 (fr) * 2009-07-16 2011-01-20 Nagrastar, Llc Systèmes et procédés pour gérer un contenu en temps réel
US20140331103A1 (en) * 2009-12-29 2014-11-06 Cleversafe, Inc. Encoding multi-media content for a centralized digital video storage system
US20120294591A1 (en) * 2011-05-20 2012-11-22 Echostar Technologies L.L.C. Systems and Methods for Recording Content
US20130142499A1 (en) * 2011-12-06 2013-06-06 DISH Digital L.L.C. Storage device management techniques for a remote storage digital video recorder that handles multiple bitrate content

Similar Documents

Publication Publication Date Title
US10331738B2 (en) Segmented video content storage
US10642917B2 (en) Method and device for sharing segmented video content across multiple manifests
JP4491150B2 (ja) バッファ・リードおよびライト同期機能を備えたストリーミング情報機器
US7765244B2 (en) Fast and efficient method for deleting very large files from a filesystem
US9055268B2 (en) Multi-tier recorder to enable seek-back unique copy recording
US11818406B2 (en) Data storage server with on-demand media subtitles
WO2011137681A1 (fr) Procédé et dispositif de classement de fichiers de découpage de décalage et de lecture de programmes dans un système de télévision à personnalité interactive
WO2017062869A1 (fr) Enregistrement de contenu vidéo segmenté
US9997201B2 (en) Method and apparatus for video compression of multiple instances using index frames
US9979787B2 (en) Information processing system, network storage device, and non-transitory recording medium
WO2014072872A1 (fr) Tampon de revue persistant
US11212573B2 (en) Systems, methods, and devices for managing segmented media content
KR20150093704A (ko) 동일한 디지털 비디오 및/또는 오디오 스트림의 복수의 오버랩하는 레코딩들을 저장하는 디바이스 및 방법
US10631019B2 (en) Remote storage digital video recording optimization method and system
US11051051B1 (en) Systems, methods, and devices for managing storage of media objects
AU2016223008A1 (en) Managing data
US9712859B2 (en) Generating a playlist that includes local segment identifiers and remote segment identifiers for media content
WO2022042514A1 (fr) Procédé et appareil de synchronisation de métadonnées
US20190132632A1 (en) Cloud DVR Storage Reduction
JP2007300186A (ja) コンテンツ視聴装置及びコンテンツ視聴装置の制御方法
JP2009118086A (ja) ストレージ装置及びクロック管理方法
JP2011223321A (ja) 映像コンテンツ生成装置、映像コンテンツ生成方法、デジタル放送受信装置
JP2012151742A (ja) 映像記録装置および映像記録方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16787640

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016787640

Country of ref document: EP