TW201603568A - Media presentation description signaling in typical broadcast content - Google Patents

Abstract

A device may comprise a processor that may be configured to receive an audio bitstream in a single multiplex. The device may determine languages included in the single multiplex. The device may determine codecs contained in the single multiplex. The device may signal codecs used by the Content Component. The device may receive instructions from the Content Component. The device may signal multi-channel audio. The device may signal sampling rates.

Description

Media presentation description messaging in typical broadcast content

Cross-reference to related applications

The present application claims the benefit of U.S. Provisional Patent Application No. 62/019,784, filed on Jul.

In recent years, "on the cloud" (OTT) streaming has become a delivery medium. OTT streaming uses the Internet as a delivery medium. Network performance has evolved to enable video delivery over the Internet. The media presentation description messaging can be used to process broadcast content in Dynamic Adaptive Streaming (DASH) via HTTP.

A device can include a processor configured to receive multimedia presentation description (MPD) information related to content. The processor can determine that the content includes a multiplex representation based on the MPD information, the multiplex representation including a closed caption component that is multiplexed with at least one of an audio component or a video component. The processor can determine whether the closed caption component is a CEA-608 closed caption component or a CEA-708 closed caption component. The processor can determine if the device supports display of the closed caption component. The processor can request the multiplex representation and receive a content segment that includes the multiplex representation.

A device can include a processor configured to receive MPD information related to content. The processor can determine that the content includes a multiplex representation based on the MPD information, the multiplex representation including two audio components that are multiplexed together, the audio components being encoded according to different audio codecs. The two audio components have different languages. The processor can determine the language of the at least one audio component. The processor can determine if the two audio codecs are supported. The processor can request the multiplex representation and receive a content segment that includes the multiplex representation.

A device can include a processor configured to receive MPD information related to content. The processor can determine that the content includes a multiplex representation based on the MPD information, the multiplex representation including a segmented packet identifier included in the multiplex representation. This segment can be a video component. The processor can determine a track identifier of at least one of a video component and an audio component in the segment. The processor can determine the earliest presentation time (EPT) of the video component or audio component in the segment. The processor can determine the relative offset of the audio components in the segment from the EPT of the segmented video component. The processor can request the multiplex representation and receive a content segment that includes the multiplex representation.

The illustrative embodiments are now described in detail with reference to the drawings. While this description provides a detailed example of possible implementations, it should be noted that the details are illustrative and not limiting the scope of the application.

FIG. 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content via sharing of system resources, including wireless bandwidth. For example, the communication system 100 can use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA). Single carrier FDMA (SC-FDMA) and the like.

As shown in FIG. 1A, communication system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (collectively or collectively referred to as WTRUs 102), and radio access network (RAN) 103/104. /105, core network 106/107/109, public switched telephone network (PSTN) 108, internet 110 and other networks 112, but it is understood that any number of WTRUs, base stations, networks, and/or Network component. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, mobile phones, personal digits Assistants (PDAs), smart phones, laptops, portable Internet devices, personal computers, wireless sensors, consumer electronics, and more.

Communication system 100 can also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b can be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (eg, the core network 106) Any type of device of /107/109, Internet 110 and/or network 112). For example, base stations 114a, 114b may be base station transceiver stations (BTS), node B, eNodeB, home node B, home eNodeB, website controller, access point (AP), wireless router, and the like. Although base stations 114a, 114b are each depicted as a single component, it is understood that base stations 114a, 114b can include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC) ), relay nodes, etc. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as cells (not shown). Cells can also be divided into cell sectors. For example, a cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In another embodiment, base station 114a may use multiple input multiple output (MIMO) technology, and thus multiple transceivers may be used for each sector of the cell.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the null intermediate plane 115/116/117, which may be any suitable wireless communication link. Road (for example, radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The null intermediaries 115/116/117 can be established using any suitable radio access technology (RAT).

More specifically, as noted above, communication system 100 can be a multiple access system and can utilize one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 103/104/105 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA ( WCDMA) to establish an empty intermediate plane 115/116/117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or Advanced LTE (LTE-A) to establish an empty intermediate plane 115/116/117.

In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement such as IEEE 802.16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS) -2000), Temporary Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN) .

The base station 114b in FIG. 1A may be, for example, a wireless router, a home Node B, a home eNodeB, or an access point, and may use any suitable RAT for facilitating in, for example, a business district, a home, a vehicle, a campus. A wireless connection to a local area of the class. In one embodiment, base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, base station 114b and WTRUs 102c, 102d may use a cellular based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. (femtocell). As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, base station 114b can access Internet 110 without going through core network 106/107/109.

The RAN 103/104/105 can communicate with a core network 106/107/109, which can be configured to voice, data, applications, and/or voice over the Internet Protocol (VoIP) The service provides any type of network to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 can provide call control, billing services, mobile location based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high level security functions such as users. Certification. Although not shown in FIG. 1A, it can be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 can communicate directly or indirectly with other RANs that use the RAN 103/104/105 The same RAT or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may employ E-UTRA radio technology, the core network 106/107/109 may also be in communication with other RANs (not shown) that use GSM radio technology.

The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include a circuit switched telephone network that provides Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use public communication protocols, such as transmissions in the Transmission Control Protocol (TCP)/Internet Protocol (IP) Internet Protocol Suite. Control Protocol (TCP), User Packet Protocol (UDP), and Internet Protocol (IP). The network 112 can include wired or wireless communication networks that are owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may use the same RAT as RAN 103/104/105 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, ie, the WTRUs 102a, 102b, 102c, 102d may include different wireless networks for use via different wireless links Multiple transceivers for communication. For example, the WTRU 102c shown in FIG. 1A can be configured to communicate with a base station 114a that can use a cellular-based radio technology and with a base station 114b that can use an IEEE 802 radio technology.

FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keyboard 126, a display/touchpad 128, a non-removable memory 130, and a removable Memory 132, power source 134, global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be understood that the WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments. Likewise, embodiments contemplate nodes (e.g., but not limited to transceiver stations (BTS), Node B, website controllers, access points (APs), home nodes that base stations 114a and 114b and/or base stations 114a and 114b may represent. B. Evolved Home Node B (eNode B), Home Evolved Node B (HeNB), Home Evolved Node B Gateway, and Proxy Node, etc. may include the elements described in FIG. 1B and described herein. Some or all.

The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with the DSP core, a controller, a micro control , dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to the transmit/receive element 122. Although processor 118 and transceiver 120 are depicted as separate components in FIG. 1B, processor 118 and transceiver 120 may be integrated together into an electronic package or wafer.

The transmit/receive element 122 can be configured to transmit signals to or from the base station (e.g., base station 114a) via the null planes 115/116/117. For example, in one embodiment, the transmit/receive element 122 can be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 can be a transmitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit/receive element 122 can be configured to transmit and receive both RF signals and optical signals. It will be appreciated that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals.

Moreover, although the transmit/receive element 122 is depicted as a single element in FIG. 1B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and/or receiving wireless signals via the null intermediaries 115/116/117.

The transceiver 120 can be configured to modulate a signal to be transmitted by the transmit/receive element 122 and configured to demodulate a signal received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keyboard 126, and/or a display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and User input data can be received from the above device. The processor 118 can also output user profiles to the speaker/microphone 124, the keyboard 126, and/or the display/trackpad 128. In addition, the processor 118 can access information from any type of suitable memory and store the data in any type of suitable memory, such as non-removable memory 130 and/or removable. Memory 132. The non-removable memory 130 may include random access memory (RAM), read only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a Subscriber Identity Module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access data from a memory that is not physically located on the WTRU 102 (e.g., on a server or a home computer (not shown), and store data in the memory. .

The processor 118 can receive power from the power source 134 and can be configured to distribute the power to other elements in the WTRU 102 and/or to control power to other elements in the WTRU 102. Power source 134 can be any device suitable for powering WTRU 102. For example, the power source 134 may include one or more dry cells (nickel cadmium (NiCd), nickel zinc (NiZn), nickel hydrogen (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a GPS chipset 136 that may be configured to provide location information (eg, longitude and latitude) regarding the current location of the WTRU 102. Additionally or alternatively to the information from GPS chipset 136, WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via null intermediaries 115/116/117, and/or based on two or more The timing of the signals received by neighboring base stations to determine their position. It will be appreciated that the WTRU may use any suitable location determination method to obtain location information while remaining consistent with the implementation.

The processor 118 can also be coupled to other peripheral devices 138, which can include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, peripheral device 138 may include an accelerometer, an electronic compass (e-compass), a satellite transceiver, a digital camera (for photo or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, and a hands free Headphones, Bluetooth® modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, and more.

1C is a system diagram of RAN 103 and core network 106, in accordance with an embodiment. As described above, the RAN 103 can use UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c via the null plane 115. The RAN 103 can also communicate with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node Bs 140a, 140b, 140c, each of which may include one or both for communicating with the WTRUs 102a, 102b, 102c via the null plane 115. Multiple transceivers. Each of Node Bs 140a, 140b, 140c can be associated with a particular cell (not shown) in RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node Bs and RNCs while remaining consistent with the implementation.

As shown in FIG. 1C, Node Bs 140a, 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, 140c may communicate with respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b can communicate with each other via the Iur interface. Each of the RNCs 142a, 142b can be configured to control the respective Node Bs 140a, 140b, 140c to which they are connected. In addition, each of the RNCs 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements is described as being part of core network 106, it should be understood that any of these elements may be owned and/or operated by other entities than the core network operator.

The RNC 142a in the RAN 103 can be connected to the MSC 146 in the core network 106 via the IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and conventional route communication devices.

The RNC 142a in the RAN 103 can also be connected to the SGSN 148 in the core network 106 via the IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

As noted above, the core network 106 can also be connected to the network 112, which can include other wired or wireless networks that other service providers own and/or operate.

FIG. 1D is a system diagram of RAN 104 and core network 107 in accordance with an embodiment. As described above, the RAN 104 can use E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c via the null plane 116. The RAN 104 can also communicate with the core network 107.

The RAN 104 may include eNodeBs 160a, 160b, 160c, but it will be appreciated that while remaining consistent with the embodiments, the RAN 104 may include any number of eNodeBs to remain consistent with the implementation. Each of the eNodeBs 160a, 160b, 160c can include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the null plane 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a.

Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, use in uplink and/or downlink Scheduled, etc. As shown in FIG. 1D, the eNodeBs 160a, 160b, 160c can communicate with each other via the X2 interface.

The core network 107 shown in FIG. 1D may include a mobility management gateway (MME) 162, a service gateway 164, and a packet data network (PDN) gateway 166. While each of the above elements is described as being part of core network 107, it should be understood that any of these elements may be owned and/or operated by other entities than the core network operator.

The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface and may act as a control node. For example, MME 162 may be responsible for authenticating the users of WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular service gateway during initial connection of WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide control plane functionality for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA.

Service gateway 164 may be connected to each of eNodeBs 160a, 160b, 160c in RAN 104 via an S1 interface. The service gateway 164 can typically route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The service gateway 164 may also perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging, managing and storing the WTRUs 102a, 102b, 102c when the downlink information is available to the WTRUs 102a, 102b, 102c Context and so on.

The service gateway 164 may also be coupled to the PDN 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate the WTRUs 102a, 102b, 102c and IP enabling devices. Communication between.

The core network 107 can facilitate communication with other networks. For example, core network 107 may provide WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as PSTN 108, to facilitate communications between WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between core network 107 and PSTN 108, or may be in communication with the IP gateway. In addition, core network 107 can provide access to network 112 to WTRUs 102a, 102b, 102c, which can include other wired or wireless networks that are owned and/or operated by other service providers.

FIG. 1E is a system diagram of RAN 105 and core network 109, in accordance with an embodiment. The RAN 105 may be an Access Service Network (ASN) that utilizes IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c via the null plane 117. As will be described further below, the communication links between the different functional entities in the WTRUs 102a, 102b, 102c, RAN 105, and core network 109 may be defined as reference points.

As shown in FIG. 1E, the RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182, although it will be appreciated that the RAN 105 may include any number of base stations and ASN gates while remaining consistent with the implementation. Road. Each of the base stations 180a, 180b, 180c can be associated with a particular cell (not shown) in the RAN 105 and can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the null mediation plane 117. Device. In one embodiment, base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, base station 180a can use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a. Base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 can act as a traffic aggregation point and can be responsible for paging, caching user profiles, routing to the core network 109, and the like.

The null interfacing plane 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c can establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 can be defined as an R2 reference point that can be used for authentication, authorization, IP host configuration management, and/or mobility management.

The communication link between each of the base stations 180a, 180b, 180c can be defined to include an R8 reference point for facilitating the agreement between the WTRU handover and the data transfer between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include an agreement to facilitate mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

As shown in FIG. 1E, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined, for example, as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, Accounting (AAA) server 186, and a gateway 188. While each of the above elements is described as being part of core network 109, it will be understood that any of these elements may be owned and/or operated by other entities than the core network operator.

The MIP-HA may be responsible for IP address management and may cause the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 can provide the WTRUs 102a, 102b, 102c with access to a packet switched network (e.g., the Internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 can be responsible for user authentication and support for user services. Gateway 188 facilitates interworking with other networks. For example, gateway 188 can provide WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. In addition, gateway 188 provides access to network 112 to WTRUs 102a, 102b, 102c, which may include other wired or wireless networks that are owned and/or operated by other service providers.

Although not shown in FIG. 1E, it should be understood that the RAN 105 can be connected to other ASNs and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include a protocol for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and other ASNs. The communication link between core network 109 and other core networks may be defined as an R5 reference point, which may include protocols for facilitating interaction between the home core network and the visited core network.

"On the Cloud" (OTT) streaming can use the Internet as a delivery medium. Hardware performance has evolved to create a wide range of video capabilities. The range of video functions can range from mobile devices to Internet set-top boxes (STBs) to network TVs. Network performance has evolved to enable high quality video delivery over the Internet.

A "hidden" network can be controlled by a multi-system operator (MSO). The Internet can be a "best effort service" environment. In a "best effort" environment, bandwidth and latency can be changed (eg, constantly changing). In a mobile network, network conditions may be unstable. Dynamic adaptation to network changes, for example, can provide a tolerable user experience in an unstable mobile network.

Adaptive streaming can be thought of as similar to HTTP streaming. User Packet Protocol (UDP) can be used for Internet video streaming. HTTP streaming can be used for Internet video streaming. HTTP usage for Internet video streaming is attractive and scalable, for example, due to the existing HTTP infrastructure. Existing HTTP infrastructures may include, for example, one or more content distribution networks (CDNs) as well as HTTP support prevalent on multiple platforms and devices. HTTP streaming usage for Internet video streaming is attractive, for example, due to firewall penetration. The firewall may not allow UDP traffic. Video via HTTP may be available behind a firewall. HTTP streaming may be suitable for rate adaptive streaming.

For example, in HTTP adaptive streaming, an asset can be segmented by a virtual segment or entity. For example, in HTTP adaptive streaming, resources can be published to the CDN. Wisdom can exist on the client side (for example, DASH client). The client may acquire knowledge of other published codes (eg, representations), for example, via a media presentation description (MPD) file. The client can obtain a way to construct a URL to download segments from known representations. The adaptive bit rate (ABR) client can observe network conditions. The ABR client can determine which combination of bit rate, resolution, etc. can provide the best quality of experience on the client device at the example time. The ABR client can determine the best URL to use. For example, when the ABR client determines the best URL to use, the ABR client can issue an HTTP GET (HTTP Get) request to download the segment.

DASH can be built on top of the HTTP/TCP/IP stack. DASH may define a segmentation format for a manifest format (eg, a media presentation description (MPD)), and/or an MPEG-2 transport stream and/or an ISO base media file format. DASH defines a set of quality metrics at the network, at the user end, at the media presentation level, and the like. This set of quality metrics enables an interactive way of monitoring quality of experience (QoE) and quality of service (QoS).

Representation is the core concept of DASH. Represents a single encoded version of the entire resource. The representation can be a single encoded version of a subset of the entire set of components. For example, the representation may be an ISO-BMFF including 2.5 Mbps 720p AVC video that is not multiplexed and/or a separate ISO-BMFF representation in different languages for 96 Kbps MPEG-4 AAC audio. DASH can provide an unmultiplexed representation of the audio and a separate unmultiplexed representation for the video. A single transport stream that includes two or more video, audio, and/or subtitles can be a single multiplex representation. For example, the combined structure may include video and English audio as a single multiplex representation, and Spanish and Chinese audio tracks, for example, as separate unmultiplexed representations.

A segment can be the smallest single addressable unit of media material. A segment can be an entity that can be downloaded using a URL advertised via MPD. For example, the media segment can be a four second live commercial portion that begins at play time 0:42:38, ends at 0:42:42, and is available within a three minute time window. The media segmentation can be a complete on-demand movie available during the entire license period of the movie.

The MPD can be an XML file. The MPD can be an XML file that can advertise the available media. The MPD can provide information requested by the client to select representations, make appropriate decisions, and/or recover segments from the network. The MPD can be independent of the segmentation. The MPD can signal the requested characteristics to determine if the representation can be successfully played. The MPD can signal the functional characteristics (eg, whether the segmentation begins at a random access point). The MPD can describe the full presentation using, for example, a hierarchical data model.

The representation can be the lowest conceptual level of the hierarchical data model. The MPD can, for example, transmit information by signal at the lowest level of the hierarchical data. For example, the information transmitted by the signal may include a bandwidth and/or a codec that can be used for successful presentation and/or a manner of constructing a URL for accessing the segment. Additional information can be provided at the lowest level of conception of hierarchical data, such as trick mode, random access information, layer and view information for scalable and multi-view codecs, and general-purpose solutions that can be supported by the client that wishes to play the specified representation and many more.

DASH provides flexible URL construction capabilities. A single piece of each segmented URL can provide a rigid URL construction function. A single single piece per segment URL is possible in DASH. DASH allows dynamic construction of URLs. DASH allows dynamic construction of URLs, for example, by combining portions of URLs (eg, base URLs) that appear at different levels of the hierarchical data model. For example, if a multi-base URL is used with a segment requested from one or more locations, the segment may have multi-path functionality. Multipathing improves performance and reliability.

For example, if short segments are used, the URL list and byte range can reach thousands of elements per representation. DASH allows the use of predefined variables (eg, number of segments, segmentation time, etc.). DASH allows the use of printf-style syntax to quickly construct URLs that use templates. Multiple segments can be listed as all segments (eg, seg_00001.ts (segment_00001.ts), seg_00002.ts, ..., seg_03600.ts). For example, if it cannot be recovered at the time the MPD is acquired, the multiple segments can be represented as a single line (eg, seg_$Index%05$.ts (segment_$index%05$.ts)). Due to the efficiency of the template, multi-segment representations can be useful for using the template.

For example, in the absence of multiplex, the adaptive set may be the same resource and/or different representation groups of the same component. Representations in an adaptive collection (eg, all representations) can render the same content. The client can switch between representations in the adaptive set.

In one example, the adaptive set can be an aggregation of ten representations of video encoded at different bit rates and/or resolutions. For example, when presenting the same content to a viewer, the switching of the representation can occur in segments and/or sub-segments. For example, under certain segmentation level constraints, seamless representation switching is possible. Segmentation level restrictions can be used in practical applications (eg, DASH profiles and DASH subsets used by multiple SDOs). Segmentation level restrictions can be applied to representations in an adaptive collection.

A period can be a time-limited subset of presentations. The adaptive set can be available during this period. The adaptive set at different periods may include different representations (eg, according to codecs, bit rates, etc.). The MPD can include a single cycle for the entire duration of the resource. For example, a period can be used for tagging, where a separate cycle is dedicated to some resources and/or advertisements.

The MPD can be an XML file that presents a hierarchy. This level may, for example, begin with global presentation level characteristics (eg, timing) and continue with periodic level characteristics and/or adaptive sets available for the period. Indicates the lowest level that can be at this level.

DASH, for example, may use a simplified version of XLink (X Link) to allow for immediate loading of a portion of the MPD (eg, cycles) from a remote location. For example, in an ad insertion, the precise timing of the ad insertion can be known in advance, and the ad server can instantly determine the exact ad.

The MPD can be dynamic or static. Dynamic MPD can vary. The dynamic MPD can be reloaded periodically by the client. Static MPD can be valid for the entire presentation. Static MPD can be used in VoD applications. Dynamic MPDs are available, for example, for on-site and PVR applications.

The media segmentation can be a time-limited portion of the representation. The media segmentation can have approximately a segmentation duration that can occur in the MPD. The segmentation duration can be different for one or more segments. The segmentation duration may be constant and/or nearly constant for segments (eg, DASH-AVC/264 may use segments with a duration within a 25% tolerance range).

The MPD may include information about media segments that are not available at the moment the MPD is read by the user (eg, in the case of live broadcasts). Segmentation may be available within a defined available time window. The time window can be calculated from the wall clock time and/or the segment duration.

Index segments can be of segment type. Index segments can appear as sub-files. Index segments can appear in media segments. Index segments can include timing and/or random access information. Index segmentation enables efficient implementation of random access and trick mode. Index segmentation can be used for more efficient bitstream switching. Index segmentation is available for VoD and PVR type applications. Index segmentation is less used in situations involving the field.

Segmentation level and/or presentation level characteristics can be used to implement efficient bitstream switching. DASH provides functional requirements for segmentation level and/or presentation level features. Segmentation level and/or presentation level characteristics may be represented in the MPD (eg, in a format independent manner). The segmentation format specification may include format level restrictions corresponding to general requirements.

The media segment can be shown as i . The representation can be shown as R. The media segment i representing R can be shown as. The duration can be shown as. The earliest presentation time can be shown as. The EPT can correspond to the earliest presentation time of the segment. The earliest presentation time may not be the time when the segment successfully played during random access.

Time calibration can be used for efficient switching between representations in an adaptive set. For a pair (eg, any pair) in the adaptive set representing R _a and R _b , and segment i , the effective switching in the adaptive set can be followed. For example, when switching is in accordance, switching capabilities and/or double decoding at segment boundaries without overlapping downloads can occur. For example, when a segment starts with a certain type of random access point, the switching capability and/or double decoding at the segment boundary without overlapping downloads can occur.

For example, bit stream switching at the sub-segment level can occur when index processing is used. For example, bit stream switching at the sub-segment level can occur when sub-segment switching is followed. For example, bitstream switching at the sub-segment level can occur when a sub-segment begins with a certain type of random access point.

The system can use time calibration and/or random access point layout restrictions. For example, in video coding, the restriction may correspond to a code that matches a transient decoder renew (IDR) frame and/or a closed picture group (GOP) at a segment boundary.

Figure 2 is an example DASH system model 200. The DASH client can include one or more of the following: an access client (eg, DASH access engine 202), a media engine (eg, media engine 204), and/or an application (eg, application 206). The DASH access engine 202 can be an HTTP client. The DASH access engine 202 can receive MPD and/or segmentation material, for example, via a CDN (not shown). The DASH access engine 202 can send media (eg, along with timing) to the media engine 204. The medium can be in MPEG format (eg, MPEG-2 TS) or ISO format (eg, ISO-BMFF). The media engine 204 can decode and present media provided from the DASH access engine 202. The DASH access engine 202 can pass events (e.g., along with timing) to the application 206. The online format interface for segmentation and/or MPD can be defined. Other interfaces may be defined in accordance with the judgment of the implementer.

The timing behavior of the DASH client can be complex. For example, in Apple HLS, the segments mentioned in the manifest can be valid. For example, in Apple HLS, the client can poll for new manifest files. DASH MPD reduces polling behavior. The DASH MPD can reduce polling behavior, for example, by defining an MPD update frequency and/or allowing calculation of segment availability.

Static MPD can be effective. Static MPD can always be effective. Dynamic MPD can be effective. The dynamic MPD can be valid, for example, from the time when the dynamic MPD is acquired by the client to the duration of the refresh cycle. MPD can expose open time.

The MPD can provide the available time of the earliest segment of the cycle. The available time of the earliest segment of the cycle can be shown as. Media segments can be shown as n . For example, starting at time, media segmentation n can be available. Media segmentation n may be available for the duration of the time offset buffer. The time offset buffer can be shown as. This time offset buffer can be stated in the MPD. Window size availability can affect the catch-up TV functionality of DASH deployments. For example, if the segment availability is within the MPD validity period, then accessing the client depends on the segment availability time.

The MPD can indicate the bandwidth, for example, for the representation R. The bandwidth can be shown as. MPD can define the global minimum buffer time. The global minimum buffer time can be shown as. The access client is able to deliver the segment to the media engine. For example, after the bit is downloaded, the accessing client can deliver the segment to the media engine. Segmentation can begin with a random access point. The earliest time segmentation n delivered to the media engine can be shown as. The download time of segment n can be shown as. The DASH client, for example, can start playing immediately to minimize latency. The MPD may propose a rendering delay (eg, as an offset from). For example, the MPD may propose a presentation delay to ensure synchronization between different clients. Tight synchronization of fragmented HTTP GET requests can affect the infrastructure.

MPD validity and/or segmentation availability can be calculated using absolute (eg, wall clock) time. Media time can be represented in segments. For example, in the case of scene drift, media time can evolve between the encoder and the client clock. Media time can be processed at the container level. For example, both MPEG-2 TS and ISO-BMFF provide synchronization functionality.

HTTP can be stateless and/or client-driven. A "push" event can be emulated using polling (eg, frequency polling). For example, in current ad insertion practices in cable/IPTV systems, an upcoming commercial break can be sent for three to eight seconds before the commercial break begins. Poll-based implementations may be invalid. Events can handle invalid ad insertions.

Events can include timing information. Events can include time and duration information. Events can include payload information. The payload information can include any information. Events can have application-specific payloads. In-band events can be small message blocks. Small message blocks can appear at the beginning of the media segment. An MPD event can be a periodic level list of timing elements. DASH can define an MPD validity expiration event. After the specified presentation time, the MPD validity event identifies the oldest valid MPD version.

DASH may be unknowable for Digital Rights Management (DRM). DASH supports the transmission of DRM solutions by signal. DASH can support the signal transmission DRM scheme feature in the MPD. The DRM scheme can be transmitted by signal via a ContentProtection descriptor. An opaque value can be passed within the DRM scheme. The DRM scheme can be transmitted by signal using the unique identifier of the scheme. The meaning of the opaque value can be defined to signal the DRM scheme. A scenario-specific namespace can be used to signal the DRM scheme.

MPEG can provide content protection standards (eg, Common Encryption for ISO-BMFF (CENC) and segmentation encryption and authentication. Public encryption can encrypt which parts of the sample and/or encrypt how the relay material is signaled in orbit For example, for a given encrypted relay data in a segment, the DRM module can be responsible for delivering the key to the client. The decryption can use the standard AES-CTR and/or AES-CBC mode. The CENC framework is Scalable. For example, if other encryption algorithms are defined, the CENC framework can use other encryption algorithms beyond AES-CTR and/or AES-CBC mode. Public encryption can be used in some commercial DRM systems. Universal encryption can be a system used in DASH (eg, DASH264).

DASH Segmentation Encryption and Authentication (DASH-SEA) may be agnostic for segmentation formats. Encrypted relay data can be delivered via the MPD. For example, the MPD can include information about the keys that can be used to decrypt the segments. The MPD may include information on how to obtain a key that can be used to decrypt the segment. For example, the baseline system can be equivalent to the baseline system defined in the HLS, such as a baseline system with AES-CBC encryption and HTTPS-based key transmission. This baseline system, equivalent to the baseline system defined in the HLS, enables MPEG-2 TS media segmentation to be compatible with encrypted HLS segments. The DASH-SEA standard is extensible. For example, similar to CENC, the DASH-SEA standard may permit other encryption algorithms and/or more DRM systems.

DASH-SEA provides a segmented authentication framework. The segmentation authentication framework ensures that the segment received by the client is the same and/or similar to the segment that the MPD author intends to receive from the client. The segmentation authentication framework, for example, may use MAC and/or digest algorithms to avoid content modification in the network (eg, ad replacement, changing in-band events, etc.).

In instances where one or more (eg, all) representations are not multiplexed, each representation may include a ContentComponent (eg, video, audio, etc. in a particular language). MPEG-2 streaming segments can serve as an example here, however all instances are also associated with all segmentation types.

A single resource can be divided into several cycles. In the transport stream, there may be a time distance between the audio and video. The start times of the two components may not be the same. Content components used for timing calculations may be difficult to represent. Drift can develop between audio and video. For example, in the case where the period of insertion is removed, a false signal in the transition may occur. For example, since the audio and video durations of the previous cycle may be different, a false signal in transition may occur.

According to one example, decisions can be made in the Internet radio for audio, closed captioning, video, and the like. Video can be a slide show at a very slow, possibly variable, frame rate. It can be represented by a "master" component that can be made in accordance with all calculations.

In one example, there may be two audio streams (eg, L1 and L2) in different languages in a single multiplex. L1 and L2 can use different codecs (for example, C2 and C2, respectively). L1 may require C1 and L2 may require C2. Missing support for codec C2 may result in inability to play in language L2. It may be allowed to play in the language L1. For example, the languages L1 and L2 can be English AC-3 and Spanish MP2. For example, if traditional US content is trimmed without re-encoding, the language may not be allowed.

In one example, closed captioning and/or subtitles and "burned in" in a video bitstream (eg, using CEA-608 or CEA-708, as defined in SCTE 128-1) It may be difficult to distinguish between closed captions and/or subtitles (where text is part of pre-encoded video (for example, text cannot be removed without specific processing)). Implementers can identify differences between multiplexed and built-in closed captions and/or subtitles. For example, CEA 608/708 closed captions can be turned on and off. Built-in subtitles may not be turned on and off. The implementation of CEA 608/708 can be used via a video codec to display CEA 608/708 closed captioning. The video codec can be used alone to display built-in closed captions.

In one example, when multiple resources are present in a single cycle (eg, upstream completed ad splicing with different video features), varying aspect ratio messaging and/or processing, and/or expected display (eg, The "mailbox" can be used for in-band communication and/or processing. The signal transmission aspect ratio in DASH can be used at the presentation/adaptive aggregation level. For example, when the signal is transmitted in the DASH, the player may not be aware that the signal transmission aspect ratio can be changed. A signal transmission interruption may occur. For example, when different streams are stitched together, a time interruption may occur. For example, in MPEG-2 TS, a signal transmission interrupt can be notified. For example, in MPEG-2 TS, signal transmission interruptions may result in PCR-PCR differences. The signal is used to inform the player that the segmentation duration (eg, not directly using the timestamp) estimates that the segmented EPT can be used to reduce signal transmission interruptions and PCR-PCR differences.

The content component types in MPEG DASH can be used to represent different content components of a multiplex representation. Content component element definitions may appear in section 5.3.4 of ISO/IEC 23009-1:2014. The content component can be extended to provide additional attributes that represent parameters. The content component can be extended to provide a mapping between the appropriate packet identifier (PID) (eg, or track) in the stream and the content component. Content components can be defined for each application collection. Content components can be defined for each representation. Table 1 is an example of a content component element definition with attributes added to represent parameters.

The @ codec element in the content component can be signaled. For example, when presenting different audio features (eg, two audio streams in different languages using a different codec in a single multiplex), the @ codec elements in the content component can be signaled. For example, the @ codec element in the content component can be signaled to distinguish between multiplexed closed captions or subtitles in the video bitstream, and built-in closed captions or subtitles whose text is part of the precoded video. For example, the @ codec element in the content component may indicate that a multiplex representation includes two audio components that are multiplexed together, and/or indicates that the audio component is encoded according to a different audio codec. The multiplexed audio component can have a different language (as indicated by the @ language). The client can determine if the device supports one or more audio components.

Multi-channel audio and/or sample rate messaging can be added to the content component. For example, when presenting different audio features, multi-channel audio and/or sample rate messaging can be added to the content component.

A 1:1 mapping can be established between the content component and the track IP and/or PID. For example, when a single resource is divided into cycles, a 1:1 mapping can be established between the content component and the track IP and/or PID.

The relative offset from the "non-master" component of the "main" component can be determined. For example, the relative offset from the "non-master" component of the "master" component can be determined by indicating the offset using the @component rendering time offset. When a single resource is partitioned into cycles, the relative offset from the "non-master" component of the "master" component can be determined. The UE can determine the EPT of the video component or audio component in the segment. The processor can determine the relative offset of the audio components in the segment based on the EPT of the segmented video component.

Codecs can be registered for CEA-608 and/or CEA-708. A 4cc value can be registered for CEA 608/708. The 4cc value can be a separate value for one or more criteria (eg, c608 and c708). The 4cc value can be a defined generic value (eg, cc08). Common values can be defined. The profile may indicate whether CEA-708 can be used (eg, CEA-608 with cc08.6 and CEA-708 with cc08.7).

The PAR value can be defined. The value of AFD can be defined. The value of the AFD can be defined when multiple resources are in a single cycle. The ratio type definition in ISO/IEC 23009-1:2014 Appendix B allows values that are not accepted in regular PAR calculations (for example, the values ":", "0:", and ":0"). These unacceptable values can be used as an indicator of the in-band specified aspect ratio and its processing.

The role value can be used to indicate the primary component that can be used as the "master" component. The principal component can be a component assumed to be used for time calculation. According to one example, the role "master" can be added to Table 22 of ISO/IEC 23009-1:2014, Section 5.8.5.5, and the equivalent semantics can be added to ISO/IEC 23009-1:2014, Section 5.8.5.5 Table 22. A "master" content component can be visualized. The @track identifier can be rendered.

For example, a supplemental feature can be introduced to signal that an interruption may occur. The desired receiver behavior can be used to calculate a mapping of the specified rendering time in the bitstream. The mapping of the presentation time specified in the bitstream may be calculated relative to the estimation of the segmentation duration and/or @presentation time offset.

The initialization segment and/or the first available segment may be obtained (eg, requested and/or received). The initialization segment and/or the first available segment may be obtained when different audio features are presented. The initialization segment and/or the first available segment may be obtained to distinguish between closed captions or subtitles in the video bitstream and textual built-in closed captions or subtitles that are part of the precoded video.

The content component can be used as an extension representing the basic type. For example, content components can be used as extensions to represent basic types to resolve messaging issues.

Although the features and elements are described above in a particular combination, each feature or element can be used alone or in various combinations with other features and elements. Moreover, the methods described herein can be implemented in a computer program, software or firmware incorporated in a computer readable storage medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted via a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor memory devices, such as built-in hard drives and removable magnetic Magnetic media, magneto-optical media, and optical media (eg, CD-ROM discs and digital versatile discs (DVD)). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host.

100‧‧‧Communication system
102, 102a, 102b, 102c, 102d‧ ‧ ‧ wireless transmit / receive unit (WTRU)
103/104/105‧‧‧Radio Access Network (RAN)
106/107/109‧‧‧ core network
108‧‧‧Public Switched Telephone Network (PSTN)
110‧‧‧Internet
112‧‧‧Other networks
114a, 114b‧‧‧ base station
115/116/117‧‧‧Intermediate mediation
118‧‧‧Processor
120‧‧‧ transceiver
122‧‧‧Transmission/receiving components
124‧‧‧Speaker/Microphone
126‧‧‧ keyboard
128‧‧‧Display/Touchpad
130‧‧‧Non-movable memory
132‧‧‧Removable memory
134‧‧‧Power supply
136‧‧‧Global Positioning System (GPS) chipset
138‧‧‧ peripheral devices
140a, 140b, 140c‧‧‧ Node B
142a, 142b‧‧‧ Radio Network Controller (RNC)
144‧‧‧Media Gateway (MGW)
146‧‧‧Mobile Exchange Center (MSC)
148‧‧‧Serving GPRS Support Node (SGSN)
150‧‧‧Gateway GPRS Support Node (GGSN)
160a, 160b, 160c‧‧‧e Node B
162‧‧‧Mobility Management Gateway (MME)
164‧‧‧ service gateway
166‧‧‧ Packet Data Network (PDN) Gateway
180a, 180b, 180c‧‧‧ base station
182‧‧‧Access Service Network (ASN) Gateway
184‧‧‧Action IP Local Agent (MIP-HA)
186‧‧‧Authentication, Authorization, Accounting (AAA) Server
188‧‧ ‧ gateway
200‧‧‧Example DASH system model
202‧‧‧DASH Access Engine
204‧‧‧Media Engine
206‧‧‧Application
DASH‧‧‧Dynamic Adaptive Streaming
Iub, IuCS, IuPS, iur, S1, X2‧‧ interface
MPD‧‧‧Multimedia presentation description
R1, R3, R6, R8‧‧‧ reference points

1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. FIG. 1B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used in the communication system shown in FIG. 1A. Figure 1C is a system diagram of an example radio access network and an example core network that can be used in the communication system shown in Figure 1A. FIG. 1D is a system diagram of another example radio access network and an example core network that may be used in the communication system shown in FIG. 1A. FIG. 1E is a system diagram of another example radio access network and an example core network that may be used in the communication system shown in FIG. 1A. Figure 2 is a diagram of an example DASH system model.

200‧‧‧Example DASH system model

202‧‧‧DASH Access Engine

204‧‧‧Media Engine

206‧‧‧Application

DASH‧‧‧Dynamic Adaptive Streaming

MPD‧‧‧Multimedia presentation description

Claims (44)

An apparatus, the apparatus comprising: a processor configured to: receive a multimedia presentation description (MPD) information associated with a content; based on the MPD information, determining that the content comprises a multiplex representation, the multiplex representation including a closed caption component multiplexed with at least one of an audio component or a video component; requesting the multiplex representation; and receiving a content segment including the multiplex representation. The apparatus of claim 1, wherein the processor is further configured to determine whether the closed caption component is a CEA-608 closed caption component or a CEA-708 closed caption component. The device of claim 2, wherein the processor is further configured to determine whether a display of the closed caption component is supported on the device. The device of claim 2, wherein the processor is further configured to determine whether the device is capable of decoding and displaying the closed caption component. The device of claim 1, wherein the processor is further configured to determine a language of the closed caption component. The device of claim 5, wherein the processor is further configured to determine whether the language is supported on the device. The device of claim 5, wherein the processor is further configured to determine whether the device is capable of displaying closed captions in the determined language. An apparatus, the apparatus comprising: a processor configured to: receive a multimedia presentation description (MPD) information associated with a content; based on the MPD information, determining that the content comprises a multiplex representation, the multiplex representation including Two audio components that are multiplexed together, the audio component being encoded according to a different audio codec; requesting the multiplex representation; and receiving a content segment including the multiplex representation. The device of claim 8, wherein the processor is further configured to determine a language of the at least one audio component. The device of claim 9, wherein the processor is further configured to determine whether the audio codec is supported. The device of claim 10, wherein the two audio components have different languages. The apparatus of claim 8, wherein the processor is further configured to distinguish an audio sampling rate of the two audio components of the multiplex representation. The device of claim 8 wherein the MPD information comprises a sampling rate comprising one or more segments of the multiplex representation. The apparatus of claim 8, wherein the processor is further configured to determine that an audio codec of an audio segment of the multiplex representation is not supported, and select other audio segments of the multiplex representation A segment of the segment for replay. An apparatus, the apparatus comprising: a processor configured to: receive a multimedia presentation description (MPD) information associated with a content; based on the MPD information, determining that the content comprises a multiplex representation, the multiplex representation including A packet identifier of a segment included in a multiplex representation; requesting the multiplex representation; and receiving a content segment including the multiplex representation. The device of claim 15, wherein the segment is a video component. The device of claim 15, wherein the processor is further configured to determine a track identifier of at least one of a video component and an audio component of the segment. The device of claim 15 wherein the processor is further configured to determine an earliest presentation time (EPT) of a video component or an audio component of the segment. The device of claim 18, wherein the processor is further configured to determine a relative offset of an audio component of the segment from the EPT of a video component of the segment. The device of claim 18, wherein the MPD information comprises the video component or one of the audio components being an indication of a primary content component. The apparatus of claim 20, wherein the processor is further configured to determine at least one of a video component or an audio component of the segment from the EPT of the primary content component of the segment. A relative offset. The device of claim 15 wherein the processor is further configured to determine an aspect ratio of a video component of the segment. A method comprising: receiving a multimedia presentation description (MPD) information associated with a content; determining, based on the MPD information, that the content comprises a multiplex representation comprising an audio component or a video component a closed caption component of at least one multiplex; requesting the multiplex representation; and receiving a content segment including the multiplex representation. The method of claim 23, further comprising determining whether the closed caption component is a CEA-608 closed caption component or a CEA-708 closed caption component. The method of claim 23, further comprising determining whether to support display of the closed caption component. The method of claim 24, further comprising determining whether a device is capable of decoding and displaying the closed caption component. The method of claim 23, further comprising determining a language of the closed caption component. The method of claim 26, further comprising determining whether the language is supported on the device. The method of claim 26, further comprising determining whether the device is capable of displaying a closed caption in the determined language. A method comprising: receiving a multimedia presentation description (MPD) information associated with a content; determining, based on the MPD information, that the content comprises a multiplex representation comprising two audio components that are multiplexed together, The audio component is encoded according to a different audio codec; the multiplex representation is requested; and a content segment including the multiplex representation is received. The method of claim 30, further comprising determining a language of the at least one audio component. The method of claim 31, further comprising determining whether the audio codec is supported. The method of claim 30, wherein the two audio components have different languages. The method of claim 30, further comprising distinguishing an audio sampling rate of the two audio components of the multiplex representation. The method of claim 30, wherein the MPD information comprises a sampling rate of the one or more segments included in the multiplex representation. The method of claim 30, further comprising determining that an audio codec of an audio segment of the multiplex representation is not supported, and selecting a segment of the other audio segment of the multiplex representation Used for replay. A method comprising: receiving a multimedia presentation description (MPD) information associated with a content; determining, based on the MPD information, that the content comprises a multiplex representation comprising a segment included in a multiplex representation a packet identifier; requesting the multiplex representation; and receiving a content segment including the multiplex representation. The method of claim 37, wherein the segment is a video component. The method of claim 37, further comprising determining a track identifier of at least one of a video component and an audio component in the segment. The method of claim 37, further comprising determining an earliest presentation time (EPT) of a video component or an audio component in the segment. The method of claim 40, further comprising determining a relative offset of an audio component in the segment from the EPT of a video component of the segment. The method of claim 40, wherein the MPD information comprises an indication that the video component or the one of the audio components is a primary content component. The method of claim 42, further comprising determining, from the EPT of the primary content component of the segment, a relative offset of at least one of a video component or an audio component of the segment. The method of claim 37, further comprising determining an aspect ratio of a video component of the segment.