BR112017018324B1 - METHOD FOR MANAGING AN INITIAL TIME OF MEDIA CONTENT ON A RECEIVING DEVICE, COMPUTER READABLE NON-TRANSIENT MEMORY AND RECEIVING DEVICE - Google Patents

Abstract

DELAY COMPENSATION FOR CONTINUOUS STREAM WITH BROADCAST ADAPTIVE BIT RATE. The systems, methods and apparatus of the various embodiments allow management of the initial time of media content in a media receiving apparatus. The processor of the receiving device can receive content from media labeled with the transmission time of a sending device. The processor may determine the service construction delay of the media content of the media content. The processor may determine the time offset of the media content based on the service construction delay. The processor may deliver media content to a media client in a continuous stream at the receiving apparatus using time shifting.

Description

RELATED ORDERS

[0001] This application claims the benefit of priority to North American provisional application No. 62/121 303, entitled “Delay Compensation for Continuous Stream with Broadcast Adaptive Bitrate”, filed on February 26, 2015, and to North American Provisional Application No. 62/126,089, entitled “Delay Compensation for Continuous Streaming with Adaptive Broadcast Bitrate”, filed on February 27, 2015, the entire contents of both applications being hereby incorporated as a reference.

BACKGROUND

[0002] Adaptive bitrate streaming is a technique used to continuously stream media data (such as video, audio and other multimedia data) over a communications network. Examples of adaptive bitrate streaming techniques include Dynamic Adaptive Streaming over the Hyper-Text Transfer Protocol (HTTP)(DASH), Adobe Dynamic Streaming for Flash, Apple HTTP Live Streaming (“HLS”), and Microsoft Smooth Continuous Flow. DASH is adaptive streaming supporting the streaming standard using the HTTP protocol. In a variant of DASH, intermedia gaps may be composed of one or more layered chunks, and each additional layered chunk added to a base cab chunk can increase the media presentation quality for that intermedia gap. Each media presentation can be encoded using a Scalable encoder so that each media gap includes a base layer chunk and one or more enhanced layer chunks.

[0003] Content data (media content, for example) streamed is received and rendered on a receiving device by a client application, such as a streaming media client. Among other delays, received content data may be subject to delays due to processing of the content data by the protocol stack of the receiving device. Although the receiving device can be configured to anticipate a certain level of delay, if there is more or less delay than anticipated, the performance of the streaming media client may be adversely affected. For example, the streaming media client may start presenting content data, or the streaming media client may launch either too early or too late. When the streaming media client starts presenting content data too soon, presentation stalls may result due to a lack of sufficient data for smooth presentation of the content. When the streaming media client starts presenting content data too late, the streaming media client may, among other things, delay the presentation of content data longer than strictly necessary, deteriorating switching performance of channel and increasing total latency unnecessarily.

SUMMARY

[0004] Various embodiments include methods that can be implemented on a receiving device to manage the start time of media content. Various embodiments may include receiving, by the processor of the receiving device, media content labeled with a transmission time from a sending device, determining, by the processor, the service construction delay of the media content, determining, by the processor, the time shifting of the media content based on the service construction delay, and delivering, by the processor, the media content to a streaming media client that utilizes the time shifting.

[0005] Some embodiments may also include determining, by the processor, the starting time of the media content based on the determined time offset, wherein delivering, by the processor, the media content to a streaming media client that uses time shifting includes delivering, by the processor, the media content to the streaming media client, based on the initial time. Some embodiments may also include determining, by the processor, the protocol stack delay of the media content.

[0006] In some embodiments, determining the protocol stack delay of the media content may include determining, by the processor, the local time of the receiving device, and comparing, by the processor, the transmission time with the local time of the receiving device. In such embodiments, determining the time offset of the media content may include determining the time offset based on protocol stack delay.

[0007] In some embodiments, determining, by the processor, service construction of the media content may include determining the service construction delay, based on the transport layer presentation time of the media content. Some embodiments may also include receiving by the processor a request for the byte range of the media content, wherein determining the service construction delay of the media content may include determining the service construction delay based on a service construction delay. service for the requested byte range of media content.

[0008] In some embodiments, in response to a request from a client application to the transport layer of a media content protocol stack that arrives before the requested media content is completely present in a transport buffer, the transport layer protocol stack transport may interpret the request as a request for delivery of the byte range of the requested media content. In some embodiments, determining the start time of the media content based on the determined time offset may include determining the sum of the determined protocol stack delay of the media content and the transport layer presentation time. In some embodiments, the protocol stack delay of the media content may include a delay time due to processing in the media content by the protocol stack at the receiving apparatus.

[0009] In some embodiments, determining the protocol stack delay of the media content may include determining the protocol stack delay after a media content portion of the media content is processed by the transport layer of the protocol stack of the media content. to present. In some embodiments, determining the stack delay of the media content may include retrieving a predetermined stack delay value from the memory of the receiving apparatus. In some embodiments, determining the starting time of the media content may include modifying, by the processor, the media presentation description of the media content based on the time offset and determining, by the processor, the starting time of the media content based on in the modified media description presentation.

[0010] In some embodiments, determining the starting time of the media content may include modifying, by the processor, the local time of the receiving device based on the time offset and determining, by the processor, the starting time of the media content based on the modified local time. In some embodiments, the media content may include a header portion labeled with the transmission time of the sending device. Some embodiments may also include creating, by the processor, a timer based on the given time offset, wherein delivering, by the processor, the media content to a streaming media client that utilizes the time offset, may include delivering, by the processor, the media content to the media client streams in response to the timer expiring.

