EFFICIENT STREAMING FORMAT

A streaming media system and streaming format that uses a streamlined JavaScript Object Notation (JSON) manifest to enable improved streaming performance over existing streaming formats. The JSON manifest includes global objects that define certain unique (e.g., non-redundant, non-duplicative) global parameters that can pertain to any or all of the audio/video segments, along with a corresponding unique identifier to refer to the global object. The JSON schema also includes respective local objects that define local parameters for each of the audio/video segments, including one or more parameters that refer to a global object using the unique identifier of the global object, as opposed to duplicating information of the global object within the audio/video information objects themselves. As such, the disclosed JSON manifest demonstrates a substantially smaller file size, substantially faster downloading and processing time, and substantially fewer objects being ingested during processing, relative to the manifests of other streaming formats.

BACKGROUND

This disclosure relates generally to streaming media, and more specifically to manifest files for streaming media, such as streaming audio and/or video content.

A significant portion of media content produced today is consumed via streaming. For example, a consumer may use a content player of an internet-connected device (e.g., a smartphone, computer, or television) to access and stream audio and/or video content for consumption over Hypertext Transfer Protocol (HTTP). For example, Dynamic Adaptive Streaming over HTTP (DASH) and HTTP Live Streaming (HLS) are two streaming protocols that are commonly used for streaming media, and both of these protocols utilize manifests. These manifests are files, such as text files or Extensible Markup Language (XML) files, downloaded and processed by the content player to determine parameters defining how each audio and/or video segment of the requested content should be retrieved and presented by the content player.

However, it is presently recognized that, for both DASH and HLS, manifests can include a significant amount of repetitious information, causing the manifest files to be large and extensive. These manifests can be cumbersome for the content player to download and parse, resulting in undesirable delays when beginning playback of requested content, additional energy and/or computing resource consumption, and/or playback errors. As such, there exists a need to improve performance, efficiency, and stability relative to existing streaming protocols.

BRIEF DESCRIPTION

In accordance with an embodiment of the present disclosure, a playback device includes at least one memory configured to store a content player and at least one processor configured to execute stored instructions of the content player to perform actions. The actions include receiving a manifest associated with content and parsing the manifest to ingest a set of objects defining parameters of the content. The actions include selecting an audio segment of the content, a video segment of the content, or a combination thereof. The actions include determining a local audio segment information object associated with the selected audio segment, or a local video segment information object associated with the selected video segment, or a combination thereof. The actions include determining, from the ingested set of objects, at least one global object associated with the local audio segment information object or associated with the local video segment information object. The actions include presenting for playback the audio segment or the video segment by utilizing parameters defined by the at least one global object.

In accordance with an embodiment of the present disclosure, a method includes receiving a manifest associated with content and parsing the manifest to ingest a set of objects defining parameters of the content. The method includes selecting an audio segment of the content, a video segment of the content, or a combination thereof. The method includes determining a local audio segment information object associated with the selected audio segment, or a local video segment information object associated with the selected video segment, or a combination thereof. The method includes determining, from the ingested set of objects, at least one global object associated with the local audio segment information object or associated with the local video segment information object. The method includes presenting for playback the audio segment or the video segment by utilizing parameters defined by the at least one global object.

In accordance with an embodiment of the present disclosure, a method includes parsing a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) manifest associated with content to ingest objects respectively associated with audio segments of the content, video segments of the content, or a combination thereof. The method includes identifying, within the ingested objects, at least one parameter that is redundantly defined for more than one of the audio segments or more than one of the video segments. The method includes generating, in a schema, a global object defining the at least one parameter along with a corresponding unique identifier of the global object. The method includes generating, in the schema, at least one local object defining an identifier parameter that references the global object using the corresponding unique identifier of the global object. The method includes outputting the schema as a manifest for the content.

In accordance with an embodiment of the present disclosure, a non-transitory, computer-readable medium stores instructions executable by a processor of a computing device. The instructions include instructions to parse a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) manifest associated with content to ingest objects respectively associated with audio segments of the content, video segments of the content, or a combination thereof. The instructions include instructions to identify, within the ingested objects, at least one parameter that is redundantly defined for more than one of the audio segments or more than one of the video segments. The instructions include instructions to generate, in a schema, a global object defining the at least one parameter along with a corresponding unique identifier of the global object. The instructions include instructions to generate, in the schema, at least one local object defining an identifier parameter that references the global object using the corresponding unique identifier of the global object. The instructions include instructions to output the schema as a manifest for the content.

