Patent Description:
Three-dimensional (<NUM>-D) video offers a high-quality and immersive multimedia experience, which has only recently become feasible on consumer electronics and mobile platforms through advances in display technology, signal processing, transmission technology, and circuit design. It is currently being introduced to the home through various channels, including by Blu-ray Disc™, cable and satellite transmission, etc., as well as to mobile networks through <NUM>-D enabled smartphones, etc. Concepts related to delivery of such content through wireless networks are being developed.

<NPL>, discloses a general description of a transparent packet-switched streaming service in 3GPP-defined networks.

<CIT> discloses a system and method for rule-based dynamic server-side streaming manifest files.

<CIT>discloses a system and method for selective distribution of information. The method includes developing a filtered manifest that includes a list of files needed by a client application and associated with a condition.

Illustrative embodiments of the present disclosure include, but are not limited to, methods, systems, computer-readable media, and apparatuses for signaling stereoscopic three-dimensional video content capabilities of a client device in a communication network. Some embodiments of this invention in this context could be on methods, systems, computer-readable media, and apparatuses for signaling stereoscopic three-dimensional video content capabilities of a mobile device in a wireless communications network.

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrase "in some embodiments" is used repeatedly. The phrase generally does not refer to the same embodiments; however, it may. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrase "A and/or B" means (A), (B), or (A and B). The phrases "A/B" and "A or B" mean (A), (B), or (A and B), similar to the phrase "A and/or B". The phrase "at least one of A, B and C" means (A), (B), (C), (A and B), (A and C), (B and C) or (A, B and C). The phrase "(A) B" means (B) or (A and B), that is, A is optional.

As used herein, the term "module" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

Significant improvements in video compression capability have been demonstrated with the introduction of the H. <NUM>/MPEG-<NUM> advanced video coding (AVC) standard. Since developing the standard, the joint video team of the ITU-T Video Coding Experts Group (VCEG) and the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) Moving Picture Experts Group (MPEG) has also standardized an extension of AVC that is referred to as multiview video coding (MVC). MVC provides a compact representation for multiple views of the video scene, such as multiple synchronized video cameras.

In stereoscopic <NUM>-D video applications, two views are displayed. One for the left eye and one for the right eye. There are various ways of formatting the views of stereoscopic <NUM>-D video content. In one embodiment, the encoding of stereo-paired <NUM>-D video may be a special case of MVC, where left and right eye views are produced via MVC. Other encoding formats of producing <NUM>-D video content are also possible. Various devices may have different capabilities with respect to decoding and rendering these different formats. Embodiments described herein provide for various parameters of a device capability exchange that may facilitate delivery and viewing of the <NUM>-D video content in a communication network such as a wireless network, e.g., an evolved universal terrestrial radio access network (EUTRAN).

<FIG> schematically illustrates a network environment <NUM> in accordance with various embodiments. The network environment <NUM> includes a user equipment (UE) <NUM>, which may also be referred to as a client terminal or mobile device, wirelessly coupled with a radio access network (RAN) <NUM>. The RAN <NUM> may include an enhanced node base station (eNB) <NUM> configured to communicate with the UE <NUM> via an over-the-air (OTA) interface. The RAN <NUM> may be part of a third generation partnership project (3GPP) long-term evolution (LTE) advanced network and may be referred to as an EUTRAN. In other embodiments, other radio access network technologies may be utilized.

The UE <NUM> may communicate with a remote media server <NUM> through the RAN <NUM>. While the eNB <NUM> is shown communicating directly with the media server, it will be understood that the communications may flow through a number of intermediate networking components, e.g., switches, routers, gateways, etc., in various embodiments. For example, in some embodiments, the RAN <NUM> may be coupled with a core services network (CSN) that communicatively couples the RAN <NUM> with a larger network, e.g., a wide area network, of which the media server <NUM> may be considered a part.

While <FIG> describes the network environment as a wireless communication network, other embodiments may be used in other types of networks, e.g., wire-line networks. It may be understood that other network environments in which embodiments of the present invention may be employed may include additional, fewer, or different components than those explicitly shown in the example depicted in <FIG>. For example, embodiments of the present invention employed in a wire-line network, may have the media server <NUM> and the UE <NUM> communicating with one another without the RAN <NUM>.

