System And Method For Delivering AV Content

Abstract

A method of delivering audiovisual content to a viewer includes a controller obtaining content from a plurality of sources wherein the obtained content is in a format associated with the source of the content; converting the content to an intermediate format; storing the converted content; determining a communication interface between the controller and at least one of a plurality of viewer destinations; and transmitting the converted content to the at least one of a plurality of viewer destinations in a second format wherein the second format is associated with the determined communication interface.

Description

RELATED APPLICATIONS/CLAIM FOR PRIORITY

This application claims the benefit of the filing date of U.S. Provisional Application No. 62/831,136 filed on Apr. 8, 2019. This application is also related to U.S. patent application Ser. No. 16/578,159 filed on Sep. 20, 2019. The subject matter of each of these applications is incorporated in their entirety by reference.

BACKGROUND

This disclosure is directed to audiovisual (AV) content communication and more specifically to communication over different communication paths to a viewer.

A recently adapted television standard, ATSC 3.0 (Advanced Television Systems Committee), provides for a hybrid delivery of television signals. The signals can be delivered over different communication paths. In addition to over the air (OTA) broadcast (first medium), this standard provides for transmission over a broadband connection (second medium) to a viewer.

OTA interface is a traditional communication path for broadcasting to all receivers within a physical viewing range. Transmission over a broadband (or network), on the other hand, can take place via unicast (one destination) or multicast (multiple destinations).

Traditional consumer ISPs (Internet service providers), utilizing unicast data networks, are overwhelmed by video streaming traffic. During the peak hours (typically between 5 to 10 PM), video streaming can consume as much as 90% of bandwidth. During non-peak periods, bandwidth is abundant and the marginal cost is effectively zero because ISPs pay by bandwidth rather than aggregate packets sent/received.

Video content distribution companies were traditionally tied to a specific delivery mechanism. Broadcast companies were tied to RF-based (Radio Frequency) broadcasts over antennas. Cable companies were tied to QAM (Quadrature Amplitude Modulation) delivery over HFC (Hybrid Fiber Coaxial) cable. Telephone communication companies used their direct, individual wiring (such as twisted-pair copper wires and later, fiber) to consumers' homes to deliver their content.

With the advent of IP-based (Internet Protocol) delivery, more and more companies are using IP-based networks to deliver content to their consumers. However, these methods are individual to each subscriber. If a plurality of customers all watch the same content, they will each use individual IP streams unicasted to their devices. From the content distribution point-of-view, all of these individual streams are replicated across their networks, resulting in much duplication of content transmission. Such duplication leads to inefficient use of the network bandwidth.

Broadcast mechanisms (such as cable, satellite, RF antenna Over-the-Air) require significant up-front investment but then have a significantly reduced cost of delivery as the number of consumers watching a particular program increase.

What is desired is a system and a method that leverage the functionality of ATSC 3.0 to efficiently distribute content to viewers (users or customers).

The terms “user”, “viewer”, “customer” and “consumer” are used interchangeably within this disclosure. These terms may all refer to the same entity. The terms “Set Top Box (STB)” and receiver are used interchangeably and may refer to the same component/device. The terms “transfer” and “communication” may refer to communication of data such as audiovisual (AV) data.

SUMMARY

According to an exemplary embodiment, a method for delivering audiovisual content to a viewer is disclosed. The method comprises: a controller obtaining content from a plurality of sources wherein the obtained content is in a format associated with the source of the content; converting the content to an intermediate format; storing the converted content; determining a communication interface between the controller and at least one of a plurality of viewer destinations; and transmitting the converted content to the at least one of a plurality of viewer destinations in a second format wherein the second format is associated with the determined communication interface.

According another exemplary embodiment, a system for delivering audiovisual content to a viewer is disclosed. The system comprises: a plurality of sources containing audiovisual content; and a controller for: obtaining content from the plurality of sources wherein the obtained content is in a format associated with the source of the content; converting the content to an intermediate format; storing the converted content; determining a communication interface between the controller and at least one of a plurality of viewer destinations; and transmitting the converted content to the at least one of a plurality of viewer destinations in a second format wherein the second format is associated with the determined communication interface.

BRIEF DESCRIPTION OF THE DRAWINGS

The several features, objects, and advantages of exemplary embodiments will be understood by reading this description in conjunction with the drawings. The same reference numbers in different drawings identify the same or similar elements. In the drawings:

