Method and apparatus for creating and providing a database of metadata, descriptors of use, and other information concerning multimedia and video content streams distributed across a network are described.
In a multiple service operator (MSO) network, multimedia and video transport stream information, service metadata, encryption/rights data, channel map data, and like descriptors of use are needed for headend and other network devices, such as downstream video processing devices (VPDs), to be able to properly process, provision, distribute, and deliver multimedia content streams to other downstream devices, such as devices located on a customer premise or elsewhere (e.g., in the network cloud). Such data may also be needed by VPDs and other downstream devices to locate and process multimedia content streams available on the network. Conventionally, the information, metadata, descriptors of use, and the like for multimedia and video content streams have been entered manually by operators requiring a relatively labor-intensive process.
The manual entry of such configuration data presents a growing problem because MSO networks are being required to distribute increasing numbers of multimedia and video content streams. For example, these streams may include Internet protocol (IP) traffic, IP multicast traffic, multi-screen video streams, over-the-top (OTT) video streams, broadcast streams, and the like. Still further, such multimedia content streams are typically replicated for localization and ad insertion and are further replicated to provide streams of different resolution, digital rights management (DRM) technologies, and video transport formats required by downstream network client devices.
A MSO may have a metadata server (MS) or the like at a headend of the network. The MS enables the centralized storage and distribution of configuration data, metadata, descriptors of use, and the like for multimedia content streams available on the network. The data stored in the MS is made available to and can be automatically requested by the appropriate network devices or like components and equipment located in the headend or other locations on the network. However, as stated above, the need for the manual entry of such data impedes the creation of a database for a central management server to store and distribute such information.
This disclosure describes a method of constructing a metadata database of descriptor of use information relative to video and multimedia transport streams that are capable of being distributed across a network. The method includes electronically scanning a transport stream of interest available on the network to detect metadata directly from the transport stream and electronically collecting additional metadata of the transport stream of interest from at least one network device. The metadata and additional metadata obtained for the transport stream of interest are associated and stored in the metadata database to provide a comprehensive database of descriptor of use information that is automatically and autonomously populated.
This disclosure also describes a signal processing electronic device for automatically and autonomously constructing a metadata database of descriptor of use information of transport streams capable of being distributed across a network. The signal processing electronic device includes at least one module for scanning for metadata directly from a video transport stream of interest, for querying and collecting additional metadata known by other network devices for the video transport stream of interest, and for populating the metadata database with the metadata and additional metadata concerning descriptor of use information for the video transport stream of interest.
Various features of the embodiments described in the following detailed description can be more fully appreciated when considered with reference to the accompanying figures, wherein the same numbers refer to the same elements.
For simplicity and illustrative purposes, the principles of the embodiments are described by referring mainly to examples thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. It will be apparent however, to one of ordinary skill in the art, that the embodiments may be practiced without limitation to these specific details. In some instances, well known methods and structures have not been described in detail so as not to unnecessarily obscure the embodiments.
In a typical network 10, the CMTS 14 will be connected to a plurality of network taps, each of which are connected to a plurality of cable modems or network elements 12 such that the CMTS 14 may serve and communicate with many hundreds or more of cable modems or network elements 12. In turn, each cable modem or network element 12 may be in communication with one or more customer premises equipment (CPE) (not shown), i.e., client devices, computers, routers, set top boxes, media centers, gaming consoles, smartphones, and the like. The CMTS 14 may also be connected to numerous program providers, television networks and stations, Internet broadcasters/service providers, and the like 20 for providing content via the headend 16 to the cable modems or network elements 12 and CPE.
In addition to the above noted headend devices, the headend 16 in the embodiment illustrated in
As best shown in
By way of example, a switch in a video path at the headend of the network can be configured to replicate Internet Group Management Protocol (IGMP) and/or Multicast Listener Discovery (MLD) protocol traffic to a port of the module 32, which in turn may form part of the metadata server (MS) 22. IGMP and MLD are communications protocols used by hosts and adjacent routers on IP networks to establish multicast group memberships. The module 32 or metadata server (MS) 22 can infer the active IP multicast streams on a LAN segment by monitoring (i.e., “snooping”) IGMP or MLD membership report messages from downstream VPDs. As an alternative, the module 32 or metadata server (MS) 22 may scan a range of IP multicast addresses (MCAs) to iteratively or momentarily join and analyze the streams. In the above manner, the module 32 can discover new multimedia content streams on the network and automatically add to the database stored in the MS 22.
By way of further example, some modes of operation of the module 32 are shown in
In the running mode of operation 40 of module 32, the above three referenced processes performed by NIC136 and NIC238 can be performed concurrently. The configuration process provided by NIC238 provides a user interface (UI) (e.g. web server) and is able to apply changes to the algorithm used in the scanning process performed by NIC136. The scanning process provided by NIC136 executes the currently configured scan algorithm. For example, the scan algorithm may be IGMP and/or MLD membership report snooping or MCA range scanning as described above.
Two high-level sub-states of the scanning process may include a running process 42 (i.e., scan is in-process) and a ready process 44 (i.e., scan is imminent). The module 32 transitions from the running sub-state scan process 42 to the ready sub-state scan process 44 after a scan of a particular transport stream is complete and transitions from the ready sub-state scan process 44 to the running sub-state scan process 42 when a configuration change is made requiring a new scan or when a timer lapses which causes the module 32 to autonomously scan on a set interval.
The advertisement process can be performed by NIC238 to expose a newly-discovered set of metadata to VPDs. This process can occur in real-time or after a pre-determined time delay. For purposes of this disclosure, “real-time” includes a level of responsiveness that is sufficiently fast to keep up with the rate of scanning of a transport stream as well as a level of responsiveness that tolerates a degree of lateness or built-in delay. Any method can be used to perform the advertisement process, for instance, web services, session announcement protocol/session description protocol (SAP/SDP), or the like.
As shown in
By way of example,
After the module 32 of MS 22 discovers a new multimedia or video content stream available by the headend of the network and collects at least some limited information from the scanning process (see step 60 in
When the additional data is to be collected, the module 32 queries the network encryptor 24 for transport stream and program information with respect to a newly discovered and scanned stream (see step 64). In response, the network encryptor 24 may return primary/secondary designations, bitrates, PSI data, source IDs, service provider IDs, and like information to the module 32 (see step 66). Thereafter, the module 32 may use the source IDs, service provider IDs and like information to request and obtain rights data and the like for the stream from the digital access controller 26 and/or SI generator 28 (see step 68). The module 32 transmits a query or request (see step 70), and the digital access controller 26 and/or SI generator 28 return encryption including encryption mode, service tier, CCL level, APS, source name, and like data to the module 32 (see step 72).
As a further option, the module 32 of the MS 22 may also request channel map data from the digital access controller 26 and/or SI generator 28. See step 74 in
All the data provided by scanning a given transport stream and by querying and receiving information from network devices concerning the given transport stream is associated and used to populate and update the database stored in the MS 22. See step 90 in
By way of example with respect to the advertising process discussed above, as the module 32 assembles the metadata database in the MS 22, the MS 22 may periodically announce descriptors stored in the database via any suitable protocol, such as SAP. For example, these announcements may be made at 5 minute intervals or the like. See
The devices, units, modules, servers, network interface cards, and storage discussed above can physically be provided on a circuit board or within an electronic device and can include various processors, microprocessors, controllers, chips, disk drives, and the like. It will be apparent to one of ordinary skill in the art that the modules, processors, controllers, units, and the like may be implemented as electronic components, software, hardware or a combination of hardware and software.
While the principles of the invention have been described above in connection with specific devices, systems, and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the invention as defined in the appended claims.