[0011] Other embodiments may include a receiving apparatus that includes a memory, a receiver circuit, and a processor coupled to the memory and the receiver circuit and configured with processor-executable instructions to perform the operations of the methods described above. Other embodiments may include a receiving apparatus that includes devices for carrying out instructions of the methods described above. Other embodiments may include computer-readable storage media on which processor-executable instructions configured to cause the processor of a receiving apparatus to perform the operations of the methods described above are stored.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The attached drawings, which are incorporated herein and constitute part of this report, show examples of the various modalities and, together with the general description presented above and the detailed description presented below, serve to explain the features of the various modalities.

[0013] Figures 1A and 1B are block diagrams of communication systems suitable for use with the various modalities.

[0014] Figure 2 is a block diagram of the protocol stack of a streaming media client suitable for use with the various modalities.

[0015] Figure 3 is a block diagram of a communication system suitable for use with the various modalities.

[0016] Figure 4A shows relationships of values that can be used to determine the initial time of content availability according to different modalities.

[0017] Figure 4B is a call beam diagram showing a method for managing the initial timing of media content at a receiving apparatus.

[0018] Figure 5 is a processing flow diagram showing a method for managing the initial timing of media content on a receiving device, according to various embodiments.

[0019] Figure 6 is a component diagram of an exemplary receiving apparatus suitable for use with the various modalities.

[0020] Figure 7 is a component diagram of an exemplary server suitable for use with the various modalities.

DETAILED DESCRIPTION

[0021] The various embodiments will be described in detail with reference to the attached drawings. Wherever possible, the same reference numbers will be used in all drawings to refer to the same or similar parts. References made to specific designs and implementations are for illustration purposes and are not intended to limit the scope of the various embodiments or the claims.

[0022] As used herein, the terms “receiving apparatus” and “receiving apparatus” are used interchangeably herein to RSRP any or all cellular telephones, smart telephones, personal or mobile multimedia players, personal data assistant (PDAs), laptop computers, tablet computers, smartbooks, palm-top computers, wireless e-mail receivers, Internet multimedia enabled cell phones, wireless game controllers, personal computers, television set-top box converters, televisions, cable television receivers and similar personal electronic devices that include a processor and memory and programmable circuitry for receiving and presenting media content.

[0023] The various embodiments are described here using the term “content server” to refer to any computing device capable of functioning as a content data provider, such as a master exchange server, a server Web server, an email server, a document server or any other type of server. A content server can be a dedicated computing device or a computing device that includes a server component (which runs an application that can make the computing device function as a server, for example). A server component (a server application, for example) may be a full-function server component or a lightweight or secondary server component (a lightweight or secondary server application, for example) that is configured to provide synchronization services between dynamic databases between mobile devices. A lightweight server or secondary server may be a scaled-down version of server-type functionality that may be implemented on a receiving device, thereby allowing the receiving device to function as an Internet server only to the extent necessary to provide the functionality described herein.

[0024] In a typical content broadcast distribution scheme, the client application of a receiving device typically anticipates the reception of media objects, byte range or first data, at an expected arrival time. The expected arrival time is typically reflected in a Media Presentation Description (MPD) or other data description that is included or transmitted with the content data or in a separate signaling that provides information to the streaming media client to adaptive continuous flow of content. Among other things, MPD can describe the relationship between a presentation timeline and a “wall clock” (that is, a time that can be established in the streaming media client with broadcast or unicast devices). The relationship between the timeline and presentation time can be established by other methods as well.

[0025] The timing relationships between the expected arrival time and the presentation timeline presented in the MPD (or other delivery method) can be used to calculate the presentation timeline. The time relationships may reflect, presented in the MPD, among other things, one or more assumptions about delays in the distribution system within the receiving apparatus. If there is more or less delay than the expected behavior of the broadcast system and the receiving device, the streaming media client of a receiving device may launch or begin presenting content data too early or too late. When the streaming media client starts serving content too soon, presentation stalls can result, and presenting content data too late delays content delivery for longer than strictly necessary, causing deterioration in streaming media performance. changing channels.

[0026] To address these limitations in conventional content broadcast distribution schemes, systems, methods and apparatus, the schemes, discovery request systems, methods and apparatus of the various embodiments manage media content transmission delays to a receiving apparatus determining and compensating for a protocol stack delay that may arise in the receiving device. The receiving apparatus may calculate the time offset between the transmission time (radiation time) of the content data or part of the content data of the sending apparatus and the time at which the content data emerges from a portion of the stack. protocols (the “emergency time”) of the receiving device. Based on the calculated time offset, the receiving device can determine the initial availability time of the content data or a part of the content data. This calculated initial availability time can be analogous to the “segment availability time” as might be used in DASH for a DASH client application that renders segments. In some embodiments, the transmission infrastructure (a content server, for example) may label the content data or a portion of the content data with determined radiation times (i.e., the time at which the portion of the data content is transmitted by the content server). In some embodiments, the irradiation time may be the sender current time (SCT), as described in the proposed standard Layered Coding Transport (LCT) Building Block, Request for Comments (RFC) 5651 < htpp:// tools.ietf.org/html/rfc5651 > October 2009.

[0027] Various embodiments can be implemented in media receiving devices that can function within various communication systems 100A and 100B, two examples of which are shown in Figures 1A and 1B. Referring to Figure 1, a receiving apparatus 102 may communicate with a communications network 108, which may include a base station 104, an access point 106, and a content server 110. The base station 104 may communicate with the communications network 108 via a wired or wireless communications link 114, and the access point 106 may communicate with the communications network via a wired or wireless communications link 118. The communications links 114 and 118 may include fiber optic return transport links, microwave return transport links, and other communication links. In some embodiments, the communications network 108 may include a mobile telephone communications network.