In accordance with an embodiment of the present disclosure, a device includes a memory and at least one processor coupled to the memory. The processor is configured to execute a modified streaming encoder on content to generate audio segments of the content, video segments of the content, or a combination thereof, from a source file. The processor is configured to generate a manifest for the content based on information determined during execution of the modified streaming encoder. The manifest includes a global object defining at least one parameter along with a corresponding unique identifier of the global object, and includes at least one local object defining an identifier parameter that references the global object using the corresponding unique identifier of the global object.

In accordance with an embodiment of the present disclosure, a method includes executing a modified streaming encoder on content to generate audio segments of the content, video segments of the content, or a combination thereof, from a source file. The method includes generating a manifest for the content based on information determined during execution of the modified streaming encoder. The manifest includes a global object defining at least one parameter along with a corresponding unique identifier of the global object, and includes at least one local object defining an identifier parameter that references the global object using the corresponding unique identifier of the global object.

DETAILED DESCRIPTION

As used herein, the term “audio/video” is intended to refer to audio, or video, or a combination of audio and video. The term “global” is used herein to refer to an object or parameter of a JSON manifest that can be accessed and used to facilitate the playback of any (e.g., one or multiple) or all of the audio/video segments of the audio/video content. In contrast, the term “local” or “non-global” is used herein to refer to an object or parameter of the JSON manifest that is accessed and used to facilitate the playback of only a particular (or a single) corresponding audio or video segment of the audio/video content.

As noted above, for both DASH and HLS streaming protocols, manifests can be large and extensive due to substantial repetitious information. This can lead to substantial delays in beginning playback of requested audio/video content, inefficiencies with respect to power consumption and computing resource usage of the content player or playback device, and issues with stability of the content player or playback device. In particular, it is presently recognized that DASH and HLS manifests typically include multiple representations of digital rights management (DRM) information, as well as multiple audio and video timelines defined for each video segment and each audio segment of the content. For example, even when it is identical from segment to segment (e.g., across multiple audio segments or multiple video segments), DRM information is typically repeatedly or independently defined in DASH and HLS manifests with respect to each audio/video segment. Furthermore, timeline information is typically repeatedly defined in DASH and HLS manifests for each audio/video segment. This results in substantial duplicative or redundant data that the content player and playback device must download and ingest and process, wasting energy and computing resources, and introducing undesirable delays in downloading and starting playback of the desired content.

With the foregoing in mind, present embodiments are directed to a streaming media system and streaming format that enables improved streaming performance over existing streaming formats (e.g., DASH, HLS) by way of a streamlined manifest and schema. In certain embodiments, the manifest may be a JSON manifest and the schema may be a JSON schema. The following discussion of the JSON manifest is meant to be exemplary, and the foregoing principles and techniques are applicable to other types of manifests, including binary formats. JSON is widely supported across many platforms, and many devices support optimized JSON parsing for enhanced efficiency and performance. Furthermore, while the manifests of other streaming protocols redundantly define certain information (e.g., DRM information, timeline information) for each audio/video segment, the schema of the presently disclosed streaming format includes global objects that define certain unique (e.g., non-redundant, non-duplicative) global parameters that can pertain to any or all of the audio/video segments, along with a corresponding unique identifier to refer to the global object. The schema also includes respective local objects that define local parameters for each of the audio/video segments, including one or more parameters that refer to a global object using the unique identifier of the global object, as opposed to duplicating information of the global object within the audio/video information objects themselves.

In this manner, the manifest of the presently disclosed streaming format demonstrates a substantially smaller file size than corresponding DASH or HLS manifests (e.g., 5× reduction in file size). The manifest of the present approach also demonstrates a substantially faster downloading and processing time compared to DASH or HLS manifests (e.g., 100× decrease in downloading and processing time), with substantially fewer objects being ingested during processing (e.g., 70% fewer objects). As such, the manifest enables a novel streaming format that offers a number of improvements, including reduced delays in beginning playback of requested content, reduced energy utilization, reduced computing resource consumption (e.g., reduced memory utilization, reduced processor utilization), and improved stability.