The UE <NUM> and media server <NUM> may have a number of components that are configured to facilitate access, storage, transmission, and display of <NUM>-D video content. For example, the UE <NUM> may include a content management module <NUM>, a media player <NUM> having a streaming application <NUM>, and a display <NUM>. The streaming application <NUM> may have sufficient functionality to receive <NUM>-D video content and associated information; decode, unpack, and otherwise re-assemble the <NUM>-D video; and render the <NUM>-D video on the display <NUM>. In various embodiments, the streaming application <NUM> may be referred to in the context of the streaming technology employed. For example, in embodiments in which the content is streamed by a packet-switched streaming service (PSS), the streaming application <NUM> may be referred to as a PSS application. The content management module <NUM> may negotiate or otherwise communicate streaming parameters including, e.g., device capability parameters, to enable receipt of the data in manner that facilitates operation of the media player <NUM>.

The media server <NUM> may include content delivery module <NUM> having a streaming application <NUM>, a content management module <NUM>, and a content storage <NUM>. The content delivery module <NUM> may encode, pack, or otherwise assemble <NUM>-D video content, stored in the content storage <NUM>, for transmission to one or more UEs, e.g., UE <NUM>. The content management module <NUM> may negotiate or otherwise communicate streaming parameters including, e.g., device capability parameters, and control the content delivery module <NUM> in a manner to facilitate delivery of the <NUM>-D content.

In some embodiments, one or more of the components that are shown as being part of the media server <NUM> may be disposed separately from the media server <NUM> and communicatively coupled with the media server over a communication link. For example, in some embodiments, content storage <NUM> may be disposed remotely from the content delivery module <NUM> and the content management module <NUM>.

In some embodiments, the content delivery module <NUM> may deliver, through eNB <NUM> in one example, the <NUM>-D video content to the UE <NUM> in accordance with a 3GPP streaming standard. For example, the <NUM>-D video content may be transmitted in accordance with a PSS standard, e.g., <NPL>), a dynamic adaptive streaming over HTTP (DASH) standard, e.g., <NPL>), a multimedia broadcast and multicast service (MBMS) standard, e.g., <NPL>), and/or an IMS-based PSS and MBMS services (IMS_PSS_MBMS) standard, e.g., <NPL>). The streaming application <NUM> may be configured to receive the <NUM>-D video content over any of a number of transport protocols, e.g., real-time transport protocol (RTP), hypertext transport protocol (HTTP), etc..

Capability exchange enables media streaming servers, such as media server <NUM>, to provide a wide range of devices with video content suitable for the particular device in question. To facilitate server-side content negotiation for streaming, the media server <NUM> may determine the specific capabilities of the UE <NUM>.

The content management module <NUM> and the content management module <NUM> may negotiate or otherwise communicate parameters of a <NUM>-D video content streaming session. This negotiation may take place through session-level signaling via the RAN <NUM>. In some embodiments, the session-level signaling may include transmissions related to device capability information that includes stereoscopic <NUM>-D video decoding and rendering capabilities of the media player <NUM>. In various embodiments, the device capability information may further include pre-decoder buffer size, initial buffering. , decoder capability, display properties (screen size, resolution, bit depth, etc.), streaming method (real-time streaming protocol (RTSP), HTTP, etc.) adaptation support, quality of experience (QoE) support, extended real-time transport protocol (RTCP) reporting support, fast content switching support, supported RTP profiles, session description protocol (SDP) attributes, etc..

During the setup of the streaming session, the content management module <NUM> may use the device capability information to control the content delivery module <NUM> in a manner to provide the UE <NUM> with the proper type of multimedia content. For example, the media server <NUM> may determine which variants of multiple available variants of a video stream are desired based on the actual capabilities of the UE <NUM> to determine the best-suited streams for that terminal. This may allow for improved delivery of <NUM>-D video content and associated session description and metadata files, for example SDP file or a media presentation description (MPD) file, to the UE <NUM>.