[0028] The receiving apparatus 102 may communicate with the base station 104 via a wireless communication link 112 and with the access point 106 via a communication link 116. In some embodiments, the wireless communication link 112 may include a broadcast or multicast transmission, and the wireless communication link 116 may include a unicast transmission. In some embodiments, unicast transmission may be optional. The content server 110 may be an application server, a media server, or other network node or network element configured to provide content data to a client application 102a, such as the receiving device 112. The server content server 110 may communicate with the communications network via a wired or wireless communication link 120. The receiving device 102 may send requests for content data, such as video, audio, or multimedia content, to the content server 110 through the communications network 108 requesting delivery of the content data to the client application 102a. In response, the content server 110 may stream the requested content data to the receiving apparatus 102 over one or more wireless or wired communication links 120. In some embodiments, the receiving apparatus 102 may receive the data from content requested through a single interface (through a cellular communication interface or through a Wi-Fi communication interface, for example). In some embodiments, the receiving device 102 may receive the content data through multiple interfaces (through Wi-Fi and cellular communication interfaces, for example), and the receiving device 102 can receive multiple parallel streams through multiple network interfaces. .

[0029] The communications network 108 supports communications utilizing one or more radio access technologies, and each of the wireless communications links 112 and 116 may include cellular connections that may be made via bidirectional wireless communications links utilizing one or more radio access technologies. Examples of radio access technologies may include 3GPP Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMax), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA) , Wideband CDMA (WCDMA), Global System for Mobility (GSM), a radio access protocol in the Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol family (Wi-Fi, for example), Systems Commission Advanced Television (ATS) 3.0, Digital Video Broadcasting (DVB)-T2, and other radio access technologies. Although the communication links 112, 116 are shown as single links, each of the communication links may include a series of frequencies or frequency bands, each of which may include a series of logical channels.

[0030] Referring to Figure 1B, in an alternative network configuration, the base station 104 may communicate with a receiving device 122 via communication link 112 and an access point 124 may communicate with the receiving device 222 via a wired or wireless communication link 126. The receiving apparatus 102 may communicate with the access point 124 via a wireless communication link 128, which may include multicast and/or unicast transmissions. The receiving apparatus 222 may be configured to receive content data from the content server 110, for example, via the base station 104, and the access point 124 may be configured to transmit content data received via the receiving apparatus 122 to the receiving device. Thus, content data can pass through an intermediate hop via the receiving device 122 and the access point 124, via a short-range transmission, such as Wi-Fi, for example. Passing the content data through such an intermediate hop can be referred to as “redistribution”.

[0031] Figure 2 shows a protocol stack 200 of a streaming media client (the client application 102a of Figures 1A and 1B, for example) suitable for implementing the various embodiments. Referring to Figures 1A-2, a receiving apparatus (receiving apparatus 102, for example) may receive content data 202 from the physical layer ("PHY layer") 204. The PHY layer may establish a receiver local time 204a (a time “wall clock” receiver, for example). The PHY layer may also provide a local time indication 220, such as a “tick” or other informational announcement, to higher layers of the protocol stack 200. The processor of the receiving device may derive a time (Coordinated Universal Time (UTC) , for example) of the physical layer tick. The physical layer can also be directly labeled with a time indication (UTC, for example).

[0032] The content data 202 may include a media presentation description (MPD) or other media description that may be included in the content data, such as in the header portion of the content data or in some other part of the data of content. The MPD may describe information about the content data in a manner that allows the processor running a client application (the client application 102a, for example) to process and render the content data. Among other things, the MPD can describe the relationship between the presentation timeline and a wall clock (the time that can be established by the PHY layer 204, for example). The MPD may also include timing information, such as one or more delay times assumed by the sender and recorded in the MPD. The MPD may also include a transmission time or irradiation time of the sender of the content data. Timing information can also be incorporated into extension headers of a transport protocol, such as File Delivery over One-Way Transport (FLUTE) or Real-Time Object over One-Way Transport (ROUTE).

[0033] The physical layer 204 may send content data to a machine access control layer 206 such as the media access control (MAC) layer. The MAC layer 206 may send the content data to a networking protocol layer 208 to decode the content data from a network transport protocol (the Internet Protocol (IP), the User Datagram Protocol (UDP) or other similar network transport protocol, for example) an IP/UDP stack. The networking protocol layer 208 may send the content data to a transport layer 210 (the file delivery protocol layer, which may include early error correction (FEC) (application layer (AL)-FEC). , for example). Transport layer 210 may send content data to a client application 212, which may interpret the encoding of the content data according to, for example, a base media file format (BMFF), e.g. example, from the International Organization for Standardization (ISO), or the Media Transport Format (MMT) from the Moving Picture Specialist Group (MPEG). The client application 212 may send the content data to an encoding/coding circuit. decoding (CODEC) 214 for decoding and rendering.

[0034] Content data emerges from the transport layer 210 with a delay 218 resulting from the transport layer 210 with delay 218 resulting from, for example, the delay within the MAC layer 206 and/or the physical layer (PHY) 204 (a storage delay or similar data processing delay, for example). In some embodiments, delay 218 may also include delay introduced by intermediate distribution or redistribution, such as when the client device receives (or fetches) data from a network adapter (the receiving device 222, for example) which may introduce some unknown distribution delay of data content.