FIG.1is a diagram of an embodiment of streaming media system10. As illustrated, the streaming media system10includes at least one playback device12that is communicatively coupled to at least one server device14(also referred to herein as simply “server”) via suitable network16. In certain embodiments, the playback device12is a desktop computer, a laptop computer, a smart phone, a television, a set-top box, or another suitable computing device. In certain embodiments, the server14is a stand-alone server or a virtualized server hosted by a remote or on-premises data center. The network16may include a wide-area network (WAN), a local-area network (LAN), a virtual private network (VPN), the Internet, another suitable wired and/or wireless network, or any suitable combination thereof.

For the embodiment illustrated inFIG.1, the playback device12includes at least one processor18(e.g., a central processing unit (CPU), a graphic processing unit (GPU)), at least one memory20(e.g., random access memory (RAM), read-only memory (ROM)), at least one networking interface22(e.g., wired or wireless network interface), at least one input/output (I/O) device24(e.g., display, video output port, speakers, audio output port, touchscreen, keyboard, mouse, Bluetooth or infrared (IR) remote control), and at least one storage26(e.g., a hard disk drive (HDD), a solid-state disk (SSD), flash memory). It may be appreciated that, in certain embodiments, the playback device12may be a television or set-top box having substantially fewer computational resources (e.g., lower power processor18, smaller/slower memory20, limited bandwidth or throughput networking interface22, smaller storage26) compared to other playback devices, such as a desktop computer. Indeed, in certain cases, the limitations of the computational resources of such playback devices may be by design, for example, to reduce manufacturing cost or to limit the power consumption of the playback device and achieve a particular energy usage rating. It may be appreciated that disclosed technique is especially useful for playback devices with such limitations, as it enables reduced computational resource and/or energy usage relative to other streaming formats.

The storage26of the playback device12stores suitable applications or apps that are executed by the processor18to provide desired functionality at the playback device12. For example, the storage26of the playback device12stores a content player28that can be loaded into memory20and executed by the processor18to enable the playback device12to stream audio/video content from the server14. As discussed below, the content player28of the playback device12is capable of receiving and processing JSON manifests to facilitate the playback of streamed audio/video content on the playback device12.

For the embodiment illustrated inFIG.1, the server14may include at least one processor30(e.g., a CPU, a GPU), at least one memory32(e.g., RAM, ROM), at least one networking interface34(e.g., wired or wireless network interface), and at least one storage36(e.g., a HDD, SSD, flash memory). The storage36stores one or more applications that are loaded into the memory32and/or executed by the processor30to enable different functionality discussed herein. For example, as discussed in detail below with respect toFIGS.4and5, in certain embodiments, the storage36of the server14stores a JSON manifest generator38having instructions that cause the processor30to convert the manifests of other streaming formats (e.g., DASH or HLS manifests) into JSON manifests42. As discussed in detail below with respect toFIG.6, in certain embodiments, the storage36of the server14may store a modified streaming encoder40having instructions that cause the processor30to encode source audio/video content into audio segments44and/or video segments46, and to generate corresponding JSON manifests42to facilitate streaming of the content. AlthoughFIG.1illustrates both the JSON manifest generator38and the modified streaming encoder40within the server14, the server14(or another device) may include one without the other. For the illustrated embodiment, in addition to storing the JSON manifests42that are generated by the JSON manifest generator38or the modified streaming encoder40, the storage36also stores the audio segments44and video segments46generated by a streaming encoder (e.g., a standard streaming encoder or the modified streaming encoder40) when encoding the source audio/video content for streaming, as discussed below.