The content delivery module <NUM> may access the content in the content storage <NUM> and adapt the content and/or associated session description and metadata files, e.g., SDP/MPD files, according to the negotiated session parameters prior to delivery of the content/associated files. The content, when delivered to the UE <NUM>, may be decoded by the media player <NUM> and rendered on the display <NUM>.

Adaptation of content and/or associated session description and metadata files is shown in accordance with some specific examples with reference to <FIG>, while setup of streaming session is shown in accordance with a specific example with reference to <FIG>.

<FIG> illustrates a DASH-based streaming embodiment with adaptation of <NUM>-D video formats in accordance with some embodiments. In particular, <FIG> illustrates an HTTP server <NUM> in communication with a DASH client <NUM> and implementing a pull-based streaming embodiment, in which the streaming control is maintained by the client rather than the server, where the client downloads content from the server through a series of HTTP-based request-response transactions after the inspection of the MPD. In DASH-based streaming, the MPD metadata file provides information on the structure and different versions of the media content representations stored in the HTTP server <NUM> (including different bitrates, frame rates, resolutions, codec types, etc.). Based on this MPD metadata information that describes the relation of the segments and how they form a media presentation, DASH client <NUM> may request the media segments using HTTP GET or partial GET methods. The HTTP server <NUM> and DASH client <NUM> may be similar to and substantially interchangeable with media server <NUM> and UE <NUM>, respectively.

In DASH, the set of <NUM>-D video formats and corresponding content information may be signaled to the DASH client <NUM> in the MPD. Depending on the capability profile of the DASH client <NUM> and its supported <NUM>-D formats, the HTTP server <NUM> may offer different formatted content, the HTTP server <NUM> excludes the <NUM>-D formats that are not supported by the DASH client <NUM> in the MPD and only includes those that are supported by the DASH client <NUM>. In this context, the HTTP server <NUM> may provide the content optimized for different <NUM>-D video formats to the DASH client <NUM>. In doing this, the HTTP server <NUM> may use the device capability exchange signaling from the DASH client <NUM> describing the various supported <NUM>-D video formats. The DASH client <NUM> may then request the corresponding versions of the <NUM>-D video content supported by the DASH client <NUM>. Moreover, when retrieving an MPD with HTTP, the DASH client <NUM> may include <NUM>-D video codec and format information in a GET request, including any temporary adjustments to the <NUM>-D video formats based on profile difference (ProfDiff). In an example, the difference may be configured to temporarily modify one or more MPD parameters for a content presentation session. For example, the difference may be configured to modify the MPD until the content presentation session ends or a subsequent difference (corresponding to the first communicated difference) is communicated to the HTTP server <NUM>. This way the HTTP server <NUM> may deliver an optimized MPD to the DASH client <NUM>.

<FIG> illustrates an RTSP-based streaming embodiment with adaptation of <NUM>-D video formats in accordance with some embodiments. In particular, <FIG> illustrates a server <NUM> and a client <NUM> implementing a push-based streaming method, in which the streaming and session control are maintained by the server <NUM> rather than the client <NUM>. The server <NUM> and client <NUM> may be similar to and substantially interchangeable with media server <NUM> and UE <NUM>, respectively.

Examples of push-based streaming include PSS and IMS_PSS_MBMS services based on the RTSP and session initiation protocol (SIP), respectively. In this context, the server <NUM> receives the set of supported <NUM>-D video codecs and formats from the client <NUM> and adapts the content based on this information, e.g., the server <NUM> selects the most suited content version among stored content versions or dynamically transcodes the content based on the supported <NUM>-D video formats and streams the content to the client <NUM>. The session-related metadata carried in the SDP may carry the <NUM>-D video format information for the streamed content.

<FIG> illustrates a service discovery with subscribe/notify for IMS_PSS_MBMS service in accordance with some embodiments. In particular, <FIG> illustrates interactions between a UE <NUM>, an IP Multimedia (IM) Core Network (CN) subsystem <NUM>, and a service discovery function (SDF) <NUM>. The UE <NUM> may be similar to and substantially interchangeable with UE <NUM>. The IM CN subsystem <NUM> and the SDF <NUM> may be part of a core network domain that interfaces with the access network domain, e.g., the RAN <NUM>.