FIG. 1 illustrates a method in accordance with exemplary embodiments;

FIG. 2 illustrates a system in accordance with exemplary embodiments;

FIG. 3 illustrates a controller in accordance with exemplary embodiments;

FIG. 4 illustrates a Delivery Decision Matrix (DDM) in accordance with exemplary embodiments; and

FIG. 5 illustrates a Set Top Box (STB) in accordance with exemplary embodiments.

DETAILED DESCRIPTION

In the following description, numerous specific details are given to provide a thorough understanding of embodiments. The embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the exemplary embodiments.

Reference throughout this specification to an “exemplary embodiment” or “exemplary embodiments” means that a particular feature, structure, or characteristic as described is included in at least one embodiment. Thus, the appearances of these terms and similar phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. The headings provided herein are for convenience only and do not interpret the scope or meaning of the embodiments.

Companies or entities that possess multiple means of content distribution (such as OTA and IP-based) have the ability to optimize their distribution of content over their particular networks.

According to exemplary embodiments, efficient methods and systems are disclosed for determining the content that is to be delivered to a user/viewer (customer) and the communication path thru which that content is delivered as well as the format in which it is delivered based on the communication path. The intelligence tool that is utilized for providing such efficiency may be referred to as a Channel Abstraction Layer™ or CAL™.

AV content can be in the form of a linear stream (such as live programming for example). It can also be a (data) file which can also be in a streaming format.