For the embodiment illustrated inFIG.1, the content player28may receive user input (e.g., via the I/O devices24) requesting the playback of particular audio/video content that is hosted by the server14or an affiliated entity (e.g., a content delivery network). In response, the content player28of the playback device12generates and sends to the server14, or an intermediary entity, a request48to stream particular audio/video content to the player. In response to the request, the server14, or the intermediary entity, provides a response50that includes the JSON manifest of the requested audio/video content. As discussed below, the content player28parses the received JSON manifest to ingest a set of objects defining parameters related to downloading, processing, and presenting the audio segments44and/or video segments46of the requested audio/video content. Using the information gleaned from ingestion of the received JSON manifest, the content player28provides one or more requests52for the audio segments44and/or video segments46of the audio/video content, as defined in the JSON manifest. In response to these requests, the server14or the affiliated entity (e.g., a content delivery network) provides responses54including the requested audio segments44and/or video segments46of the content. Additionally, using the information gleaned from ingestion of the JSON manifest, the content player28presents or plays the received audio segments and/or video segments of the content to the user (e.g., via the I/O devices24), in accordance with the parameters defined in the JSON manifest.

FIG.2is a diagram illustrating a schema60of an example embodiment of a manifest62, in accordance with the present technique. For the illustrated embodiment, the manifest62is a JSON manifest and the schema60is a JSON schema, while in other embodiments, other file formats may be used. The example JSON manifest62is associated with and defines parameters for streaming audio/video segments encoded from source audio/video content. As discussed below, in some embodiments, the source audio/video content is first encoded using a standard encoder, such as a DASH encoder, to generate the one or more audio/video segments, as well as a non-JSON manifest, and then the JSON manifest generator38converts the non-JSON manifest into the JSON manifest62. In other embodiments, the source audio/video content is encoded using the modified streaming encoder, which generates the audio/video segments, as well as the JSON manifest62.

For the embodiment illustrated inFIG.2, the JSON schema60of the JSON manifest62includes one or more global timeline objects64and one or more global DRM information objects66. These global objects define global parameter information that can be accessed and used during the playback of any or all of the audio/video segments of the audio/video content. For example, a global timeline object may indicate a timelineId with a value of 1, a timescale value, a start number value, a vector of segments, and a presentation time offset. Another global timeline object with a different timelineId value (e.g., value of 2) may have different values with respect to the timescale, the start number, the vector of segments, and/or the presentation time offset. Similarly, a global DRM information object may indicate a drmInfold with a value of 1 that corresponds to a particular DRM license. Another global DRM information object with a different drmInfold value may have information corresponding to a different DRM license that the global DRM information object with a drmInfold value of 1. In other words, the value of the timelineId and drmInfold may be unique to their respective information with the object. When parsing the JSON manifest62, the content player28may look up the timeline information corresponding to a global timeline object with a timelineId with value 1. Similarly, the content player28may look up DRM information corresponding to a global DRM information object with drmInfold with value 1. It may be appreciated that, in other embodiments, the JSON schema60may define other global objects storing other global parameter information (e.g., adaptation information, resolution information, high dynamic range (HDR)/standard dynamic range (SDR) information, advertisement information) that can be accessed and used to facilitate the playback of any or all of the audio/video segments of the associated audio/video content. The JSON schema60also defines one or more local audio segment information objects68and/or one or more local video segment information objects70, including a respective local audio segment information object for each audio segment of the audio/video content, and a respective local video segment information object for each video segment of the audio/video content. The local audio/video segment information objects define local or non-global parameter information that is accessed and used only during the playback the particular corresponding audio/video segment of the audio/video content.

As noted above, DASH and HLS manifests include a substantial amount of redundant information that detrimentally results in increased file size, increased downloading and parsing time, and has increased a number of objects ingested during parsing. It is presently recognized that a substantial portion of the redundant information of DASH and HLS manifests results from certain parameters or sets of parameters (e.g., DRM information, timelines) being separately defined within each audio segment information section and each video segment information section of the manifest, even when the parameter names and values are identically defined within each of these sections. In contrast, in present embodiments, the JSON schema60of the JSON manifest62enables a substantial reduction in redundant data using the global objects and their corresponding unique identifiers. For example, in the context where a standard encoder is used to generate a non-JSON manifest (seeFIG.4), rather than defining identical local parameter information with respect to each local audio segment information object and/or each local video segment information object, in the JSON schema60, certain duplicative parameter information is instead replaced by a global identifier, wherein the global identifier (e.g., timelineId or drmInfold) is assigned a unique value. Additionally, audio segment information within a DASH or HLS manifest would have portions of the local audio segment information object replaced by a corresponding one or more global identifiers (e.g., timelineId or drmInfold), and video segment information within a DASH or HLS manifest would have portions of the local video segment information object replaced by a corresponding one or more global identifiers (e.g., timelineId or drmInfold). Each global identifier is defined to include at least one parameter (e.g., an identifier parameter) having a value that corresponds and refers to a global object within the JSON schema60, which enables the content player28to retrieve the desired parameter information from the definition of the referenced global object. As such, the JSON manifest62demonstrates a substantial reduction in file size, a substantial reduction in downloading and parsing time, and a substantial reduction in the number of objects ingested, as compared to DASH or HLS manifests.

