WO2017207861A1 - Agencement destiné à l'organisation de média en continu - Google Patents

Agencement destiné à l'organisation de média en continu Download PDF

Info

Publication number
WO2017207861A1
WO2017207861A1 PCT/FI2016/050377 FI2016050377W WO2017207861A1 WO 2017207861 A1 WO2017207861 A1 WO 2017207861A1 FI 2016050377 W FI2016050377 W FI 2016050377W WO 2017207861 A1 WO2017207861 A1 WO 2017207861A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
metadata
content
chunk
chunks
Prior art date
Application number
PCT/FI2016/050377
Other languages
English (en)
Inventor
Janne Lintuala
Tommi KETOLA
Original Assignee
Teleste Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Teleste Oyj filed Critical Teleste Oyj
Priority to PCT/FI2016/050377 priority Critical patent/WO2017207861A1/fr
Publication of WO2017207861A1 publication Critical patent/WO2017207861A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present invention relates to transmission of media and in particular to the organization of data transmitted in a media stream. Background of the invention
  • Video distribution systems conventionally include a video source and at least one receiving device to receive video content.
  • the video content may be distributed over a network, such as broadcast television, Over The Top (OTT) delivery, Internet Protocol Television (IPTV), etc.
  • Network-based media delivery services typically code an input video sequence as coded video data that has been parsed into a plurality of separately deliverable segments.
  • HTTP Live Streaming is the most widely adopted Internet video delivery protocol and it is widely supported in mobile operating systems and modern browsers. This makes it currently a de-facto standard for OTT video delivery. Instead of streaming the video from a server to a playback client, the client is essentially downloading video as multiple HLS segments using HTTP protocol.
  • the length of a HLS segment is typically equivalent to a playback time of 10 seconds.
  • the relatively large file length together with the fact that the client device may often select from multiple bitrates, makes the HLS resistant to short-term congestion. This makes HLS a very favorable technique to stream video files stored in a network server.
  • HLS can also be used for live streams, but it has a considerable latency because the built-in playback components of a video player typically buffer 2 - 3 HLS segments before the video playback is started. Considering all delay components of the system, the end-to- end latency typically increases to 30 - 40 seconds. For video systems requiring nearly real-time playback, such as various surveillance systems, such delay is too long. Summary of the invention
  • a method according to the invention is based on the idea of obtaining multimedia data arranged in segments according to a streaming protocol; dividing the multimedia data into a plurality of data chunks; creating metadata relating to content of each data chunk; and interleaving the metadata and the data chunks into a transmission frame having structure such that the metadata of the associated data chunk precedes said associated data chunk.
  • the multimedia data is arranged in segments according to HTTP Live Streaming (HLS) protocol or Dynamic Adaptive Streaming over HTTP (DASH) protocol.
  • HLS HTTP Live Streaming
  • DASH Dynamic Adaptive Streaming over HTTP
  • the method further comprises generating a plurality of data chunks per one second of playback time.
  • the metadata comprises a security record associated with the data chunk and content metadata of the data chunk.
  • an encryption key is associated with security record.
  • the encryption key is obtained from a trusted third party.
  • the data chunks are encrypted using a streaming protocol specific encryption scheme.
  • the security record comprises one or more of the following:
  • a field for a network address such as an URL of the trusted third party
  • the content metadata comprises one or more of the following:
  • an apparatus comprising: a processor; and a memory unit operatively connected to the processor wherein the apparatus is configured to: obtain multimedia data arranged in segments according to a streaming protocol; divide the multimedia data into a plurality of data chunks; create metadata relating to content of each data chunk; and interleave the metadata and the data chunks into a transmission frame having structure such that the metadata of the associated data chunk precedes said associated data chunk.
  • a computer program product embodied on a computer-readable medium, for arranging multimedia data for distribution, comprising computer code adapted to perform: obtaining multimedia data arranged in segments according to a streaming protocol; dividing the multimedia data into a plurality of data chunks; creating metadata relating to content of each data chunk; and interleaving the metadata and the data chunks into a transmission frame having structure such that the metadata of the associated data chunk precedes said associated data chunk.
  • Fig. 1 shows a functional block diagram of an exemplary streaming system
  • Fig. 2 shows how the media streams, such as video streams, are organized into HLS segments
  • Fig. 3 shows a flow chart of a streaming method according to an embodiment of the invention; shows a principle of dividing HLS segments into data chunks according to an embodiment of the invention; illustrates obtaining encryption keys for the data chunks encrypted with the security record according to an embodiment of the invention;
  • Figs. 6a, 6b show examples how the data chunks and the associated metadata may be multiplexed into the frame structure according to an embodiment of the invention.
  • Fig. 7 shows an example streaming system according to an embodiment. Description of embodiments
  • HLS streaming systems In the following, the invention will be illustrated by referring to HLS streaming systems. It is, however, noted that the invention is not limited to HLS solely, but it can be implemented in any similar system as the technology advances.
  • Dynamic Adaptive Streaming over HTTP (DASH), (a.k.a. MPEG-DASH) streaming system may be utilised in the implementation.
  • DASH Dynamic Adaptive Streaming over HTTP
  • MPEG-DASH Dynamic Adaptive Streaming over HTTP
  • FIG. 1 shows a functional block diagram of an exemplary streaming system 100, wherein the embodiments described below may be implemented.
  • the system 100 may include a media server 1 10, a distribution server 120 and a communication network 130 for delivering media data to one or more client devices 140, 142, 144. From the perspective of the client devices, the media server 1 10 and the distribution server 120 may be considered together to form a media source 150.
  • the media server 1 10 takes input streams of media and the encoder 1 12 encodes the streams according to a predetermined encoding scheme and encapsulates the encoded streams in a format suitable for delivery.
  • the streams are encoded according to MPEG-2 encoding and they are encapsulated as MPEG-2 Transport Streams (MPEG-2 TS).
  • MPEG-2 TS MPEG-2 Transport Streams
  • the segmenter 1 14 organizes the encoded input media stream as a plurality of coded segments 1 16a -1 16n and generates a playlist 1 17 to identify the segments.
  • the coded segments may also be referred to as HLS segments.
  • the input media stream may also be readily in the MPEG-2 TS format, in which case the encoded input media stream may be provided directly to the segmenter 1 14.
  • Each coded segment may be stored by the media server 1 10 at locations that can be referenced by unique URLs (Uniform Resource Locators).
  • Each coded segment is indexed by the media server, whereupon e.g. the URL, a program date and time are associated with the coded segment in an index file.
  • the playlist is created on the basis of the index files, and it identifies the available media streams and the locations of each segment as stored at the media source.
  • the playlist 1 17 and coded segments of the available media resources 1 16a -1 16n are stored in data storage 1 18, which is accessible by the distribution server 120.
  • the playlist is published to the client devices and it includes a plurality of tags that provide information to the client regarding the content of the media stream.
  • the distribution servers 120 are typically standard web servers. It is noted that while Figure 1 shows the data storage 1 18 as residing in the media server, it may as well be provided in the distribution server or in both.
  • the distribution server 120 is responsible for accepting client requests and delivering prepared media and associated resources to the client.
  • the distribution server 120 maintains and publishes URLs of the playlists of the media source 1 10, on the basis of which the client requests may be generated.
  • the distribution server 120 may transmit the coded segments 1 16a - 1 16n via one or more channels of the communication network 130.
  • the media server 110 and/or the distribution server 120 may buffer coded video segments for a predetermined amount of time.
  • the buffer is continually updated such that older segments are deleted from the buffer as new segments are generated and stored.
  • the playlist 1 17 is updated over time according to sliding window principle to reflect the updated content of the buffer.
  • the client devices 140, 142, 144 may be provided with standard media players that request and download coded segments from the distribution server 120.
  • the coded segments are decoded and rendered for playback.
  • the client device downloads the playlist 1 17 from the distribution server 120, whereupon the client device may request a particular coded segment for delivery and decoding. After decoding and rendering the requested coded segment, the client device may request the next entry in the playlist 1 17 from the distribution server 120.
  • the client device may periodically refresh its copy of the playlist 1 17 and continue with the above process by downloading further coded segments from the distribution server 120 until the client device discontinues playing the media stream.
  • a distribution server 120 may transmit multiple (different) media streams to multiple client devices.
  • the distribution server 120 may transmit a common media stream to multiple client devices using different bit rates and/or different frame sizes according to playback capabilities of different types of client devices.
  • various network architectures may be used between the media source 150 and the client devices 140, 142, 144. For example, there may be gateway devices or routers providing a connection to the client device by a wired or wireless local area network.
  • Figure 2 illustrates how the media streams, such as video streams, are organized into HLS segments.
  • a video stream may be represented as a sequence of individual source frames which may be organized into video segments.
  • the sequence of individual source frames may be encoded according to one or more compression algorithms in order to obtain a sequence of compressed frames with a reduced data rate as compared to the source frames.
  • the encoded video frames are encapsulated into MPEG-2 TS packets, and a plurality of MPEG-2 TS packets (p1 , p2, pn) are combined together to form a HLS segment.
  • the length of a HLS segment is typically equivalent to a playback time of 10 seconds.
  • the relatively large file length together with the fact that the client device may often select from multiple bitrates, makes the HLS resistant to short-term congestion, and therefore, HLS can easily adapt to changing delivery conditions of unmanaged Internet. This makes HLS a very favorable technique to stream video files stored in a network server.
  • HLS can also be used for live streams, but it has a considerable latency because the built-in playback components of the operating system or the browser typically buffer at least two, usually three HLS segments before the video playback is started. Considering all delay components of the system, the end-to-end latency typically increases to 30 - 40 seconds with the default 10 second HLS segment size.
  • the latency may be reduced by decreasing the HLS segment size to 1 - 2 seconds.
  • this has the adverse effect on increasing the number of video segments to be stored in data storage and indexed in a database.
  • the number of HTTP operations increase, which will increase the cost of using cloud platforms.
  • the latency is still in the region of 5-10 seconds and the playback operation may be susceptible to an additional latency, because the playback component behaviour is optimised for the nominal 10 second segment size.
  • an improved HLS streaming method is introduced herein for enabling a significant reduction in the end-to-end latency when playing live material, while still maintaining full HLS compatibility for storage and playback of recorded material.
  • multimedia data arranged in segments according to a streaming protocol such as in HTTP Live Streaming (HLS) segments, is obtained (300).
  • the multimedia data is divided (302) into a plurality of data chunks (a.k.a. sub-segments), and metadata relating to content of each data chunk is created (304).
  • the metadata and the data chunks are interleaved (306) into a transmission frame structure such that the metadata of the associated data chunk precedes said associated data chunk.
  • a transmission frame structure which enables the playback components of a HLS player to start the decryption and the playback already when a fraction of a HLS segment has been received.
  • the sender of the multimedia data arranges the multimedia data into said frame structure, whereupon the receiver may start the decryption and the playback of the data chunks as soon as a predetermined number of data chunks and their associated metadata have been received.
  • the decryption may be started when at least one encrypted block is received, but practically the decryption may be carried out for a whole data chunk.
  • the playback may depend on the used player, for example for HTML5 players, a Group- Of- Pictures (GOP) may be needed before starting the playback.
  • GOP Group- Of- Pictures
  • the decoding and playback may start even when only a few data chunks have been received.
  • the end-to-end latency in the playback of live streams may be significantly reduced, for example into 2 - 3 seconds in total.
  • Figure 4 illustrates the principle of dividing the content of the HLS segment, organized as shown in Figure 2, into data chunks. It is noted that the lengths of the data chunks in Figure 4 are not in scale with the length of the HLS segment. According to an embodiment, a plurality of data chunks is generated per one second of playback time. At minimum, the data chunk may consist of only one video frame, which corresponds to a playback time of 1/25 second (40 ms). The length of the data chunks may be constant or it may be dynamically adjustable within a HLS segment.
  • the metadata comprises a security record associated with the data chunk and content metadata of the data chunk.
  • each data chunk may be encrypted with an encryption key.
  • the encrypted data is associated with a security record that is used to derive the encryption key and determine the authorization for the decryption of the encrypted data chunk.
  • FIG. 5 illustrates the principle of obtaining the encryption key when the playback component of a player 500 receives the data chunk 502 encrypted with the security record 504.
  • the encryption keys may be managed by a trusted third party 506, from which the playback component may query the encryption key for the particular data chunk.
  • the playback component, or a decryption application 508 therein sends 510 its identification and the security record 504 received in the metadata to the third party.
  • An application 512 of the trusted third party authenticates the playback component and derives the encryption key based on the identification and the information of the security record.
  • the trusted third party sends 510 the encryption key to the playback component, which uses the encryption key to obtain decrypted content 512 of the data chunk.
  • the encryption key is obtained from the trusted third party using a HTTP GET operation.
  • the data chunks are encrypted using Advanced Encryption Standard AES-128 encryption scheme.
  • the security record comprises one or more of the following:
  • a field for a network address e.g. an URL
  • a network address e.g. an URL
  • the content metadata comprises one or more of the following:
  • Figures 6a and 6b show two examples how the data chunks and the associated metadata may be multiplexed into the frame structure.
  • the metadata N associated with the data chunk N precedes the data chunk N.
  • the metadata N+1 associated with the data chunk N+1 may precede the data chunk N+1 , etc.
  • the associated metadata is preferably received before the encrypted data chunk such that the encryption key may be derived from the trusted third party in advance. Because of the transaction latency in communicating with the trusted third party, at least the security record part of the metadata may be provided earlier in the frame structure, for example several seconds before the encrypted data chunk. Thus, the player may obtain the encryption key in advance and start the decryption as soon as it receives the data chunk corresponding to the encryption key.
  • This multiplexing scheme may be used to ensure that the encryption keys of the data chunks are received in time. The encryption key may be guaranteed to be unchanged such that no new transactions with the trusted third party are needed.
  • the sender may preferably transmit the data chunks and the associated metadata as soon as they become available.
  • the receiver of the transmission frame may be e.g. a player having necessary playback components or an intermediate server performing forwarding and/or storing of the data. If the receiver of the data is a player, the player may perform a method comprising: receiving a transmission frame comprising multimedia data divided into a plurality of data chunks and metadata of each associated data chunk preceding said associated data chunk; buffering the multimedia data of a predetermined amount of data chunks de- multiplexed on the basis of said metadata; and re-multiplexing the multimedia data into data fragments suitable for streaming playback. According to an embodiment, the multimedia data is re-multiplexed into MPEG4 fragments.
  • the data chunks are encrypted using a streaming protocol specific encryption scheme and the metadata comprises an association to an encryption key
  • the demultiplexing comprises obtaining the encryption key from a trusted third party, and decrypting the encoded data chunks for buffering.
  • the data chunks are decrypted, buffered, decoded and displayed as they become available.
  • the playback may start as soon as a predetermined amount of decrypted data chunks is buffered, e.g. corresponding to a playback time of 2 - 3 seconds.
  • HTML5 Media Source Extensions may be used to re- multiplex the data from the data chunk into a format (such as MPEG4 fragments), which can be played by the HTML5 video player.
  • the typical buffering size is one Group-Of-Pictures (GOP), which may correspond to duration of one second.
  • the receiver of the data is a server performing store-and-forward
  • the data chunk may be forwarded to the next component, such as another intermediate server, a gateway or a player, immediately after the data chunk is received.
  • the data chunks are buffered until data of a complete HLS segment is received.
  • the data is re-assembled into a regular HLS segment, and the HLS segment is stored in a data storage and indexed in the database. As a result, the stored data is in the exact format needed for efficient HLS video delivery.
  • the framing principle supports multiple methods of transport including HTTP/HTTPS and RTP/SRTP ((Secure) Real-time Transport Protocol).
  • the selected transport method may depend on the underlying communication system: for example, RTP can be used in point-to-point and point-to-multipoint communication over Local Area Network or Internet, whereas HTTP can be used in client-server architectures over Internet.
  • Figure 7 shows an example streaming system according to an embodiment, where a sender 700 creates streams, which are divided into data chunks as described above, and sends them to a store-and- forward server 702.
  • player 704 which is capable of processing the chunked streams almost in real time, herein referred to as HLS-RT (Real Time) player
  • HLS-RT Real Time
  • conventional HLS Player 706 which capable of only play back regular (non-chunked) HLS streams.
  • the operation of the store-and-forward server 702 depends on the capabilities of the player.
  • the store-and-forward server 702 relays the chunked stream as such to the HLS-RT player 704.
  • the server 702 reassembles the HLS segments from the data chunks for storage and forwards the HLS segments to the HLS Player 706.
  • the system shown in Figure 7 may be utilised in various video surveillance systems, for example.
  • the sender 700 may be provided with a surveillance camera capturing video data about an area to be monitored.
  • the video data may be encoded into a format suitable for streaming, such as in H.264 format.
  • the sender 700 produces a stream divided into data chunks as described above, and sends it to the store-and-forward server 702.
  • WebSockets may be used in the transportation, where the data chunks are transferred in binary frames and the metadata in text-based frames.
  • the transportation from the server 702 to the HLS-RT player 704 may use WebSockets to implement HTTP compatible push streaming.
  • the framing on top of the WebSockets may be implemented with a suitable lightweight protocol, such as STOMP (Simple Text Oriented Message Protocol).
  • STOMP Simple Text Oriented Message Protocol
  • the server 702 relays the data chunks and the metadata to HLS-RT player 704 immediately upon reception.
  • HLS-RT Player 704 may use the Media Source Extension to re-multiplex the received chunks into MPEG4 media fragments. HTML5 video element may be used for playback of the fragments.
  • the transportation from the server 702 to the conventional HLS player 706 is implemented as normal HLS, where the server 702 provides playlists and media segments for the player to download.
  • the latency from the sender (camera) 700 to the HLS-RT player 704 is typically about two seconds, whereas the latency from the sender 700 to the conventional HLS Player 706 is typically about 40 seconds.
  • the system of Figure 7, due to being rather straightforward and inexpensive to implement may be utilized, for example, in various home surveillance systems.
  • the camera may provide video data, for example, about home indoor/outdoor area, as a door phone video or surveillance data in elderly peoples' home care system.
  • the end-to- end latency in the chunked data stream is so minimal that the video data can be followed practically in real-time.
  • the store-and-forward server stores the streams as re-assembled to regular HLS segment, whereupon the surveillance data may be checked afterwards to address any incidents.
  • the systems may be embodied as hardware, in which case, the illustrated blocks may correspond to circuit sub-systems within the systems.
  • the components of the systems may be embodied as software, in which case, the blocks illustrated may correspond to program modules within software programs.
  • the systems may be hybrid systems involving both hardware circuits and software programs.
  • Some embodiments may be implemented, using a non-transitory computer-readable storage medium or article which may store an instruction or a set of instructions that, if executed by a processor, may cause the processor to perform a method in accordance with the disclosed embodiments.
  • the exemplary methods and computer program instructions may be embodied on a non-transitory machine- readable storage medium.
  • a server or database server may include machine-readable media configured to store machine executable program instructions.
  • the features of the embodiments of the present invention may be implemented in hardware, software, firmware, or a combination thereof and utilized in systems, subsystems, components or subcomponents thereof.
  • the machine- readable storage media may include any medium that can store information. Examples of a machine-readable storage medium include electronic circuits, semiconductor memory device, ROM, flash memory, erasable ROM (EROM), floppy diskette, CD-ROM, optical disk, hard disk, fiber optic medium, or any electromagnetic or optical storage device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention consiste : à obtenir des données multimédia agencées dans des segments conformément à un protocole de diffusion en continu ; à diviser les données multimédia en une pluralité de blocs de données ; à créer des métadonnées se rapportant au contenu de chaque bloc de données ; et à entrelacer les métadonnées et les blocs de données en une trame de transmission possédant une structure de telle sorte que les métadonnées du bloc de données associées précèdent ledit bloc de données associées.