In the IMS_PSS_MBMS service, the UE <NUM> can send device capability information, e.g., supported <NUM>-D video codecs and formats, in a SIP SUBSCRIBE message to the IM CN Subsystem <NUM> during service discovery. The IM CN subsystem <NUM> may then forward the message to the SDF <NUM>. The SDF <NUM> determines the proper service discovery information, e.g. according to the capabilities of the UE <NUM> as described in the user's profile (Personalized Service Discovery). The SDF <NUM> may then send a SIP <NUM> OK message to the IM CN subsystem <NUM>, which is relayed to the UE <NUM> to confirm the session initialization based on the sent device capability information that also includes the supported <NUM>-D video codecs and formats. Afterward, the SDF <NUM> may send a SIP NOTIFY message, with service discovery information, to the IM CN subsystem <NUM>, which relays the SIP NOTIFY message back to the UE <NUM>. The UE <NUM> may then respond by sending a SIP <NUM> OK message to the IM CN subsystem <NUM>, which is then relayed to the SDF <NUM>.

Such a framework enables optimized service discovery utilizing the supported <NUM>-D video formats in IMS-based PSS and MBMS user services. Later during the IMS session, the UE <NUM> may also use SIP signaling to indicate updates including any temporary adjustments to the set of supported <NUM>-D video codecs and formats based on ProfDiff (e.g., if the current device orientation is different from the default device orientation). This may be done by refreshing the subscription through further SIP SUBSCRIBE messages including information on the updates to the <NUM>-D video format information.

Referring again to <FIG>, in some embodiments, the media server <NUM> may be coupled with a device profile server <NUM> that has profile information of the UE <NUM>. The profile information may include some or all of the device capability information. In such embodiments, the media server <NUM> may receive identification information from the UE <NUM> and then retrieve the profile information from the device profile server <NUM>. This may be done as part of the session-level signaling.

In some embodiments, the UE <NUM> may supplement the profile information retrieved from the device profile server <NUM> with extra attributes or overrides for attributes already defined in its device capability profile, based on ProfDiff signaling. In one example, such a temporary adjustment may be triggered by user preferences, for example if the user for a particular session only would like to receive two-dimensional (<NUM>-D) video even though the terminal is capable of rendering <NUM>-D video.

The streaming application <NUM> may encode the <NUM>-D video content for transmission in the network environment <NUM> in accordance with a number of different stream types, with each stream type having associated frame types. Frame types could include frame packing, simulcast, or <NUM>-D plus auxiliary frame types.

Frame packing may include frame-compatible packing formats and full-resolution per view (FRPV) packing format. In frame-compatible packet formats, the streaming application <NUM> may spatially pack constituent frames of a stereo pair into a single frame and encode the single frame. Output frames produced by the streaming application <NUM> contain constituent frames of a stereo pair. The spatial resolution of the original frames of each view and the packaged single frame may be the same. In this case, the streaming application <NUM> may down-sample the two constituent frames before the packing operation. The frame-compatible packing formats may use a vertical interleaving, horizontal interleaving, side-by-side, top-bottom, or checkerboard format as illustrated in <FIG>, respectively, and the down sampling may be performed accordingly.

In some embodiments, the streaming application <NUM> may indicate the frame-packing format that was used by including one or more frame packing arrangement supplemental enhancement information (SEI) messages as specified in the H. <NUM>/AVC standard into the bitstream. The streaming application <NUM> may decode the frame, unpack the two constituent frames from the output frames of the decoder, up sample the frames to revert the encoder side down sampling process, and render the constituent frames on the display <NUM>.

A FRPV packing format may include temporal interleaving. In temporal interleaving, the <NUM>-D video may be encoded at double the frame rate of the original video with each parent and subsequent pictures constituting a stereo pair (left and right view). The rendering of the time interleaved stereoscopic video may typically be performed at a high frame rate, where active (shutter) glasses are used to blend the incorrect view in each eye. This may rely on accurate synchronization between the glasses and the screen.