For the embodiment illustrated inFIG.2, the global timeline objects64of the JSON schema60include one or more global audio timeline objects72and one or more global video timeline objects74. Each of the global audio timeline objects72defines a number of global parameters, including: a respective audio timeline identifier76(e.g., timelineId) uniquely identifying the audio timeline object, a respective timescale parameter78that defines (e.g., in milliseconds) the length or duration of the audio segments associated with the audio timeline object, a respective start number parameter80that defines the number or audio segment at which the playback begins, a respective time offset parameter82that defines whether the audio segments associated with the audio timeline object are to be temporally shifted during playback, and a respective array of audio segment identifiers84indicating the audio segments that are associated with the audio timeline object. For example, in certain embodiments, the array of audio segment identifiers84may be an array storing a set of audio segment identifiers, wherein each audio segment identifier uniquely refers to a corresponding local audio segment information object of the local audio segment information objects68.

Each of the global video timeline objects74defines a number of global parameters, including: a respective video timeline identifier86(e.g., timelineId) uniquely identifying the video timeline object, a respective timescale parameter88that defines (e.g., in milliseconds) the length or duration of the video segments associated with the video timeline object, a respective start number parameter90that defines the number or video segment at which the playback begins, a respective time offset parameter92that defines whether the video segments associated with the video timeline object are to be temporally shifted during playback, and a respective array of video segment identifiers94indicating the video segments that are associated with the video timeline object. For example, in certain embodiments, the array of video segment identifiers94may be an array storing a set of video segment identifiers, wherein each video segment identifier uniquely refers to a corresponding local video segment information object of the local video segment information objects70. It may also be appreciated that the content player28can also infer additional parameter information based on the parameters and values defined in the JSON schema60, such as determining a frame rate of a video segment based on the timescale parameter (e.g., a timescale of 24000 results in a 24 frames per second (fps) framerate).

For the embodiment illustrated inFIG.2, each of the global DRM information objects66of the JSON schema60defines global DRM information associated with one or more of the audio/video segments of the audio/video content. Each of the global DRM information objects66define a number of global parameters, including a respective DRM information identifier96that uniquely identifies the DRM information object, as well as a respective protection system specific header (PSSH) parameter98and a respective encryption key identifier parameter100(KID) that define suitable values used by an example DRM technique. It may be appreciated that, in other embodiments, any other suitable DRM parameters may be defined within the global DRM information objects66, in accordance with the present disclosure.

For the embodiment illustrated inFIG.2, each of the local audio segment information objects68of the JSON schema60defines respective local parameters of an associated audio segment of the audio/video content. These local parameters include a respective audio segment identifier102that uniquely identifies the audio segment information object within the schema, a respective bandwidth parameter104that defines the bandwidth of the associated audio segment, a respective codecs parameter106that defines the codec used to encode and decode the associated audio segment, one or more respective uniform resource locator (URL) parameters108that define a location of the associated audio segment or other resources (e.g., templates), a respective language parameter110defining a language of the associated audio segment, a respective channel count parameter112that defines the number of audio channels of the associated audio segment. The local parameters also include a respective audio timeline identifier114that uniquely refers to the audio timeline identifier76of a global audio timeline object that corresponds to the associated audio segment, as well as a respective DRM information identifier116that uniquely refers to the DRM information identifier96of a global DRM information object that corresponds to the associated audio segment.