[0035] The delay(s) may/may cause the arrival time of the content data to differ from that of the timing information (a delay time, for example) in the MPD. Furthermore, timing derived from the physical layer (PHY layer 204) by the receiving apparatus may be relatively accurate, but may not reflect any delay introduced as content data passes through the protocol stack. The delays 218 may propagate as that the content data moves through the protocol stack 200 and may result in the content data being delivered to the client application 212 at a different time (i.e., a later time than the client application 212 may expect based on the information in the MPD, for example).

[0036] In order to determine the delay of the protocol stack, the PHY layer 204 may provide an indication 220 of the local time (the local time/wall clock time 204a of the receiving device, for example), which the device's processor receiver can compare with the irradiation time (i.e. content data transmission time). The difference between the irradiation time of a data resource (the last byte of a range of bytes, for example) and the wall clock time of the receiving device (which can be established through the physical layer) can indicate the degree of protocol stack delay caused by the processing of the content data by the protocol stack 200. Thus, the presenter can automatically determine the protocol stack delay.

[0037] In addition, or alternatively, the processor of the receiving device may recall the delay value from the protocol stack that may be stored in the memory of the receiving device. For example, the receiving apparatus may be configured with a predetermined protocol stack delay value that has been determined for the specific implementation of the protocol stack in the receiving apparatus. In some embodiments, the predetermined delay value of the protocol stack may be derived by checking a specific protocol stack implemented in a specific receiving apparatus. The predetermined delay value of the protocol stack may be stored in the memory of the receiving apparatus and may be queried and retrieved by the processor of the receiving apparatus. The predetermined delay value of the protocol stack may be updated, for example, in a revised construction of the protocol stack that may be sent to the receiving device.

[0038] Figure 3 is a block diagram of a communication system 300 suitable for use with the various modalities. In some embodiments, the elements of Figure 3 may be similar to elements of the server 110 or the receiving apparatus 102 as described with reference to Figures 1A, 1B and 2.

[0039] Referring to Figures 1A-3, media encoder 302 may receive content data 350 that has been or will be requested by a receiving apparatus (the receiving apparatus 102, for example) or by a client application on the receiving apparatus ( client application 102a, for example). The media encoder 302 may encode the content data and send the encoded content data 352 to a segmenter 304. The segmenter may divide the encoded content data into one or more segments. The segmenter can also record the MPD according to the Sender Current Time (SCT). Typically, the MPD may be in a general object separate from the content data (a segment, for example), although the MPD and content data may be delivered to a receiving device through a common session (a ROUTE session, for example). example) and/or may be delivered in a common byte range.

[0040] The segmenter 310 may provide media-aware byte ranges 356 and other information 354 that may include a destination IP quality of service (QoS) time to a sender network protocol layer 306 (sender IP/UDP, for example). The sender network protocol layer 306 may provide media-aware byte tracks encoded using a network transport protocol 360 (encoded using IP, UDP, and another network transport protocol such as ROUTE or FLUTE, for example) and other information 358, including a forward error correction (FEC) frame tick 362, to an encapsulator 308. The encapsulator 308 may forward the FEC frame tick 362 to a scheduler 310 and may provide media-aware byte tracks 364 encapsulated for network transport using, for example, a generic stream encapsulator (GSE) protocol, to a baseband composer 312.

[0041] The programmer 310 may send physical layer assignments 368 to the baseband composer 312. The programmer may also determine the transmission time (i.e., irradiation time) of the content data. In some embodiments, the transmission time may be set to either a first byte of the content data or the last byte of the content data. The transmission time can be the sender current time (SCT). In some embodiments, the transmission time of the content data may coincide with the most recent time presented in the timing QoS information 354. The scheduler 310 may also provide rate adaptation information 366 (feedback information, for example) to the encoder. of media 302. In some embodiments, scheduler 310 may determine the transmission time that is used to label content data prior to transmission.