PCT/FI2016/050377 2016-05-30 2016-05-30 Agencement destiné à l'organisation de média en continu WO2017207861A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/FI2016/050377 WO2017207861A1 (fr) 2016-05-30 2016-05-30 Agencement destiné à l'organisation de média en continu

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FI2016/050377 WO2017207861A1 (fr) 2016-05-30 2016-05-30 Agencement destiné à l'organisation de média en continu

Publications (1)

Publication Number Publication Date
WO2017207861A1 true WO2017207861A1 (fr) 2017-12-07

Family

ID=60478061

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2016/050377 WO2017207861A1 (fr) 2016-05-30 2016-05-30 Agencement destiné à l'organisation de média en continu

Country Status (1)

Country Link
WO (1) WO2017207861A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019227736A1 (fr) * 2018-05-29 2019-12-05 北京字节跳动网络技术有限公司 Procédé et appareil de lecture de réseau destinés à un fichier multimédia et support d'informations
CN110545483A (zh) * 2018-05-29 2019-12-06 北京字节跳动网络技术有限公司 网页中切换分辨率播放媒体文件的方法、装置及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110246616A1 (en) * 2010-04-02 2011-10-06 Ronca David R Dynamic Virtual Chunking of Streaming Media Content
WO2012032502A1 (fr) * 2010-09-10 2012-03-15 Nokia Corporation Procédé et appareil de diffusion en continu adaptative
WO2012166813A1 (fr) * 2011-06-03 2012-12-06 Apple Inc. Listes de lecture pour une diffusion en continu en temps réel ou quasi en temps réel
WO2013163448A1 (fr) * 2012-04-26 2013-10-31 Qualcomm Incorporated Système de diffusion en continu à demande de blocage amélioré pour gérer la diffusion en continu à latence faible
US20140365759A1 (en) * 2013-06-06 2014-12-11 Futurewei Technologies, Inc. Signaling and Carriage of Protection and Usage Information for Dynamic Adaptive Streaming
WO2015191177A1 (fr) * 2014-06-11 2015-12-17 Google Inc. Lecture de média de diffusion en continu améliorée
US20160088322A1 (en) * 2014-09-22 2016-03-24 Arris Enterprises, Inc. Video Quality of Experience Based on Video Quality Estimation

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110246616A1 (en) * 2010-04-02 2011-10-06 Ronca David R Dynamic Virtual Chunking of Streaming Media Content
WO2012032502A1 (fr) * 2010-09-10 2012-03-15 Nokia Corporation Procédé et appareil de diffusion en continu adaptative
WO2012166813A1 (fr) * 2011-06-03 2012-12-06 Apple Inc. Listes de lecture pour une diffusion en continu en temps réel ou quasi en temps réel
WO2013163448A1 (fr) * 2012-04-26 2013-10-31 Qualcomm Incorporated Système de diffusion en continu à demande de blocage amélioré pour gérer la diffusion en continu à latence faible
US20140365759A1 (en) * 2013-06-06 2014-12-11 Futurewei Technologies, Inc. Signaling and Carriage of Protection and Usage Information for Dynamic Adaptive Streaming
WO2015191177A1 (fr) * 2014-06-11 2015-12-17 Google Inc. Lecture de média de diffusion en continu améliorée
US20160088322A1 (en) * 2014-09-22 2016-03-24 Arris Enterprises, Inc. Video Quality of Experience Based on Video Quality Estimation

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Technical Report, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Packet-switched Streaming Service (PSS); Improved Support for Dynamic Adaptive Streaming over HTTP in 3GPP (Release 13", 3GPP TR 26.938 V13.0.0 (2015-12, December 2015 (2015-12-01), Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Specs/2015-12/Rel-13/26-series> [retrieved on 20160926] *
SWAMINATHAN, V ET AL.: "Designing a Universal Format for Encrypted Media", THE 15TH IEEE INTERNATIONAL WORKSHOP ON MULTIMEDIA SIGNAL PROCESSING (MMSP, September 2013 (2013-09-01), XP032524263, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/document/6659265/?reload=true&arnumber=6659265>> [retrieved on 20160926] *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019227736A1 (fr) * 2018-05-29 2019-12-05 北京字节跳动网络技术有限公司 Procédé et appareil de lecture de réseau destinés à un fichier multimédia et support d'informations
CN110545491A (zh) * 2018-05-29 2019-12-06 北京字节跳动网络技术有限公司 一种媒体文件的网络播放方法、装置及存储介质
CN110545483A (zh) * 2018-05-29 2019-12-06 北京字节跳动网络技术有限公司 网页中切换分辨率播放媒体文件的方法、装置及存储介质
US10924801B2 (en) 2018-05-29 2021-02-16 Beijing Bytedance Network Technology Co., Ltd. Method and device for playing media file while switching resolution in webpage and storage medium
US11012759B2 (en) 2018-05-29 2021-05-18 Beijing Bytedance Network Technology Co., Ltd. Webcasting method, device and storage medium of media file
CN110545483B (zh) * 2018-05-29 2021-08-10 北京字节跳动网络技术有限公司 网页中切换分辨率播放媒体文件的方法、装置及存储介质
CN110545491B (zh) * 2018-05-29 2021-08-10 北京字节跳动网络技术有限公司 一种媒体文件的网络播放方法、装置及存储介质

Similar Documents

Publication Publication Date Title
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
JP6014870B2 (ja) ストリーミング・メディア・コンテンツのリアルタイム・トランスマックス変換の方法およびシステム
CN108432261B (zh) 为媒体传输确定媒体传递事件位置的方法和装置
US11252454B2 (en) System, devices and methods for providing stream privacy in an ABR OTT media network
US9462302B2 (en) Efficient delineation and distribution of media segments
US9270721B2 (en) Switching between adaptation sets during media streaming
US9319448B2 (en) Trick modes for network streaming of coded multimedia data
US8818021B2 (en) Watermarking of digital video
US9596522B2 (en) Fragmented file structure for live media stream delivery
US20170127147A1 (en) Multicast streaming
US20110299586A1 (en) Quality adjustment using a fragmented media stream
WO2012030734A1 (fr) Authentification d&#39;un utilisateur et d&#39;un dispositif pour des services multimédia
US20150312303A1 (en) Determining whether to use sidx information when streaming media data
WO2012030739A2 (fr) Gestion des droits numériques sur de multiples dispositifs
US20240155019A1 (en) Synchronizing independent media and data streams using media stream synchronization points
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
WO2017207861A1 (fr) Agencement destiné à l&#39;organisation de média en continu
KR101855972B1 (ko) 적응형 스트리밍을 위한 포렌식 마킹의 시그널링 및 핸들링
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16903894

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16903894

Country of ref document: EP

Kind code of ref document: A1