In embodiments using simulcast frame types, the left and the right views may be transmitted in separate, simulcast streams. The separately transmitted streams may be combined by the streaming application <NUM> and jointly decoded.

In embodiments using <NUM>-D plus auxiliary frame types, <NUM>-D video content may be sent by the streaming application <NUM> in conjunction with auxiliary information that may be used by the streaming application <NUM> to render <NUM>-D video on the display <NUM>. This auxiliary information may be, e.g., a depth/parallax map that is a <NUM>-D map with each pixel defining a depth/parallax of one or more pixels in an associated <NUM>-D video frame.

In some embodiments, other frame types may be used. For example, in some embodiments the streaming application <NUM> may be capable of encoding stereoscopic views into a base view stream and a non-base view stream, which may be transmitted in the same or different streams. In some embodiments, this may be referred to as MVC-based for stereoscopic video. The non-base view stream may include inter-view prediction frames that provide spatial/temporal predictive information. The base view stream may be sufficient for a single-view, e.g., <NUM>-D, decoder to render the base view as <NUM>-D video, while the non-base view stream may provide <NUM>-D decoders, e.g., streaming application <NUM>, with sufficient information to render <NUM>-D video. If the media server <NUM> is aware of UEs' capabilities, it can omit sending the non-base view stream to a device that does not support <NUM>-D video or does not have sufficient bitrate to support <NUM>-D video.

In various embodiments, the device capability information, transmitted from content management module <NUM> and/or device profile server <NUM> to content management module <NUM>, may include a <NUM>-D format attribute that includes a list of one or more formats relevant for streaming of stereoscopic <NUM>-D video over relevant transmission protocol, e.g., RTP or HTTP, supported by the streaming application <NUM>. In some embodiments, the <NUM>-D format attribute may be a streaming frame packing format for RTP or HTTP having an integer value "<NUM>" for vertical interleaving, "<NUM>" for horizontal interleaving, "<NUM>" for side-by-side, "<NUM>" for top-bottom, "<NUM>" for checkerboard, or "<NUM>" for temporal interleaving. In some embodiments, the same <NUM>-D format attributes may be used to indicate frame packing formats supported in a specific file or container format. In some embodiments, the <NUM>-D format attribute may include a more generalized value, e.g., "FP" for frame packing.

In some embodiments, the <NUM>-D format attribute may be another streaming format having a value "SC" for simulcast or "2DA" for <NUM>-D video plus auxiliary information.

In embodiments in which the UE <NUM> supports more than one format type, it may further indicate one or more preferred format types. This could be done by listing the format types in an order of preference, associating a preference indicator with select format types, etc..

In some embodiments, in addition to providing a frame type attribute, the content management module <NUM> and/or the device profile server <NUM> may provide one or more component type attributes. The component type attributes may provide additional details about specific types of video components, which are constituent elements of the stereoscopic <NUM>-D video, supported and/or preferred by the streaming application <NUM>.

The component type attributes may have a value "C" for indicating a center-view stream, "CD" for indicating a center-view stream and a depth map, "CP" for indicating a center-view stream and a parallax map, "D" for indicating a depth map, "P" for indicating a parallax map, "L" for indicating a left-view stream, "LD" for indicating a left-view stream and a depth map, "LIL" for indicating video frames that include alternating scan lines from the left and right views, "LP" for indicating a left-view stream and a parallax map, "R" for indicating a right-view stream, "Seq" to indicate frame sequential (e.g., video stream that includes alternating frames from the left and right streams - additional signaling, e.g., AVC SEI messages, may be needed to signal which frames contain left and right views), "SbS" for
<IMG>
indicating side-by-side, and "TaB" for indicating top and bottom.

Each format type attribute may be associated with a respective set of component type attributes. For example, if the format type is SC, the associated component type may be L or R to indicate left and right views, respectively.