[0042] Baseband composer 312 may send to a transmitter 314 content data that is ready for transport 370, as well as a baseband description of the content data. Transmitter 314 may transmit content data 372 to a receiving apparatus. Immediately before or at the transmission time of the content data 372, the transmitter 314 may label (encode, for example) a portion of the content data with the transmission time (the sender's current time (SCT), for example). The transmission time value may be provided by the scheduler 310 and may be encoded by the scheduler 310 and the sender 306. In some embodiments, the sender may establish these fields when creating the transport, so that the size of the transmitted content data does not is changed by applying the label.

[0043] In some embodiments, the transmission time may be encoded in a header form of the content data (or in the header form of a portion of the content data, such as a segment). In some embodiments, the transmission time may be encoded in an EXT_TIME ROUTE header portion. In some embodiments, the header time may be defined as the first byte of a piece of content data (of a segment, for example). In some embodiments, the header time may be set to the last byte of a piece of content data (of a segment, for example). For example, the last byte of a segment can be labeled (encoded, for example) with an SCT that corresponds to the irradiation time of the segment or a byte range (MDE).

[0044] At the receiving apparatus, the receiving elements of the protocol stack can receive the content data at the receiving apparatus. The receiving elements may include the physical layer and the MAC layer (receiver PHY/MAC 316, for example), which may be similar to the PHY layer 204 and the MAC layer 206, described with reference to Figure 2. The PHY/MAC receiver 316 may send byte ranges or media-aware objects 374 that are labeled with a transmission time to a receiver network protocol layer 318 (receiver IP/UDP, for example). The receiver network protocol layer 318 may send content data 378 to higher layers to a protocol stack of the receiving device and ultimately to a client application (client application 102a, for example).

[0045] The receiver PHY/MAC 316 may also send a locally derived time indication (wall clock time, for example) 376 to a comparator, which may be a comparison operation performed by the receiving device's processor. Receiver network protocol layer 318 may provide an indication of the irradiation time of content data 384 (the EXT_TIME label, for example) to comparator 380. Comparator 380 may compare the locally derived time (the wall clock time , for example) and the irradiation time of the content data in order to determine the protocol stack delay 382 of the protocol stack of the receiving apparatus. For example, the comparator 380 may determine the protocol stack delay when the locally derived time 376 is greater than the content data irradiation time indication 384. Using the protocol stack delay 382, the processor of the receiving apparatus may determine the offset time, which the processor of the receiving device can use to compensate for the delay determined by the protocol stack. In some embodiments, the processor of the receiving apparatus may adjust the local wall clock time of the receiving apparatus. In some embodiments, the processor of the receiving device can adjust and/or re-record two or more mMPD parameters, according to the determined travel time.

[0046] Additionally, or alternatively, the processor of the receiving apparatus may recall the protocol stack delay value that may be stored in the memory of the receiving apparatus. For example, the receiving apparatus may be configured with a predetermined protocol stack delay value that has been determined for the particular implementation of the protocol stack in the receiving apparatus. In some embodiments, the predetermined protocol stack delay value may be derived by checking a particular protocol stack implemented in a particular receiving apparatus. The predetermined protocol stack delay value may be stored in the memory of the receiving apparatus and may be queried by the processor of the receiving apparatus.

[0047] Figure 4A shows relationships 400 between values that can be used to determine the initial availability time of content data (the initial segment availability time, for example) according to various embodiments.

[0048] Referring to Figures 1A-4A, the processor of a receiving apparatus (the receiving apparatus 102, for example) may determine the initial content availability time 408 (the initial segment availability time, for example) in accordance with with relationships between different time values. The relationships of the various time values may be defined, for example, in an MPD included in or transmitted with content data or in another similar or related description.

[0049] As described above, a sending apparatus may label content data to be sent to receiving apparatuses with a radiation time 402 (i.e., transmission time). The flight time 412 represents the transit time of the content data from the sending apparatus to the receiving apparatus. The receiving apparatus may determine a local time 404 of the receiving apparatus (wall clock time, for example), from the physical layer of a protocol stack in the receiving apparatus (the PHY layer 204, for example), for example.

[0050] As the content data is processed by the protocol stack of the receiving apparatus, the content data may incur certain delays, such as a receiver PHY/MAC delay 414 and/or a delay due to other parts of the protocol stack 416 before the arrival time 406 of the content data at the top of the protocol stack (the transport layer 210 such as ROUTE or FLUTE, for example). The combination of the receiver PHY/MAC delay 414 and the delay of other parts of the protocol stack 416 can be represented as an implementation implementation-specific delay. A service construction related delay 420 may also be imposed on the content data following the arrival time 406 of the content data at the top of the protocol stack. The service construction related delay 420 may include a waiting time to allow a sufficient amount of the content data to arrive and be stored in the receiving apparatus to allow smooth replay of the content data. The initial content availability time 408 may be determined as a static amount of time after the receiver wall clock time 404. The static difference between the receiver wall clock and the initial content availability time 422 may also be determined as the sum of the specific implementation delay 418 and the delay related to service construction 420.

[0051] In some embodiments, implementation-specific delay 418 may be determined by the processor of a receiving device by comparing the content data irradiation time and/or receiver wall clock time 404. Additionally, or alternatively , the processor of the receiving apparatus may recall a protocol stack delay value that may be stored in the memory of the receiving apparatus, and may use the predetermined protocol stack delay value as the implementation-specific delay 418.

[0052] To determine the initial content availability time 408, the processor of the receiving device may receive at least two of the implementation-specific delay 418, the service construction-related delay 420 and/or the static difference between the wall clock of receiver and initial content availability time 422 may be included, for example, in an MPD of the content data. The specific implementation delay 418 may be determined by the processor of the receiving apparatus, such as by comparing the content data irradiation time and the receiver wall clock time 404 or by using a protocol stack delay value. predetermined.

[0053] Based on the initial content availability time 408, the delivery or fetching time 426 of the content data can be determined by the processor of the receiving device. The delivery or fetching time 426 of the content data may be based on the rendering/replay mode of the content data. For example, if the transport layer of the protocol stack (the transport layer 210, for example) is providing (i.e., delivering) byte ranges or media delivery events (MDEe) of content data to the client application (client application 212, for example), the client application typically does not need to wait as long as the initial content availability time to begin rendering the byte ranges of content data. The processor of the receiving device may determine a byte range delivery time 424 by applying a byte range offset value, such as @tbdByteRangeOffsetTime 430. If the transport layer of the protocol stack is delivering segments of the content data to the client application, the processor of the receiving device may use the initial content availability time 408 as the delivery/fetch time for pieces of content 426 for the client application to fetch (request from a store, for example) pieces (segments , for example) of content.

[0054] In some embodiments, if multiple client applications or multiple receiving apparatus require synchronization such that the multiple client applications/receiving apparatus render content data substantially simultaneously, the processor of the receiving apparatus may add a value additional, such as @suggestedPresentationDeley 433, in order to determine a segment-level seek time synchronized across multiple devices 428 for each streaming media client.

[0055] Alternatively, the byte range delivery time 424 may include a time in which the transport layer (the transport layer 210, for example) can deliver the MDE or byte range to the streaming media client ( client application 212, for example).

[0056] In order to determine the byte range delivery time 424, the processor may determine a service construction delay 432, such as a delay such as a delay related to service construction for representation access point delivery. (RAP) of MDE. In some embodiments, the transport layer may only send an MDE or byte range marked with a RAP, which may be a syntactical indication that the byte range or MDE can be productively processed by the streaming media client.

[0057] Figure 4B is a call flow diagram showing communications in a method 400A for managing the initial timing of media content at a receiving apparatus according to various embodiments. The call flows of method 400A may be implemented by the processor of a wireless receiving apparatus (the wireless receiving apparatus 102 of Figure 1, for example).

[0058] An application 448 may send a content data service request 460 to a service layer 446, and the service layer 446 may send an IP stream request 462 to physical and MAC layers (PHY/MAC 440, e.g. example) of the protocol stack of a receiving device. The physical and MAC layers 440 may begin receiving content data and may deliver the content data, such as IP datagrams 464, up the stack along the protocol stack to a transport layer 442. The transport layer 442 may post (make available, for example) one or more initialization segments (ISs) and an MPD associated with the content data (ISs and MPD 466, for example). A streaming media client (the media data event (MDE) client 444, for example) may fetch 468 the initialization segment(s) and MPD that is made available by the transport layer.

[0059] Transport layer 442 may receive a request for content data (a request for a first media segment 470, for example) and may interpret the request for content data 470 as a request to send byte ranges or MDEs (media delivery events) at the earliest possible time, the determination of which is described below. In response to the content data request 470, the transport layer 442 may send an acknowledgment of the request (OK(200) response 472, for example) to the streaming media client 444. The transport layer 442 may then send to the streaming media client 444 byte ranges or MDEs in a given delivery time (the 424 byte range delivery time, for example).

[0060] In order to determine the time at which a byte track or MDE may be sent from the transport layer 442 to the streaming media client 444, the processor of the receiving apparatus may calculate a service construction related delay for each byte track of the media or MDE (the service construction related delay for RAP delivery of MDE 432, for example). For example, the content data may include two time indications. The first time indication may be an indication on the transmission time (i.e., radiation time) or byte track or MDE, which may be encoded in an EXT_TIME ROUTE header portion. The second time indication may be a transport layer presentation time, which is an indication on the transmission time of the content data plus a service-related delay specific to the byte track or MDE that may be encoded in an EXT_ROUTE_PRESENTATION_TIME ROUTE header portion.

[0061] In some embodiments, the processor may subtract the first time indication from the second time indication. The processor may subtract the value of EXT_TIME from the transport layer presentation time (e.g. value, (EXT_ROUTE_PRESENTATION_TIME)) in order to determine a byte range-specific service-related delay or MDE (the service construction-related delay for delivery RAP MDE 432, for example).

[0062] In order to determine the time in which the transport layer can send the byte strip or MDE to the streaming media client (the byte strip 424 delivery time specific to the byte strip or MDE, e.g. ), the processor may add implementation-specific delay (such as implementation-specific delay 418, such as full protocol stack delay) and byte range-specific service-related delay or MDE. Thus, the processor can determine the time in which the transport layer can deliver an MDE or byte range to the streaming media client, which can be relative to the EXT_TIME of the specific MDE or byte range.

[0063] In addition, or alternatively, the processor may add the implementation specific delay (implementation specific delay 418 or total protocol stack delay, for example) and the transport layer presentation time value (EXT_ROUTE_PRESENTATION_TIME) in order to calculate the delivery time of the byte stream/MDE.

[0064] Using the determined byte strip delivery time, the transport layer 442 can send byte strips or MDEs 474 to the streaming media client. The streaming media client may send the block/MDE row 474 to a CODEC 450 (the CODEC 214, for example) as early-synchronized compressed media 476. The CODEC 450 may process the early-synchronized compressed media 476 (the streams of bytes or MDEs, for example) and may send such processed content data (early synchronized uncompressed media 478, for example) to a presentation layer 452.

[0065] Figure 5 shows a method 500 for managing the transmission delay of media content to a receiving device according to various embodiments. Method 500 may be implemented by the processor of a receiving device (the wireless receiving device 102 of Figure 1, for example).

[0066] In block 502, a sending device (a content server 110, for example) can label content data with an irradiation time (transmission, for example) and, in block 504, the sending device can tag a physical layer with a time indication (may have a physical layer tick or other time indication to allow the receiving device to establish a local/wall clock time, for example). The labeling of content data with the irradiation time can be performed by the transport layer of the sending device's protocol stack, and the marking of the physical layer with the time indication can be performed by the physical layer of the sending device's protocol stack or the sender. The sending apparatus may then send the labeled content data to a receiving apparatus (the receiving apparatus 102, for example) via a defined transmit and receive stack of the receiving apparatus.

[0067] In block 506, the receiving device can receive content data labeled with the irradiation time, as, for example, in the physical layer of the protocol stack in the receiving device (PHY layer 204, for example). In block 508, the receiving apparatus may receive a time indication through the physical layer of the protocol stack.

[0068] In block 510, the processor of the receiving device may process the content data received in the protocol stack of the receiving device. In block 512, the receiver indication apparatus processor may establish a local time of the receiving apparatus (a local wall clock or receiver wall clock, for example) from information provided by the protocol stack, for example. In some embodiments, the physical layer of the protocol stack of the receiving device may establish the local time of the receiving device based on the physical layer marking of the time indication of the sending device.

[0069] In block 514, the processor of the receiving device may recover the label irradiation time of the content data.

[0070] In block 516, the processor may compare the recovered irradiation time with the established local time of the receiving apparatus and may determine a protocol stack delay based on the comparison.

[0071] In block 518, the processor may determine a time offset based on comparing the recovered irradiation time with the established local time of the receiving apparatus. In some embodiments, the processor may create a timer based on the given time offset. The processor may use the given timer to determine the time to deliver the media content to the streaming media client.

[0072] In optional block 520, the processor may modify one or more MPD values of the content data using the determined time offset. In optional block 502, the processor may adjust the local time of the receiving device using the time domain time shift.

[0073] In block 524, the processor may determine that a streaming media client (or client application 212 and streaming media client 444, for example) is requesting byte ranges or MDEs. For example, the transport layer of the protocol stack (transport layer 210 and transport layer 442, for example) may interpret a request for content data as a request to send byte ranges or MDEs at the earliest possible time. .

[0074] In block 526, the processor may determine a byte range delivery time (the byte range delivery time 424, for example) such as a time at which the transport layer can deliver an MDE or byte range. bytes to the streaming media client. In some embodiments, the processor may determine the byte range delivery time by adding an implementation-specific delay (implementation-specific delay 218, which may be the total protocol stack delay, for example) and a service-related delay. specific to the byte range or MDE (the delay related to building services for RAP MDE 430 delivery, for example). In addition, or alternatively, the processor may calculate the byte range/MDE delivery time by adding the implementation specific delay (i.e., deployment specific delay 418) and a transport layer presentation time value (EXT_ROUTE_PRESENTATION_TIME ).

[0075] In block 528, the processor may deliver a byte strip or MDE to the streaming media client using the byte strip delivery time. Using byte range delivery time, for example, the processor can deliver content data (a byte range or MDE, for example) to a client application interface (to a ROUTE/DAS interface, for example) as streams of bytes/MDEs. In some embodiments, the processor may determine that the timer created based on the given time offset has expired. In such embodiments, the processor may deliver the media content to the streaming media client in response to the expiration of the timer (in response to determining that the timer has expired, for example).

[0076] The various embodiments may be implemented in any of a number of receiving devices, an example of which is shown in Figure 6. For example, the receiving device 600 may include a processor 602 coupled to internal memories 604 and 606. The internal media 604 and 606 may be volatile or non-volatile memories and may also be secure and/or encrypted memories or insecure and/or unencrypted memories, or any combination thereof. The processor 602 may also be coupled to a touchscreen monitor 612, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, or the like. Furthermore, the monitor of the receiving apparatus 600 does not need to have touch screen capability. The receiving device 600 may have one or more radio signal transceivers 608 (Peanut®, luetooth®, Zigbee®, Wi-Fi, radio frequency (RF), for example) and antennas 610, for sending and receiving, coupled together and /or to the processor 602. The receiving apparatus 600 may include a cellular network interface such as a wireless modem chip 612, which allows communication over a cellular data network (CDMA, TDMA, GSM, PCS, 3G, 4G , LTE, ATSC 3.0, DVD-T2 or any other type of cellular or broadcast data network, for example) and is coupled to the processor 602. The peripheral device connection interface 618 can be uniquely configured to accept a type or multiple configured to accept various types of common or proprietary physical communications connections, such as USB, FireWire, Thunderbolt, or CI. The peripheral device connection interface 618 can also be coupled to a similarly configured peripheral device connection port. The receiving apparatus 600 may also include speakers 614 to provide audio outputs. The receiving apparatus 600 may include a housing 620 constructed of plastic, metal, or a combination of materials, to contain all or some of the components discussed herein. The receiving apparatus 600 may include a power source 622 coupled to the processor 602, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the receiving device 600. The receiving device 600 may also include a physical button 624 for receiving user input and a power button 626 to turn the receiving apparatus 600 on and off.

[0077] The various embodiments can also be implemented on any of a number of commercially available server devices, such as the server 700 shown in Figure 7. Such server 700 typically includes a processor 701 coupled to a volatile memory 702 and a non-volatile memory large capacity, such as disk drive 704. Server 700 may also include a floppy disk drive, compact disk (CD) or DVD drive 706 coupled to processor 701. Server 700 may also include access ports to networks 703 coupled to processor 701 to establish network interface connections to a network 707 such as a local area network coupled to other computers and broadcast system servers to the Internet, the public switched telephone network, and /or to a cellular data network (CDMA, TDMA, GSM, PCS, 3G, 4G, LTE or any other type of cellular data network, for example).

[0078] Processors 602 and 702 may be any microprocessor, programmable microcomputer, or various processor chips that can be configured by software instructions (applications) to perform various functions, including the functions of the various embodiments described above. In some devices, multiple processors may be featured, such as a processor dedicated to wireless communications functions and a processor dedicated to running other applications. Typically, software applications may be stored in internal memory 604, 606, 702, 704 before being accessed and loaded into processors 602 and 701. Processors 702 and 701 may include internal memory sufficient to store application software instructions. In many devices, the internal memory may be volatile or non-volatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to a memory accessible by processors 602 and 701, including internal memory or removable memory connected to the apparatus and memory within the processors 602 and 701 themselves.

[0079] The preceding method descriptions and processing flow diagrams are presented merely as illustrative examples and are not intended to require or imply that the operations of various embodiments must be performed in the order presented. As will be understood by those skilled in the art, the order of operations in the foregoing embodiments may be any order. Words like “next,” etc., are not intended to limit the order of operations. These words are simply used to guide the reader through the description of the methods. Furthermore, any reference to claim elements in the singular, using the articles “a/a”, “the/the(s)” should not be interpreted as limiting the element to the singular.

[0080] The various blocks, components, circuits and operations of illustrative logical algorithms described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software or combinations of both. To clearly illustrate this interchangeability of hardware and software, several illustrative components, blocks, configurations, modules, circuits and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art may implement the described functionality in varying ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0081] The hardware used to implement the various logics, logic blocks, components and illustrative logic circuits described in connection with the embodiments disclosed herein can be implemented or executed with a general purpose processor, a digital signal processor (DSP), a application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein . A general purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller or state machine. A processor may also be implemented as a combination of computing devices, such as, for example, a combination of DSP and microprocessor, a series of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other configuration as such. Alternatively, some steps or methods may be performed by a set of circuits that is specific to a given function.