In ATSC 3.0 television broadcast standard, multiple distribution mechanisms (or, communication paths) may be available. Among these are: broadcast (such as ATSC 1.0, ATSC 3.0 linear multicast, ATSC 3.0 Non-Real Time [NRT] file multicast) and IP (via a wireless internet provider, 5G or a user's own IP connection. It could also be extended to Quadrature Amplitude Modulation (QAM) delivery and satellite delivery.

A method 100 in accordance with exemplary embodiments is illustrated in FIG. 1. An input may be received or extracted by a controller at 110 from a content source. The input can be a high resolution file from a content studio, a high quality linear stream or an ABR stream for over-the-top (OTT) distribution. The input can be a private, high-quality stream or file (which is not suitable for direct delivery to a viewer) or a pre-encoded adaptive bitrate stream (in MPEG-DASH or HLS format) that is designed for over-the-top (OTT) internet protocol (IP) distribution. The input stream or file may be in a format associated with its source. The format may be referred to as a first format or as a source format.

A high resolution file from a content studio can be a two (2) hour movie (from LionsGate® Corporation for example) in Pro-Res 422 codec file format encoded at 220 Mbps having a size of approximately 200 GB for example. A High Quality Linear Stream can be a Ku-band satellite transmission from a content studio (like Turner® Broadcasting or Viacom®) to an Multi-Channel Video Programming Distributor (MVPD) such as a cable company or the assignee of the present application for example. An ABR stream from OTT can be a stream formatted for end-user consumption like a feed from Newsy® or CNN® for example (https://go.cnn.com/?stream=cnn%3Fsr)

The controller may convert the received stream to an intermediate communication format at 120. The intermediate format may be a superset of all variables and/or parameters that may be needed for communicating a particular content via every distribution mechanism or communication path that may be available or encountered.

The parameters may include, but need not be limited to, bit rate, resolution, captions and encryption. The parameters could also include information obtained from external sources such as additional audio translation or additional metadata from a third party provider. A particular program can be associated with different set of parameters based on the communication path thru which it may be delivered to a viewer. For example, program X can be associated with one bit rate if being delivered via a first communication path but may be associated with another bit rate if being delivered via a second communication path.

The audiovisual content may be in the form of static content files that can all be placed in a single folder on a server. If it is a content stream (e.g. dynamic), then a manifest file containing URL locations (like a table of contents) may be created that describes the location of each such file and its parameters.

A superset can be a set of streams (resulting from the Ku-band satellite feed) encoded at multiple codecs, bitrates and resolutions (4K H.264 at 15 Mbps, 4K H.265 at 6 Mbps, 1080P H.264 at 8 Mbps, 1080P H.265 at 3 Mbps, 720P H.264 at 1.2 Mbps) along with associated audio streams, multiple closed captions streams (TTML, WebVTT, etc.) and a manifest to list all of these and their URLs.

The superset reduces the latency involved in just-in-time decision making as well as to enable different delivery mechanisms for different markets. The CAL may reside in a central distribution location and content distribution may take place at a regional or local market location.

A viewer for the data or stream may be identified at 130. This may be in response to a user request for example. A communication path or medium may be determined at 140. The path can be OTA broadcast or IP-based for example. A format for the data being communicated to the viewer may be determined at 150. The format can be based on the communication path for example. The audiovisual data can be communicated to the identified viewer via the determined communication path in the associated format at 160.

The optimal format and path for the identified viewer destination may be determined by a Delivery Decision Matrix (DDM). The optimal format may be specific to each market and each viewer. A variety of factors may be considered in making this determination. The factors may include, but not limited to, the current viewership of each program and channel, the trend in that viewership, the bandwidth requirements of that content, the viewer's location in relation to the broadcast/transmission/communication equipment as well as the viewer's tuning history for that channel, the time of day (to avoid peak costs for bandwidth), the content available on externally controlled networks (e.g. ATSC 1.0), the consumer's device capabilities, etc. A specific format may be dynamic and different formats may be implemented at different times even the user destination does not change.

The DDM may be in communication with a settop box (STB) or receiver at viewers' premises and receive data from the STB. This data can also be utilized by the DDM to formulate the intelligence for determining the path and format. The data from the STB can include user interaction with the STB, user's viewing habits, monitoring of viewer reaction by sensors associated with the STB etc. The STB may also be in communication with the controller having the superset stored therewith.

The DDM can be invoked with every content request made by the user. In general, the DDM can be invoked in response to a user request. Content may be delivered to a certain point in the network such as a Content Delivery Network (CDN) for example. Such delivery is in response to a user request via tuning to a particular channel or selecting a Video On Demand (VOD) for example. The video content is downloaded to the STB in response to such requests.

In some embodiments, such as with Near Video On Delivery (NVOD), content can be broadcast or communicated and the STB may choose to (or, not to) store the received content. Even in this scenario, the STB is making the decision to store the content by initiating tuning and collecting (or aggregating) the data packets that make up a video file.

In order to further optimize this process, the DDM decisions can also be pre-computed and delivered to the viewer's set top box (STB) as a locally-cached configuration file that specifies the currently optimal delivery path for each channel. The optimal delivery path (and format) information may be communicated to the controller containing the superset and AV content for delivery to the viewer.

The most recent information may be utilized to compute a path and a signal may be transmitted to the box (STB). When the input information (and therefore the computed path) changes, the locally cached configuration may be updated with the STB.

A DDM decision can always be overcome by manual intervention in some circumstances if needed.

A system in accordance with exemplary embodiments is illustrated in FIG. 2. audiovisual content may be in multiple (source or first) formats at corresponding multiple sources 210, 220 and 230. Content from each of those sources may be converted by associated converters 215, 225 and 235 into an intermediate format by controller 240. The intermediate format (which includes the AV data) may be stored in a memory of the controller. As described above, the intermediate format may be a superset of all variables comprising a communication content format.

Audiovisual data may be communicated to at least one of a plurality of viewers 270 based on viewer preferences/choices. One of a plurality of communication interfaces 260 may be used to communicate the data from the memory storing the superset. A delivery decision matrix 250 may determine the path and format of the audiovisual data as described above.

A plurality of converters as shown can facilitate a parallel processing of source data from multiple sources with each converter being assigned to a particular content source. In some embodiments, a single converter may be implemented which can convert data from the multiple content sources. The functionality of the converter(s) and DDM may be realized by one or more processors. A memory associated with controller 240 may store the superset.

A controller having a processor may be associated with the exemplary system for providing the logical decision making for receiving the audiovisual data, converting the data, storing the converted data, identifying destination viewer, determining communication medium and format and communicating the data.

A controller in accordance with exemplary embodiments is illustrated in FIG. 3. Controller 300 may include, but need not be limited to, a processor 310, a memory 320, a communication interface 330 and a system bus 340 for interconnecting each of these components in a known manner.

Communication interface 330 may communicate with content sources 210, 220 and 230 or with the intermediate converters 215, 225 and 235 (of FIG. 2). Interface 330 may also communicate with communication path 260 as well as with the Delivery Decision Matrix 250. Controller may be a server located in the cloud. The paths, as highlighted above, can be broadcast, broadcast multicast, IP-unicast/multicast, etc.

A DDM in accordance with exemplary embodiments is illustrated in FIG. 4. DDM 400 may include, but need not be limited to, a processor 410, a memory 420, a communication interface 430 and a system bus 440 for interconnecting each of these components in a known manner.

Communication interface 430 may communicate with controller 300 and a Set Top Box (STB) 500. DDN 400 may also be located in the cloud. As described above, DDM 400 may compute or determine the path and format based on input from STB, etc.

A Set Top Box (STB) in accordance with exemplary embodiments is illustrated in FIG. 5. STB 500 may include, but need not be limited to, a processor 510, a memory 520, a communication interface 530 and a system bus 540 for interconnecting each of these components in a known manner.

Communication interface 530 may receive viewer inputs via a remote control or a keyboard or other such input device 550. Interface 530 may also be communicate with a display or monitor (e.g. TV) 560 for displaying AV content. The display may have audio output for playing the audio component of the AV content. Interface may receive AV content via an antenna 570 (if broadcast, broadcast multicast for example) or from IP, WISP, 5G and broadband 580.

A settop box (STB) or a receiver may receive the audiovisual content at each of the viewers' premises. The STB may transmit data to DDM (in the form of user inputs, network status, etc.) or audiovisual content to a display mechanism (such as a TV or a monitor) for real time viewing. The memory may store the audiovisual data for viewing at a time chosen by the viewer.

The DDM may communicate with a plurality of STBs. There may be multiple controllers and DDMs to provide redundancy.

If a requested or desired program is already cached on the device's (i.e. STB), the content may be played. If it is not cached, a request may be made for delivery of the content. The data delivery or communication may take place via path and format specified by the DDM as described above. The STB may also collect playback statistics and deliver those in the form of analytics that can be aggregated and delivered as input to the DDM for future decision making.

Although exemplary embodiments have been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of embodiments without departing from the spirit and scope of the disclosure. Such modifications are intended to be covered by the appended claims.

Further, in the description and the appended claims the meaning of “comprising” is not to be understood as excluding other elements or steps. Further, “a” or “an” does not exclude a plurality, and a single unit may fulfill the functions of several means recited in the claims.

The above description of illustrated embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Although specific embodiments of and examples are described herein for illustrative purposes, various equivalent modifications can be made without departing from the spirit and scope of the disclosure, as will be recognized by those skilled in relevant art.

The various embodiments described above can be combined to provide further embodiments. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.

These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.

Claims

1. A method of delivering audiovisual content to a viewer, the method comprising:

a controller obtaining content from a plurality of sources wherein the obtained content is in a format associated with the source of the content;

converting the content to an intermediate format;

storing the converted content;

determining a communication interface between the controller and at least one of a plurality of viewer destinations; and

communicating the converted content to the at least one of a plurality of viewer destinations in a second format wherein the second format is associated with the determined communication interface.

2. The method of claim 1, wherein the obtained content is one or more of a high resolution file, a high quality linear stream and an adaptive bit rate (ABR) stream.

3. The method of claim 1, wherein the intermediate format has a superset format associated therewith.

4. The method of claim 3, wherein superset format includes bit rates, resolutions, captions, encryption, device optimized format and ABR manifests.

5. The method of claim 1, wherein the interface includes at least one of ATSC 1.0 over the air (OTA), ATSC 3.0 linear broadcast, ATSC 3.0 non-real time file broadcast, unicast delivery and external over the top (OTP):

6. The method of claim 1, further comprising:

communicating with a delivery decision module; and

obtaining delivery format from the module for the content being communicated to the viewer.

7. A system for delivering audiovisual content to a viewer, the system comprising:

a plurality of sources containing audiovisual content;

a controller for: obtaining audiovisual content from the plurality of sources wherein the obtained content is in a format associated with the source of the content; converting the audiovisual content to an intermediate format; storing the converted audiovisual content; determining a communication interface between the controller and at least one of a plurality of viewer destinations; and transmitting the converted audiovisual content to the at least one of a plurality of viewer destinations in a second format wherein the second format is associated with the determined communication interface.

8. The system of claim 7, further comprising:

a receiver at each viewer destination for receiving the content and displaying the content to the viewer.

9. The system of claim 8, further comprising:

a memory associated with the receiver for storing the received audiovisual content.

10. The system of claim 7, further comprising:

a delivery decision matrix module communicating with a set top box (STB) associated with a viewer and receiving viewer information from the STB; and communicating a delivery format to the controller based on the received viewer information.