The device capability exchange signaling capability in the PSS specification 3GPP TS <NUM> enables servers to provide a wide range of devices with content suitable for the particular device in question. In order to improve delivery of stereoscopic <NUM>-D video content to the client terminal, the present disclosure describes a new set of attributes that may be included in the PSS vocabulary for device capability exchange signaling. These proposed attributes may describe the <NUM>-D video decoding and rendering capabilities of the client terminal, including which <NUM>-D video frame packing formats the client supports. This may for example allow the server and network to provide an optimized RTSP SDP or DASH MPD to the client terminal, as well as to perform the appropriate transcoding and <NUM>-D format conversions in order to match the transmitted <NUM>-D video content to the capabilities of the client device.

The device capability exchange signaling of supported <NUM>-D video codecs and formats may be enabled in 3GPP TS <NUM> with the inclusion of three new attributes in the PSS vocabulary: (<NUM>) for Streaming component, two attributes indicating the list of supported frame packing formats relevant for streaming of stereoscopic <NUM>-D video over RTP and HTTP, respectively, and (<NUM>) for ThreeGPFileFormat component, one attribute indicating the list of supported frame packing formats relevant for stereoscopic <NUM>-D video that can be included in a 3GPP file format (3GP) file, which is a multimedia container format commonly used for 3GPP-based multimedia services. The details of the attribute definitions are presented below in accordance with some embodiments. <IMG>
<IMG>
<IMG>
<IMG>.

In some embodiments, a media presentation, as described in MPD, for example, may include attributes and elements common to Adaptation Set, Representation, and SubRepresentation. One such common element may be a FramePacking element. A FramePacking element may specify frame packing arrangement information of the video media component type. When no FramePacking element is provided for a video component, frame-packing may not be used for the video media component.

The FramePacking element may include an @schemeIdUri attribute that includes a uniform resource indicator (URI) to identify the frame packing configuration scheme employed. In some embodiments, the FramePacking element may further include an @value attribute to provide a value for the descriptor element.

In some embodiments, multiple FramePacking elements may be present. If so, each element may contain sufficient information to select or reject the described representation.

If the scheme or the value of all FramePacking elements are not recognized, the client may ignore the described Representations. A client may reject the Adaptation Set on the basis of observing a FramePacking element.

For Adaptation Sets or Representations that contain a video component that conforms to ISO/IEC Information technology - Coding of audio-visual objects - Part <NUM>: Advanced Video Coding (ISO/IEC <NUM>-<NUM>:<NUM>), a uniform resource number for FramePackin@schemeldUri may be urn:mpeg:dash:<NUM>:<NUM>:frame_packing_arrangement_type:<NUM>, that may be defined to indicate the frame-packing arrangement as defined by Table D-<NUM> of the ISO/IEC <NUM>-<NUM>:<NUM> ('Defintion of frame_packing_arrangement_type') to be contained in the FramePacking element. The @value may be the 'Value' column as specified in Table D-<NUM> of the ISO/IEC <NUM>-<NUM>:<NUM> and may be interpreted according to the 'Interpretation' column in the same table.

<FIG> illustrates a method <NUM> of signaling <NUM>-D video device capabilities in accordance with some embodiments. Method <NUM> may be performed by components of a UE, e.g., UE <NUM>. In some embodiments, the UE may include and/or have access to one or more computer-readable media having instructions stored thereon, that, when executed, cause the UE, or components thereof, to perform the method <NUM>.

At <NUM>, the UE may determine device capability information. As described above, the device capability information may include information as to the decoding and rendering capabilities of a media player. In some embodiments, a content management module, located on the UE or elsewhere, may determine this information by running one or more scripts on the UE to directly test the capabilities. In other embodiments, the content management module may access one or more stored files that contain the relevant information.

At <NUM>, the UE may provide device capability information to the media server <NUM> or device profile server <NUM>, including stereoscopic <NUM>-D video decoding and rendering capabilities of the media player at the UE. As described above, the device capability information may include one or more format type attributes that represent a list of frame types supported by a streaming application of the UE. In some embodiments, the device capability information may be provided prior to or after the request at <NUM>.