For the embodiment illustrated inFIG.2, each of the local video segment information objects70of the JSON schema60defines respective local parameters of an associated video segment of the audio/video content. These local parameters include a respective video segment identifier118that uniquely identifies the video segment information object within the schema, a respective bandwidth parameter120that defines the bandwidth of the associated video segment, a respective codecs parameter122that defines the codec used to encode and decode the associated video segment, one or more respective URL parameters124that define a location of the associated video segment or other resources (e.g., templates), a respective framerate parameter126defining a framerate of the associated video segment, a respective dimensions parameter128that defines the vertical and horizontal dimensions of the associated video segment. The local parameters also include a respective video timeline identifier130that uniquely refers to the video timeline identifier86of a global video timeline object that corresponds to the associated video segment, as well as a respective DRM information identifier132that uniquely refers to the DRM information identifier96of a global DRM information object that corresponds to the associated video segment.

FIG.3is a flow diagram illustrating an embodiment of a process140in which the content player28of the playback device12processes a JSON manifest to facilitate playback of audio/video content. The process140is discussed with reference to elements illustrated inFIGS.1and2. The process140may be stored as instructions in the storage26and/or memory20and executed by the processor18of the playback device12. In other embodiments, the process140may include additional actions, fewer actions, repeated actions, actions performed in a different sequence, and so forth, in accordance with the present disclosure.

For the embodiment illustrated inFIG.3, the process140begins with the processor18receiving (block142) input (e.g., via the I/O devices24) indicating that the user of the playback device desires to stream audio/video content. In response, the processor18requests and receives (block144), from the server14, a JSON manifest for the audio/video content. The processor18then parses the received JSON manifest to ingest a set of objects (e.g., JavaScript objects) defining parameters associated with the downloading, processing, and presenting the audio/video content (block146). As discussed with respect toFIG.2, in some embodiments, the ingested objects include global audio timeline objects, global video timeline objects, global DRM information objects, local audio segment information objects, and/or local video segment information objects, or a combination thereof.

For the embodiment illustrated inFIG.3, the process140continues with the processor18selecting (block148) a local audio segment information object, a local video segment information objection, or a combination thereof.

The processor18determines (block150), from the selected object, at least one global object related to the local audio segment information object and/or related to the local video segment information object. For example, the processor18may determine, within the set of objects ingested from the JSON manifest, a global DRM information object referenced by the local audio segment information object or referenced by the local video segment information object. To do so, the processor18may determine the DRM information identifier116from the local audio segment information object, and/or the DRM information identifier132from the local video segment information object, and use this DRM information identifier to retrieve one or more corresponding global DRM information objects from the ingested set of objects.

Similarly, the processor18(block150) may determine a global audio timeline object based on the audio timeline identifier included in the local audio segment information object and/or a global video timeline object based on the video timeline identifier included in the local video segment information object. Based on the determined global audio timeline object or the global video timeline object, the processor18may then (block152) select a first audio segment associated with the global audio timeline object based on the respective start number parameter80and the respective array of audio segment identifiers84associated with the global audio timeline object, or select a first video segment associated with the global video timeline object based on the respective start number parameter90and the respective array of video segment identifiers94associated with the selected global video timeline object, or both.

For the embodiment illustrated inFIG.3, the process140continues with the processor18utilizing (block154) parameters defined by the at least one global object, and by one or both of the local audio segment information object and the video segment information object, to retrieve, process, and present the selected audio segment, or the selected video segment, or a combination thereof. For example, this may include using the DRM information defined by a related global DRM information object to process the selected audio segment or the selected video segment for presentation. As indicated by the arrow156, the processor18then returns to block148, to select the next local audio segment information object and the next local video segment information objection (e.g., as indicated by an audio timeline object and/or a video timeline object), and then repeats the actions of blocks150,152, and154until playback of the audio/video content is completed or terminated by the user.