[0082] In one or more embodiments, the described functions can be implemented in hardware, software, firmware or any combinations thereof. If implemented in software, functions may be stored as one or more processor-executable instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The method or algorithm steps disclosed herein may be embodied in a processor-executable software component that may reside on a computer-readable or non-transient processor-readable medium. Computer-readable or non-transient processor-readable storage media may be any storage media that can be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, disk storage magnetic or other magnetic storage devices or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), flexible disc, and Blu-ray disc, where discs usually reproduce data magnetically, while discs ) usually reproduce data optically with lasers, combinations of the above elements are also included within the range of non-transient computer-readable and processor-readable media. In addition, method or algorithm operations may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

[0083] The preceding description of the disclosed embodiments is presented to allow any person skilled in the art to manufacture or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to some embodiments without departing from the scope of the claims. Accordingly, the claims are not intended to be limited to the embodiments shown herein, but are to be given the broadest scope compatible with the following claims and the novel principles and features disclosed herein.

Claims (11)

1. Method (500) for managing an initial time of media content on a receiving device, characterized in that it comprises: receiving (506), by a processor of the receiving device, media content labeled with a transmission time from from a sending device; receiving, by the processor, a request (474) for a byte range of media content; determine, by the processor, a service construction delay (432) for the requested byte range based on the transmission time from the sending apparatus and a transport layer presentation time, the transport layer presentation time being an indication of the transmission time plus a related service delay specific to the byte range; determining, by the processor, a byte range protocol stack delay by: determining, by the processor, a local time of the receiving apparatus; and compare, by the processor, the transmission time with the local time of the receiving device; determining (526), by the processor, a time offset (424) of the byte range based on the service construction delay and protocol stack delay; and delivering (528), by the processor, the byte range to a streaming media client using time shifting (424). 2. The method of claim 1, further comprising: determining, by the processor, a starting time of the media content based on the determined time offset, wherein delivering, by the processor, the media content to a streaming media client using the adjusted service construction delay comprises: delivering, by the processor, the media content to the streaming media client based on the starting time. 3. The method of claim 1, wherein, in response to a request from a client application to a transport layer of a protocol stack for media content arriving before the media content requested is completely present in a transport store, the transport layer of the protocol stack interprets the request as a request for delivery of the requested byte range of media content. 4. Method according to claim 1, characterized in that the protocol stack delay of the media content comprises a delay time due to the processing of the media content by a protocol stack of the receiving device. 5. The method of claim 1, wherein determining a protocol stack delay of the media content comprises determining the protocol stack delay after a media content portion of the media content is processed by a transport layer of a protocol stack of the receiving device. 6. The method of claim 1, wherein determining a protocol stack delay of the media content comprises retrieving a predetermined protocol stack delay value from a memory of the receiving apparatus. 7. The method of claim 2, wherein determining an initial time of the media content comprises: modifying, by the processor, a media presentation description of the media content, based on the time offset; and determining, by the processor, a starting time of the media content, based on the description of the modified media presentation. 8. The method of claim 2, wherein determining a starting time of the media content comprises: modifying, by the processor, a local time of the receiving apparatus based on the time offset; and determining, by the processor, a starting time of the media content based on the modified local time. 9. Method, according to claim 1, characterized by the fact that it additionally comprises: creating, by the processor, a timer, based on the determined time offset; wherein delivering, by the processor, the media content to a streaming media client utilizing time shifting comprises delivering, by the processor, the media content to the streaming media client in response to the expiration of the timer. 10. Non-transitory computer-readable memory (604) containing computer-executable instructions configured to cause a processor (602) of a receiving apparatus (600) to perform steps, said memory characterized by the fact that it comprises: receiving content from media labeled with a transmission time from a sending device; receiving a request (474) for a byte range of media content; determine a service construction delay for the requested byte range based on the transmission time from the sending device and a transport layer presentation time, the transport layer presentation time being an indication of the longest transmission time. a service related delay specific to the byte range; determining a byte range protocol stack delay by: determining a local time of the receiving apparatus; and compare the transmission time with the local time of the receiving device; determining a byte range time offset based on service construction delay and protocol stack delay; and delivering the byte range to a streaming media client using time shifting (424). 11. Receiving apparatus (600), characterized in that it comprises: means for receiving media content labeled with a transmission time from a sending apparatus; means for determining a service construction delay (432) for the requested byte range based on the transmission time from the sending apparatus and a transport layer presentation time, the transport layer presentation time being an indication transmission time plus a related service delay specific to the byte range; means for determining a byte range protocol stack delay by: determining, by the processor, a local time of the receiving apparatus; and compare, by the processor, the transmission time with the local time of the receiving device; means for determining a time offset (424) of the byte range based on service construction delay and protocol stack delay; and means for delivering the byte range to a streaming media client using time shifting.