In some embodiments, some or all of the device capability information may be provided to the media server by another entity, e.g., a device profile server.

At <NUM>, the UE may request <NUM>-D video content. In some embodiments, the request may be in accordance with appropriate streaming/transport protocols, e.g., HTTP, RTP, RTSP, DASH, MBMS, PSS, IMS_PSS_MBMS, etc. The request may be directed to the media server and may include a uniform resource locator (URL) or some other indicator of the requested content or portions thereof. In some embodiments, the temporary adjustment to device capability information (e.g., via ProfDiff signaling) may also be provided along with the request at <NUM>, Accordingly, the UE may supplement the profile information retrieved from the device profile server with extra attributes or overrides for attributes already defined in its device capability profile, based on ProfDiff signaling. In one example, such a temporary adjustment may be triggered by user preferences, for example if the user for a particular session only would like to receive two-dimensional (<NUM>-D) video even though the terminal is capable of rendering <NUM>-D video.

At <NUM>, the UE may receive the requested <NUM>-D video content and render the content on a display of the UE. The rendering of the content may include a variety of processes such as, but not limited to, decoding, upconverting, unpacking, sequencing, etc..

<FIG> illustrates a method <NUM> of signaling <NUM>-D video content in accordance with some embodiments. Method <NUM> may be performed by components of a media server, e.g., media server <NUM>. In some embodiments, the media server may include and/or have access to one or more computer-readable media having instructions stored thereon, that, when executed, cause the media server, or components thereof, to perform the method <NUM>.

At <NUM>, the media server may determine device capability information. In some embodiments, the media server may determine the device capability information by receiving, e.g., as part of session-level signaling, the information from the UE or a device profile server.

At <NUM>, the media server may receive a request for <NUM>-D video content. In some embodiments, the request may be in accordance with appropriate streaming/transport protocols, e.g., HTTP, RTP, RTSP, DASH, MBMS, PSS, IMS_PSS_MBMS, etc. The request may be from the UE and may include a universal resource locator (URL) or some other indicator of the requested content or portions thereof. In some embodiments, the request received at <NUM> may occur simultaneously with determination of the device capability information <NUM>, before the determination, or after the determination. In some embodiments, the temporary adjustment to device capability information (e.g., via ProfDiff signaling) may also be received along with the request at <NUM>. Accordingly, the media server may be supplemented with the profile information retrieved from the device profile server with extra attributes or overrides for attributes already defined in its device capability profile, based on ProfDiff signaling.

At <NUM>, the media server may generate session description and/or metadata files to establish a streaming session, for example SDP file or a media presentation description (MPD) based on the device capability information accounting for the stereoscopic <NUM>-D video decoding and rendering capabilities of the media player at the UE.

At <NUM>, the media server may encode the <NUM>-D video content in a format type indicated as being supported by the UE in the device capability information. The <NUM>-D video content may then be streamed to the mobile device.

The components described herein, e.g., UE <NUM>, media server <NUM>, and/or device profile server <NUM>, may be implemented into a system using any suitable hardware and/or software to configure as desired. <FIG> illustrates, for one embodiment, an example system <NUM> comprising one or more processor(s) <NUM>, system control logic <NUM> coupled with at least one of the processor(s) <NUM>, system memory <NUM> coupled with system control logic <NUM>, non-volatile memory (NVM)/storage <NUM> coupled with system control logic <NUM>, a network interface <NUM> coupled with system control logic <NUM>, and input/output (I/O) devices <NUM> coupled with system control logic <NUM>.

The processor(s) <NUM> may include one or more single-core or multi-core processors. The processor(s) <NUM> may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.).

System control logic <NUM> for one embodiment may include any suitable interface controllers to provide for any suitable interface to at least one of the processor(s) <NUM> and/or to any suitable device or component in communication with system control logic <NUM>.

System control logic <NUM> for one embodiment may include one or more memory controller(s) to provide an interface to system memory <NUM>. System memory <NUM> may be used to load and store data and/or instructions, e.g., logic <NUM>. System memory <NUM> for one embodiment may include any suitable volatile memory, such as suitable dynamic random access memory (DRAM), for example.