FIG.4is a diagram illustrating an embodiment of a hybrid implementation160of the streaming media system10. For the hybrid implementation160ofFIG.4, audio/video content may be streamed to the playback device12using a non-JSON manifest162(e.g., DASH manifests, HLS manifests) or using a JSON manifest164that is generated from the non-JSON manifest162, which enables enhanced flexibility. To prepare audio/video content for streaming, a source audio/video file166is provided as input to a standard streaming encoder168, such as a Moving Picture Expert Group (MPEG) DASH encoder. The standard streaming encoder168includes computer-implemented instructions to translate the source audio/video file166into a set of audio segments170and a set of video segments172, as well as at least one non-JSON manifest162, all of which are suitably saved to the storage36. At this point, a content player28is capable of downloading the non-JSON manifest162and playing back the audio segments170and the video segments172of the content, in accordance with the corresponding protocol (e.g., DASH, HLS).

For the embodiment illustrated inFIG.4, the illustrated content player28of the playback device12may be configured to preferentially or only request the JSON manifest164for the audio/video content in order to realize the benefits of the JSON manifest set forth above. In certain embodiments, the JSON manifest generator38may be automatically executed to process the non-JSON manifest162in response to the non-JSON manifest162being created or modified, and the resulting JSON manifest164may be stored within the storage36for retrieval by the playback device12. In other embodiments, the JSON manifest generator38may instead be executed to process the non-JSON manifest162in an on-demand manner, and provide the resulting JSON manifest164to the playback device12in response to the playback device12requesting streaming of the audio/video content.

FIG.5is a flow diagram illustrating an embodiment of a process180by which the JSON manifest generator38processes and converts a non-JSON manifest162(e.g., DASH manifests, HLS manifests) into the JSON manifest164. The process180is discussed with reference to elements illustrated inFIGS.1,2, and4. The process180may be stored as instructions in the storage36and/or memory32, and executed by the processor30of the server14. In other embodiments, the process180may include additional actions, fewer actions, repeated actions, actions performed in a different sequence, and so forth, in accordance with the present disclosure.

For the embodiment illustrated inFIG.5, the process180begins with the processor30receiving (block182) the non-JSON manifest162of the audio/video content for conversion into the JSON manifest164. The processor30then parses (block184) the non-JSON manifest162to ingest objects defining parameters (e.g., DRM information, timeline information, etc.) of each audio segment and each video segment of the audio/video content. The processor30continues by identifying (block186), within the ingested objects, at least one parameter that is redundantly defined for more than one of the audio segments or video segments. For example, as discussed above, the processor30may determine that the parameters of the ingested objects define the same DRM information and/or the same timeline information for more than one of the audio or video segments of the audio/video content. In certain embodiments, the JSON manifest generator38may apply artificial intelligence (AI) models or rules-based techniques to automatically identify redundant parameters within the ingested objects.

For the embodiment illustrated inFIG.5, the process180continues with the processor30generating (block188), in the JSON schema60, a global object defining the at least one parameter identified in block186, along with a corresponding unique identifier of the global object. In certain embodiments, the processor30generates multiple global objects, each defining at least one of the parameters identified in block186, along with a respective unique identifier. The processor30also generates (block190), in the JSON schema60, at least one local object (e.g., a local audio segment information object, a local video segment information object) defining an identifier parameter (e.g., a DRM information identifier, a timeline identifier) that references the global object generated in block188using the corresponding unique identifier of the global object. In certain embodiments, the processor30generates multiple local objects that respectively reference one or more global objects using the corresponding unique identifier of the global objects. The processor30generally keeps track of the unique identifiers and their respective relationships with the unique identifiers as they are generated to ensure that each unique identifier refers to only one global object, and that there are not multiple identifiers that refer to the same global object. The process180concludes with the processor30outputting (block192) the JSON schema60as the JSON manifest164of the audio/video content, wherein the JSON objects and parameters defined within the JSON schema60are written to a file and stored within the storage36of the server14, or provided directly to the playback device12in response to receiving a request to stream the audio/video content.

In an example related to DRM information, in block184, the processor30extracts the respective DRM information of each of the audio/video segments from the non-JSON manifest162, wherein certain audio/video segments share the same DRM information (e.g., same PSSH and KID values). In block186, the processor30identifies this redundant DRM information. Then, in block188, the processor30eliminates this redundancy by generating, in the JSON schema60, respective global DRM information objects for each unique set of DRM information (e.g., each unique PSSH98and KID100), and defining a corresponding unique identifier (e.g., DRM information identifier96) to refer to each of these global DRM objects. Then, in block190, the processor30generates, in the JSON schema60, a respective DRM information identifier parameter116for each local audio segment information object, and a respective DRM information identifier parameter132for each local video segment information object, and sets appropriate values to these parameters to refer to the corresponding global DRM information object. In an aspect, for each local audio segment information object, the DRM information (e.g., PSSH98and KID100) is replaced by the DRM information identifier parameter116that references a global DRM information object containing the DRM information.

In another example related to timeline information, in block184, the processor30extracts the respective timeline information of each of the audio/video segments from the non-JSON manifest162, wherein certain audio/video segments share the same timeline information (e.g., same set of timescale, start number, time offset values, audio/video segments). In block186, the processor30identifies this redundant timeline information. Then, in block188, the processor30eliminates the redundancy by generating, in the JSON schema60, respective global timeline objects for each unique set of timeline information (e.g., each unique set of timescale, start number, time offset values, audio/video segments), and defining a corresponding unique identifier (e.g., audio timeline identifier76, video timeline identifier86) to refer to each of these global timeline objects. Then, in block190, the processor30generates, in the JSON schema, a respective audio timeline identifier parameter114for each local audio segment information object, and a respective video timeline identifier parameter130for each local video segment information object, and sets appropriate values to these parameters to refer to the corresponding global timeline object.

FIG.6is a diagram illustrating an embodiment of an alternative implementation200of the streaming media system10, in which audio/video content is streamed to the playback device12using a JSON manifest164that is generated during encoding. To prepare audio/video content for streaming, the source audio/video file166is provided as input to the modified streaming encoder40. The modified streaming encoder40includes computer-implemented instructions to translate the source audio/video file166into a set of audio segments170and a set of video segments172, and to generate the JSON manifest164, which are all suitably saved to the storage36. As the JSON manifest164is generated, the modified streaming encoder40generates respective global objects that store each unique set of timeline and DRM information and/or other repetitious information. The modified streaming encoder40keeps track of the respective relationships with the associated identifiers in order to avoid having multiple identifiers refer to the same global object. The modified streaming encoder40also generate local audio segment information objects and local video segment information objects. The local audio segment information objects and local video segment information objects may include one or more global object identifiers (e.g., DRM information identifiers, timeline information identifiers) that refer to their respective global objects. At this point, the content player28is capable of downloading the JSON manifest164and playing back the audio segments170and/or video segments172of the content in accordance with the JSON manifest164, as discussed above with respect toFIGS.1and2. As such, in contrast to the hybrid implementation160ofFIG.4, the alternative implementation200ofFIG.6does not involve the translation of manifests of other streaming protocols (e.g., DASH, HLS). However, the aforementioned benefits of the JSON manifest164(e.g., smaller manifest file size, less or no redundant information, fewer objects to ingest, etc.) are afforded to the content player28of the playback device12during playback of the audio/video content.

The technical effects of the present disclosure include a streaming media system and streaming format that enable improved streaming performance over existing streaming formats (e.g., DASH, HLS) through the use of a streamlined manifest having a streamlined schema. While the manifests of other streaming protocols redundantly define certain information (e.g., DRM information, timeline information) for each audio/video segment, the schema includes global objects that define certain unique (e.g., non-redundant, non-duplicative) global parameters that can pertain to any or all of the audio/video segments, along with a corresponding unique identifier to refer to each global object. The schema also includes respective local audio/video information objects that define local parameters for each of the audio/video segments, including one or more local parameters that refer to a global object using the unique identifier of the global object, as opposed to duplicating information of the global object within the audio/video information objects themselves. As such, the disclosed manifest demonstrates a substantially smaller file size than corresponding DASH or HLS manifests (e.g., 5× reduction in file size). The disclosed manifest also demonstrates a substantially faster downloading and processing time compared to DASH or HLS manifests (e.g., 100× decrease in downloading and processing time), with substantially fewer objects being ingested during processing (e.g., 70% fewer objects). As such, the disclosed manifest enables a novel streaming format that offers a number of improvements, including reduced delays in beginning playback of requested content, reduced energy utilization, reduced computing resource consumption (e.g., reduced memory utilization, reduced processor utilization), and improved stability.