NVM/storage <NUM> may include one or more tangible, non-transitory computer-readable media used to store data and/or instructions, e.g., logic <NUM>. NVM/storage <NUM> may include any suitable non-volatile memory, such as flash memory, for example, and/or may include any suitable non-volatile storage device(s), such as one or more hard disk drive(s) (HDD(s)), one or more compact disk (CD) drive(s), and/or one or more digital versatile disk (DVD) drive(s), for example.

The NVM/storage <NUM> may include a storage resource physically part of a device on which the system <NUM> is installed or it may be accessible by, but not necessarily a part of, the device. For example, the NVM/storage <NUM> may be accessed over a network via the network interface <NUM> and/or over Input/Output (I/O) devices <NUM>.

The logic <NUM>, when executed by at least one of the processors <NUM> may cause the system to perform the operations described herein with respect to the UE <NUM>, media server <NUM>, and/or device profile server <NUM>. The logic <NUM> may be disposed additionally/alternatively in other components of the system, e.g., in system control logic <NUM>, and may include any combination of hardware, software, or firmware components.

Network interface <NUM> may have a transceiver <NUM> to provide a radio interface for system <NUM> to communicate over one or more network(s) and/or with any other suitable device. In various embodiments, the transceiver <NUM> may be integrated with other components of system <NUM>. For example, the transceiver <NUM> may include a processor of the processor(s) <NUM>, memory of the system memory <NUM>, and NVM/Storage of NVM/Storage <NUM>. Network interface <NUM> may include any suitable hardware and/or firmware. Network interface <NUM> may include a plurality of antennas to provide a multiple input, multiple output radio interface. Network interface <NUM> for one embodiment may include, for example, a wired network adapter, a wireless network adapter, a telephone modem, and/or a wireless modem.

For one embodiment, at least one of the processor(s) <NUM> may be packaged together with logic for one or more controller(s) of system control logic <NUM>. For one embodiment, at least one of the processor(s) <NUM> may be packaged together with logic for one or more controllers of system control logic <NUM> to form a System in Package (SiP). For one embodiment, at least one of the processor(s) <NUM> may be integrated on the same die with logic for one or more controller(s) of system control logic <NUM>. For one embodiment, at least one of the processor(s) <NUM> may be integrated on the same die with logic for one or more controller(s) of system control logic <NUM> to form a System on Chip (SoC).

In various embodiments, the I/O devices <NUM> may include user interfaces designed to enable user interaction with the system <NUM>, peripheral component interfaces designed to enable peripheral component interaction with the system <NUM>, and/or sensors designed to determine environmental conditions and/or location information related to the system <NUM>.

In various embodiments, the user interfaces could include, but are not limited to, a display for rendering <NUM>-D video (e.g., a liquid crystal display, a touch screen display, an auto-stereoscopic display, etc.), a speaker, a microphone, one or more cameras (e.g., a still camera and/or a video camera), a flashlight (e.g., a light emitting diode flash), and a keyboard.

In various embodiments, the peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

In various embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the network interface <NUM> to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

Claim 1:
One or more non-transitory computer-readable media having instructions, stored thereon, that when executed cause a device to:
obtain, from a user equipment, UE, (<NUM>) of a wireless communication network, a Third Generation Partnership, 3GP, Dynamic Adaptive Streaming over Hypertext Transfer Protocol, DASH, profile associated with the UE (<NUM>), wherein the 3GP-DASH profile is a stereoscopic three-dimensional, <NUM>-D, video profile that indicates that video device capabilities of the UE (<NUM>) to render frame-packed 3D video content include a base view and a non-base view packed in a same frame;
identify a first media presentation that complies with the obtained 3GP-DASH profile and is available for delivery to the UE (<NUM>);
obtain a media presentation description, MPD, that includes information associated with the identified first media presentation and information associated with a second media presentation that does not comply with the obtained 3GP-DASH profile;
modify the MPD to exclude the information associated with the second media presentation that does not comply with the obtained 3GP-DASH profile; and
transmit the modified MPD to the UE (<NUM>).