IL287191A - Method of streaming data communication and system thereof - Google Patents

Description

METHOD OF STREAMING DATA COMMUNICATION AND SYSTEM THEREOF TECHNICAL FIELD The presently disclosed subject matter relates to data communication and, more particularly, to streaming data communication.

BACKGROUND Modern communication techniques allow transferring large volumes of data between multiple end points and enable substantially immediate access to the transferred data with no need to wait for data to be downloaded. Such streaming data techniques are usable for media streaming, real-time analytics, real-time operating between remote sites, interactive real-time applications, etc. It is noted that the term "streaming data" refers to any content – live or recorded – delivered to any computing device(s) via a communication network (e.g. Internet) and received, in substantially real time, for further use. Streaming data can include streaming media (e.g. streaming audio, streaming video, streaming text, streaming data, streaming TV or other multi-media streams and combinations thereof). Streaming media techniques are usable to present various content such as, for example, movies, television shows, recorded sports events, interactive broadcasting, news programs, live events, etc. Further to streaming media, data streaming can refer to streams of sensors data, data from IoT devices, various logs, records, commands, messages, etc.

However, despite the massive advancements in the streaming technology over the past two decades, there are specific obstacles that the industry continues to face. In particular, bandwidth limitations and latency issues can prevent real time availability of the streamed media.

Latency problems of the streaming data have been recognized in the conventional art and various techniques have been developed to provide the solutions, for example: US Patent Application No. 2008/0104267 discloses a client-side device configured to request streaming media from a server over a network connection. In one embodiment, the client device sends streaming media requests to the server and, in response, a streaming media connection is established between the client-side device and the server in accordance with an appropriate networking protocol. Once this streaming media connection is established, the client-side device may make additional requests for other media streams. Delivery of such additional media streams may then proceed using the existing streaming media connection.

US Patent Application No. 2018/0191803 discloses a method of reducing the latency in streaming live media by a client from a server. The client uses manifest information to determine the "live edge" of the live media stream, where the live edge is represented by the segment from the media stream corresponding to the current time. The client then uses this to identify the next segment, which is the segment in time that will next become available. The client then starts making repeated polling requests for that next segment until the segment becomes available. As a result, the newest possible segment is obtained by the client as soon as it becomes available, and latency is reduced. Further, when adopted by all clients, the latency variation between clients is also reduced.

US Patent Application No. US2018/0295039 discloses techniques for low- latency data streaming. A computing device comprises a processor that includes a producer and a consumer; the producer generates a data item, and in a local buffer producer mode adds the data item to a local buffer, and in a remote buffer producer mode adds the data item to a remote buffer. When the local buffer is full, the producer switches to the remote buffer producer mode, and when the remote buffer is below a predetermined low threshold, the producer switches to the local buffer producer mode. The consumer reads the data item from the local buffer while operating in a local buffer consumer mode and reads the data item from the remote buffer while operating in a remote buffer consumer mode. When the local buffer is above a predetermined high threshold, the consumer may switch to a catch-up operating mode.

US Patent Application No. 2019/0342585 discloses a method of operating a media streaming network including a broadcast component for producing a live streaming broadcast, a viewer for requesting data segments by segment identifiers, and a viewer component for receiving requests for data segments by said identifiers from said viewer and responding to said viewer with requested data. The method comprises: causing said viewer to possess one of said segment identifiers relating to a data segment that does not then exist within said viewer component, causing said viewer to utilize said one segment identifier to request data from said viewer component at a time that said data has not yet come into existence within said viewer component, upon receiving said request from said viewer at a time that said data has not yet come into existence within said viewer component, causing said viewer component to wait for data related to said one of said segment identifiers to come into existence, and causing said viewer component to transfer data related to said one identifier to said viewer when it becomes available.

US Patent application No. 2020/0322673 discloses latency reduction in streaming media by modifying a playlist requested from a content delivery network so to have modified segmentation. After receiving the playlist from the content delivery network, the location of one or more I-frames in each segment in the playlist may be determined and these locations may be used to generate the modified playlist. The modified playlist may then be sent to a client device. Media segments may be modified in accordance with the modified segmentation of the modified playlist to generate modified media segments that can be sent to the client device.

US Patent application No. 2021/0014550 discloses a data processing system to perform a method comprising: requesting, by a first request, a first playlist for a media content, the first request not containing at least one attribute for a near live playlist for the media content; receiving the first playlist in a transfer protocol compliant manner, the first playlist comprising a plurality of uniform resource identifiers (URIs), the plurality of URIs indicating an order of playback of multiple media segments that can be received, in the transfer protocol compliant manner, to recreate the media content, the first playlist comprising a last URI in the order that identifies a last available media segment in the first playlist; receiving first age data associated with the first playlist, the first age data indicating an age of the first playlist on a caching server; determining, based on the first age data and based on the last URI, a first number of at least partial media segments after the last available media segment in the first playlist, the first number specifying a number of at least partial media segments to skip over, after the last available media segment, to tune-in to the media content.

The references cited above teach background information that may be applicable to the presently disclosed subject matter. Therefore, the full contents of these publications are incorporated by reference herein where appropriate for appropriate teachings of additional or alternative details, features and/or technical background.

GENERAL DESCRIPTION In accordance with certain aspects of the presently disclosed subject matter, there is provided a method of operating a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server. The method comprises, by the server: upon establishing a connection with the contributing device, generating a Manifest Object informative of the contributing device and the data stream and accessible by the consuming device when initiating the connection with the server; generating and maintaining a plurality of Stream Objects associated with the data stream, wherein at least one Stream Object comprises a version of data stream with data chunks derived and having characteristics different from data chunks received from the contributing device, and wherein the plurality of Stream Objects is generated in accordance with an entry configuration specifying what versions of the data stream shall be generated and stored at the server; and responsive to read requests received from the consuming device, enabling the consuming device to continuously read the most updated data chunks of a requested version of the data stream.

The method can further comprise: upon receiving from the consuming device a read request specifying the data stream and one or more characteristics (e.g. related to resolution of the data stream, encoding of the data stream, latency of the data stream, etc.) of the required version of the data stream, selecting by the server a Stream Object corresponding to the required characteristics and enabling reading therefrom. When the required characteristics are not predefined by the entry configuration, generating, maintaining and adding to the plurality of Stream Objects a new Stream Object matching the required characteristics.

In accordance with further aspects of the presently disclosed subject matter and, optionally, in combination with other aspects of the presently disclosed subject matter, the method can further comprise: registering the contributing device for control commands associated with the data stream, upon receiving from the consuming device a control command related to the data stream, defining, in accordance with the server’s configuration, if the received control command is configured as a server-executable or as a contributor-executable; and executing the received control command when it is server-executable or forwarding the received control command for executing by the contributing device when the command is contributor-executable.

The server can define a received control command related to updating a previously required characteristic as a server-executable command, the method further comprising selecting by the server, from the plurality of Stream Objects, a Stream Object corresponding to the required updated characteristic and enabling reading therefrom.

In accordance with further aspects of the presently disclosed subject matter and, optionally, in combination with other aspects of the presently disclosed subject matter, the data chunks can be media chunks, wherein the version of data stream in the at least one Stream Object can be derived from the received data stream by downscaling a resolution of the received media chunks, upscaling a resolution of the received media chunks, changing one or more encoding-related characteristics of the received media chunks, etc.

In accordance with further aspects of the presently disclosed subject matter and, optionally, in combination with other aspects of the presently disclosed subject matter, enabling the consuming device to continuously read the most updated data chunks of the data stream can comprise: continuously receiving from the consuming device a plurality of concurrently pending read requests, each request characterized, at least, by request ID and by a sequential number of the last chunk received from the server at the time of generating the request (LC); for each given received read request: comparing the LC with a sequence number of the last chunk received by the server from the contributing device at the time of receiving the given request (LS); when LC is less than LS, sending, at least, the last chunk received by the server to the consuming device; when LC is equal to LS, keeping the given read request in a cache of the server; and for each given new received chunk of the data stream, checking the cache for a read request with LC less than a sequence number of the given new received chunk and, when found, sending the given new received chunk to the consuming device. Optionally, a number of concurrently pending read requests can be defined by a number of credits assigned by the server to the consuming device.

In accordance with other aspects of the presently disclosed subject matter, there is provided a method of operating a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server, the method comprising, by the server: upon establishing a connection with the contributing device, generating a Manifest Object informative of the contributing device and the data stream and accessible by the consuming device when initiating the connection with the server; continuously receiving from the contributing device chunks of the data stream and writing the chunks and/or derivatives thereof in association with the Manifest Object; continuously receiving from the consuming device a plurality of concurrently pending read requests, each request characterized, at least, by request ID and by a sequential number of the last chunk received from the server at the time of generating the request (LC). For each given received read request: comparing the LC with a sequence number of the last chunk received by the server from the contributing device at the time of receiving the given request (LS); when LC is less than LS, sending, at least, the last chunk received by the server to the consuming device; when LC is equal to LS, keeping the given read request in a cache of the server. For each given new received chunk of the data stream, checking the cache for a read request with LC less than a sequence number of the given new received chunk and, when found, sending the given new received chunk to the consuming device.

In accordance with further aspects of the presently disclosed subject matter and, optionally, in combination with other aspects of the presently disclosed subject matter, the method can further comprise: generating and maintaining a plurality of Stream Objects associated with the data stream, wherein at least one Stream Object comprises a version of data stream with data chunks derived and having characteristics different from data chunks received from the contributing device, and wherein the plurality of Stream Objects is generated in accordance with an entry configuration specifying what versions of the data stream shall be generated and stored at the server.

Upon receiving from the consuming device a read request specifying the data stream and one or more characteristics of the required version of the data stream, the server can select a Stream Object corresponding to the required characteristics and enabling reading therefrom.

In accordance with further aspects of the presently disclosed subject matter and, optionally, in combination with other aspects of the presently disclosed subject matter, the method can further comprise: registering the contributing device for control commands associated with the data stream, upon receiving from the consuming device a control command related to the data stream, defining, in accordance with the server’s configuration, if the received control command is configured as a server-executable or as a contributor-executable; executing the received control command when it is server­executable or forwarding the received control command for executing by the contributing device when the command is contributor-executable.

The server can define a received control command related to updating a previously required characteristic as a server-executable command, the method further comprising selecting by the server, from the plurality of Stream Objects, a Stream Object corresponding to the required updated characteristic and enabling reading therefrom.

The data chunks can be media chunks and wherein the version of data stream in the at least one Stream Object is derived from the received data stream by one of: downscaling a resolution of the received media chunks, upscaling a resolution of the received media chunks, changing one or more encoding-related characteristics of the received media chunks.

In accordance other aspects of the presently disclosed subject matter and, optionally, in combination with other aspects of the presently disclosed subject matter, there is provided a non-transitory computer readable medium usable by a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server. The computer readable medium comprises instructions that, when executed by a processor and memory circuitry (PMC) comprised in the server, cause the PMC to perform operations of the above methods of operating the server.

Among advantages of certain embodiments of the presently disclosed subject matter is the reduced latency of data streaming and the enhanced control functionalities.

BRIEF DESCRIPTION OF THE DRAWINGS In order to understand the invention and to see how it can be carried out in practice, embodiments will be described, by way of non-limiting examples, with reference to the accompanying drawings, in which: Fig. 1 illustrates a generalized block diagram of a data-streaming system in accordance with certain embodiments of the presently disclosed subject matter; Fig. 2 illustrates a generalized flow-chart of operating a contributing device in accordance with certain embodiments of the presently disclosed subject matter; Fig. 3 illustrates a generalized flow-chart of operating the server in conjunction with the contributing device in accordance with certain embodiments of the presently disclosed subject matter; Fig. 4 illustrates a generalized flow-chart of operating a consuming device in accordance with certain embodiments of the presently disclosed subject matter; Fig. 5 illustrates a generalized flow-chart of operating the server in conjunction with the consuming device in accordance with certain embodiments of the presently disclosed subject matter; Fig. 6 illustrates a generalized sequence of "read-ahead" process in accordance with certain embodiments of the presently disclosed subject matter; and Fig. 7 illustrates an exemplified data communication between the contributing device, the server and the consuming device during the "read-ahead" process in accordance with certain embodiments of the presently disclosed subject matter.

DETAILED DESCRIPTION In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the presently disclosed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the presently disclosed subject matter.

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing", "reading", "comparing", "generating", "writing", "creating", "updating" or the like, refer to the action(s) and/or process(es) of a computer that manipulate and/or transform data into other data, said data represented as physical, such as electronic, quantities and/or said data representing the physical objects. The term "computer" should be expansively construed to cover any kind of hardware-based electronic device with data processing capabilities including, by way of non-limiting example, the contributing devices, the consuming devices and the servers disclosed in the present application.

The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general-purpose computer specially configured for the desired purpose by a computer program stored in a non-transitory computer-readable storage medium.

Embodiments of the presently disclosed subject matter are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the presently disclosed subject matter as described herein.

Bearing this in mind, attention is drawn to Fig. 1illustrating a generalized diagram of a data-streaming system in accordance with certain embodiments of the presently disclosed subject matter. Data-streaming system 100includes a plurality of contributing devices (denoted as 101-1 and 101-2 ) and a plurality of consuming devices (denoted as 103-1and 103-2 ) operatively connected to a server 102via a packet- switched communication network (not shown).

As will be further detailed with reference to Figs. 2 - 7 , data- streaming system 100is configured to enable the consuming devices to select, control and receive the data streams provided by the contributing devices. Likewise, data- streaming system 100is configured to enable the consuming devices to select, control and receive the data streams derived from the data streams provided by the contributing devices. A contributing device can include a video and/or audio capturing device or can operate in conjunction with one or more capturing devices or other devices providing one or more data streams. A contributing device (e.g. device 101-1 ) is configured to stream to server 102one or more data streams (denoted as Stream 1and Stream 2 ). Data streams can be related to the same content. By way of non-limiting example, the related streams can be characterized by different types of streaming data (e.g. audio, video streams and/or sensor data streams), different types of implemented codecs, different quality of streaming media (e.g. different resolution), different perspectives of capturing the content, different types of log data, etc. A consuming device (e.g. device 103-1 ) is configured to request and, accordingly, receive the streamed data from server 102(in the illustrated example, Stream 1 ). The consuming device can render the received data (e.g. with a help of a media player) and/or use them and/or transfer them for other applications.

As will be further detailed with reference to Figs. 2 – 7 , the contributing device is configured to send the streamed data to server 102 . The server writes the streamed content as data chunks (referred to also as "chunks"), wherein a payload of each chunk is configured to be written and/or read as a single unit. The consuming device is configured to read from the server the most updated chunks of the data stream.

Further, the consuming device can be configured to use a separate transmission channel (denoted as Control ) to send messages to the server and/or to the contributing devices via server 102 . By way of non-limiting example, the messages can be related to operation of the consuming devices (e.g. zoom requests, resolution requests, etc.) and/or to the streaming content (e.g. enabling viewers to participate in group activities centred on a live broadcast, to be engaged in financial transactions during a live broadcast, etc.).

The server is configured to run a background streaming-data service (SDS) enabling the server operation that is further detailed with reference to Figs. 2– 7 .

In accordance with certain embodiments, the communication between the contributing devices and server 102and between server 102and the consuming devices is provided with the help of a protocol enabling communication between the contributing and consuming devices through the server (e.g. an SMB (Server Message Block) protocol, NFS (Network File System) protocol, HLS (HTTP Live Streaming) protocol, etc.

For purpose of illustration only, the following description is provided for embodiments that use SMB protocol. Those skilled in the art will readily appreciate that the teachings of the presently disclosed subject matter are, likewise, applicable to other suitable Client/Server communication protocols.

The consuming devices and the contributing devices can be configured as SMB clients of SMB-supporting server 102.In certain embodiments a contributing device and a consuming device can be connected to different servers communicating therebetween with the help of a file sharing protocol.

SMB protocol can operate on top of any suitable communication protocol enabling streaming communication over the packet-switched network (e.g. SMB over TCP, SMB over QUIC, SMB over RDMA, SMB over Bluetooth, etc.). In the illustrated example, contributing device 101-1shares with the consuming devices a Manifest Object 104 , an Entry Object 105and Control Object 107 . As further detailed with reference to Figs. 2 – 7 , Entry Object 105is associated with Manifest Object 104 , Entry Object 105is further associated with one or more Stream Objects 106and Control Object 107 . The server can handle objects 104– 107as files in the server’s file system, as database objects or other suitable data structures, depending on the server’s configuration.

It is noted that the teachings of the presently disclosed subject matter are not bound by the data-streaming system described with reference to Fig. 1 . Equivalent and/or modified functionality can be consolidated or divided in another manner and can be implemented in any appropriate combination of software with firmware and/or hardware and executed on a suitable device.

Referring to Fig. 2 , there is illustrated a generalized flow-chart of operating a contributing device in accordance with certain embodiments of the presently disclosed subject matter.

For purpose of illustration only, the following description is provided for a media stream. Those skilled in the art will readily appreciate that the teachings of the presently disclosed subject matter are, likewise, applicable to another data stream or for a plurality of data streams related to the same content.

When starting the process, contributing device 101-1connects ( 201 ) to the Streaming Data Service (SDS) running as a background process at server 102.Upon establishing a connection (e.g. using SMB over TCP protocols), contributing device 101-1establishes a contributing pipe with the server and uses the pipe to send ( 202 ) to the server data usable by the server for creating a Manifest Object. By way of non­limiting example, such data can be informative of the contributing device and the stream (e.g. camera details including name, location, frame rate (FPS), latency, etc.) codec type and current parameters; implemented transmission protocols, audio stream parameters, etc.

Contributing device 101-1further continuously sends ( 203 ) to server 102the chunks of streaming media, the chunks bearing association with a corresponding stream.

It is noted that, unless specifically stated otherwise, throughout the specification the terms "continuously sending" "continuously writing", "continuously reading" or the like refer to actions provided in accordance with a certain arrangement related to availability of new relevant data. For example, such actions can be provided in real time or near real-time mode, with predefined periodicity, responsive to predefined events, etc.

Independently of operation 203 , the contributing device registers ( 204 ) at the server for receiving control commands and executes ( 205 ) suitable control commands when received.

When the media stream needs to be terminated, the contributing device sends ( 206 ) a close command or an indication of the end of streaming.

By way of non-limiting example, the above generalized flow-chart can be illustrated by the following flow of SMB operations provided by the contributing device: (2.1) Connecting to the SMB server using the SMB Negotiate;(2.2) Connecting to the Inter-process Communication Share (IPC$) (a tree connect);(2.3) Opening a logical object (referred to hereinafter also as "Entry Object or "Entry file") associated with manifest file and with all further generated (by contributor and by server) Stream Objects, and receiving from the server a "contributing pipe" handle usable for operations (2.4) – (2.8).(2.4) Sending manifest - related data and "Create Manifest" command associated with the "contributing pipe" handle;(2.5) Sending "Create Video/Audio Stream" command associated with the "contributing pipe" handle, and receiving from the server a stream ID;(2.6) Sending stream media chunks associated with the received Stream ID (and implicitly or explicitly also with the "contributing pipe" handle);(2.7) Sending "register for control notification" request specifying control commands supportable by the contributor; the request is associated with the "contributing pipe" handle;(2.8) Closing the Stream with the respective stream ID;(2.9) Closing the Entry Object;(2.10) Closing the connection to SMB server Referring to Fig. 3 , there is illustrated a generalized flow-chart of operating the server in conjunction with the contributing device in accordance with certain embodiments of the presently disclosed subject matter.

In response to contributor’s request, server 102establishes ( 301 ) SDS connection (e.g. approves SMB and IPC$ connection requests received from the contributor device) and creates a handle to SDS. Server 102further creates ( 302 ) Manifest Object, Entry Object and Control Object associated therebetween and updates the Manifest Object with data received from the contributor.

Further, server 102generates ( 303 ) a plurality of Stream Objects each associated with the Entry Object. By way of non-limiting example, the server can generate the Entry Object in response to the contributor’s request for SDS service and provide the Entry Object with a handle usable for association with the Stream Objects, Control Objects and the Manifest File.

For each given received original media chunk, server generates ( 304 ) one or more derived media chunks. The derived media chunks can have video/audio characteristics differing from the original chunk. Server 102stores ( 305 ) the given original media chunks and the derived media chunks in respective Stream Objects, thereby each Stream Object associated with the Entry Object maintains a version of the same stream. For example, one Stream Object can maintain a version with downscaled resolution, another – with upscaled resolution, yet another – with changed encoding related parameters, etc. Each media chunk is stored in a respective Stream Object in association with the same Stream ID (e.g. received by the contributor from the server in response to "Create Video/Audio Stream" command detailed with reference to Fig. 2 ).

The server generates the Stream Objects and the derived media chunks in accordance with an entry configuration specifying what versions of the stream shall be generated and stored at the server. The entry configuration further specifies the structure of each Stream Object (e.g. video/audio characteristics of the chunks to be stored therein). The entry configuration can be pre-defined at the server 102as the same for all contributing devices or can vary by contributing devices and/or groups thereof.

In certain embodiments, all Stream Objects associated with a common Entry Object can maintain the same pre-defined number of media chunks that correspond to the same point-in-time in the stream.

In other embodiments, at least part of the Stream Objects associated with a common Entry Object can maintain different number of chunks, for example one of the Stream Objects can handle all received (or derived from the received) chunks.

By way of non-limiting example, a given Stream Object can be configured as a ring buffer, while the size of the buffer is defined by the pre-defined number of chunks and the size of the chunks to be stored therein in accordance with the entry configuration. The server can further maintain, for each Stream Object, an index informative of location (e.g. offset) of the latest chunk written in the buffer. When the chunks in a Stream Object have variable size, the index can be further informative of the sizes of the written chunks. Optionally, the index can further comprise data informative of the sequence number of the last written chunk in a sequence of chunks.

Optionally, each written media chunk can be associated with a message time tag (MTT). MTT can be usable for synchronization of reading from several Entry Objects related to the same content (e.g. Entry Objects for separate audio and video streams, Entry Objects from several stream sources as, for example for 360° video rendering, etc.), assessing latency of the contributing device, etc.

It is noted that, depending on the configuration of the server, the media chunks can correspond to media packets, media frames or groups of media frames.

Typically, prior to transferring in a network, a captured media stream is compressed by an encoder using any suitable compression protocol (e.g., H.264, H.265, H.266 for video stream, MP3, Opus for audio stream, etc.). The encoder can be a part of the contributing device or operate in conjunction therewith. A compression protocol can generate different types of frames. By way of non-limiting example, H.2generates 3 types of frames: I-frames informative of a complete image, P-frame (delta­frames) informative only of the changes in the image from the previous frame, and B- frame informative of differences between the current frame and both the preceding and following frames to specify its content. When a size of a frame exceeds a predefined maximal size (e.g. corresponding to a maximal size of a transmittable packet), the encoder further segments the frame into segments fitting this maximal size and packetize the segments into media packets.

The server can be configured to separately write each media packet as a media chunk. Each such chunk can be written with a header indicative of the chunk size, respective frame and, for segments, the sequential location in the frame. Optionally, the chunks can be written as payload only, and the values from the respective headers can be stored in the index.

Alternatively, for the frames with multiple segments the server can be configured to write the segments of the given frame as one atomic operation, i.e. an operation that either succeeds or fails in its entirety and not in a partial way. In this case, the media chunks correspond to the frames, regardless of whether the frames are segmented or not.

Likewise, the server can be configured to write multiple frames (i.e. sequential P-frames and/or B-frames) as one atomic operation. In this case, the media chunks correspond to the respective groups of frames.

Referring back to Fig. 3 , in response to the contributor’s request, the server registers ( 306 ) the contributor for control commands, the registration being associated with the stream ID and the Entry Object. As will be further detailed with reference to Fig. 5 , the server is configured to receive control commands from the consuming devices and enable the execution of the commands, while the server’s configuration specifies which of the received control commands the server executes by itself, and which control commands are defined as contributor-executable. Accordingly, upon receiving contributor-executable control command(s), the server forwards ( 307 ) such control command(s) to the contributor.

Finally, in response to the contributor’s request, server 102closes ( 308 ) the SDS connection and sends notification to all consuming devices that the feed is not available.

Claims (48)

1. A method of operating a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server, the method comprising, by the server: upon establishing a connection with the contributing device, generating a Manifest Object informative of the contributing device and the data stream and accessible by the consuming device when initiating the connection with the server; generating and maintaining a plurality of Stream Objects associated with the data stream, wherein at least one Stream Object comprises a version of data stream with data chunks derived and having characteristics different from data chunks received from the contributing device, and wherein the plurality of Stream Objects is generated in accordance with an entry configuration specifying what versions of the data stream shall be generated and stored at the server; and responsive to read requests received from the consuming device, enabling the consuming device to continuously read the most updated data chunks of a requested version of the data stream.

2. The method of Claim 1 further comprising: upon receiving from the consuming device a read request specifying the data stream and one or more characteristics of the required version of the data stream, selecting by the server a Stream Object corresponding to the required characteristics and enabling reading therefrom.

3. The method of Claim 2 further comprising: when the required characteristics are not predefined by the entry configuration, generating, maintaining and adding to the plurality of Stream Objects a new Stream Object matching the required characteristics.

4. The method of Claim 3, wherein the required characteristics are related to at least one of: resolution of the data stream, encoding of the data stream, latency of the data stream.

5. The method of any one of Claims 1 – 4, further comprising: registering the contributing device for control commands associated with the data stream, upon receiving from the consuming device a control command related to the data stream, defining, in accordance with the server’s configuration, if the received control command is configured as a server-executable or as a contributor-executable; executing the received control command when it is server-executable or forwarding the received control command for executing by the contributing device when the command is contributor-executable.

6. The method of Claim 5 wherein the server defines a received control command related to updating a previously required characteristic as a server-executable command, the method further comprising selecting by the server, from the plurality of Stream Objects, a Stream Object corresponding to the required updated characteristic and enabling reading therefrom.

7. The method of any one of Claims 1 - 6, wherein the data chunks are media chunks and wherein the version of data stream in the at least one Stream Object is derived from the received data stream by one of: downscaling a resolution of the received media chunks, upscaling a resolution of the received media chunks, changing one or more encoding-related characteristics of the received media chunks.

8. The method of any one of Claims 1 – 7, wherein the entry configuration is the same for all contributing devices or varies by contributing devices and/or groups thereof.

9. The method of any one of Claims 1 – 8, wherein all Stream Objects in the plurality of Stream Objects maintain the same pre-defined number of data chunks that correspond to the same point-in-time in the data stream.

10. The method of any one of Claims 1 – 9, wherein enabling the consuming device to continuously read the most updated data chunks of the data stream comprises: continuously receiving from the consuming device a plurality of concurrently pending read requests, each request characterized, at least, by request ID and by a sequential number of the last chunk received from the server at the time of generating the request (LC); for each given received read request: comparing the LC with a sequence number of the last chunk received by the server from the contributing device at the time of receiving the given request (LS); when LC is less than LS, sending, at least, the last chunk received by the server to the consuming device; when LC is equal to LS, keeping the given read request in a cache of the server; and for each given new received chunk of the data stream, checking the cache for a read request with LC less than a sequence number of the given new received chunk and, when found, sending the given new received chunk to the consuming device.

11. The method of Claim 10 further comprising maintaining the cache so to keep, merely, read requests that are valid at respective points-in-time.

12. The method of Claims 10 or 11, wherein a number of concurrently pending read requests is defined by a number of credits assigned by the server to the consuming device.

13. A method of operating a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server, the method comprising, by the server: upon establishing a connection with the contributing device, generating a Manifest Object informative of the contributing device and the data stream and accessible by the consuming device when initiating the connection with the server; continuously receiving from the contributing device chunks of the data stream and writing the chunks and/or derivatives thereof in association with the Manifest Object; continuously receiving from the consuming device a plurality of concurrently pending read requests, each request characterized, at least, by request ID and by a sequential number of the last chunk received from the server at the time of generating the request (LC); for each given received read request: comparing the LC with a sequence number of the last chunk received by the server from the contributing device at the time of receiving the given request (LS); when LC is less than LS, sending, at least, the last chunk received by the server to the consuming device; when LC is equal to LS, keeping the given read request in a cache of the server; and for each given new received chunk of the data stream, checking the cache for a read request with LC less than a sequence number of the given new received chunk and, when found, sending the given new received chunk to the consuming device.

14. The method of Claim 13 further comprising maintaining the cache so to keep, merely, read requests that are valid at respective points-in-time.

15. The method of Claims 13 or 14, wherein a number of concurrently pending read requests is defined by a number of credits assigned by the server to the consuming device.

16. The method of any one of Claims 13 – 15, further comprising: generating and maintaining a plurality of Stream Objects associated with the data stream, wherein at least one Stream Object comprises a version of data stream with data chunks derived and having characteristics different from data chunks received from the contributing device, and wherein the plurality of Stream Objects is generated in accordance with an entry configuration specifying what versions of the data stream shall be generated and stored at the server.

17. The method of Claim 16 further comprising: upon receiving from the consuming device a read request specifying the data stream and one or more characteristics of the required version of the data stream, selecting by the server a Stream Object corresponding to the required characteristics and enabling reading therefrom.

18. The method of Claim 17 further comprising: when the required characteristics are not predefined by the entry configuration, generating, maintaining and adding to the plurality of Stream Objects a new Stream Object matching the required characteristics.

19. The method of Claim 18, wherein the required characteristics are related to at least one of: resolution of the data stream, encoding of the data stream, latency of the data stream.

20. The method of any one of Claims 16 – 19, further comprising: registering the contributing device for control commands associated with the data stream, upon receiving from the consuming device a control command related to the data stream, defining, in accordance with the server’s configuration, if the received control command is configured as a server-executable or as a contributor-executable; executing the received control command when it is server-executable or forwarding the received control command for executing by the contributing device when the command is contributor-executable.

21. The method of Claim 20, wherein the server defines a received control command related to updating a previously required characteristic as a server­executable command, the method further comprising selecting by the server, from the plurality of Stream Objects, a Stream Object corresponding to the required updated characteristic and enabling reading therefrom.

22. The method of any one of Claims 16 - 21, wherein the data chunks are media chunks and wherein the version of data stream in the at least one Stream Object is derived from the received data stream by one of: downscaling a resolution of the received media chunks, upscaling a resolution of the received media chunks, changing one or more encoding-related characteristics of the received media chunks.

23. The method of any one of Claims 16 – 22, wherein the entry configuration is the same for all contributing devices or varies by contributing devices and/or groups thereof.

24. The method of any one of Claims 16 – 23, wherein all Stream Objects in the plurality of Stream Objects maintain the same pre-defined number of data chunks that correspond to the same point-in-time in the data stream.

25. A non-transitory computer readable medium usable by a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server, the computer readable medium comprising instructions that, when executed by a processor and memory circuitry (PMC) comprised in the server, cause the PMC to perform operations comprising: upon establishing a connection with the contributing device, generating a Manifest Object informative of the contributing device and the data stream and accessible by the consuming device when initiating the connection with the server; generating and maintaining a plurality of Stream Objects associated with the data stream, wherein at least one Stream Object comprises a version of data stream with data chunks derived and having characteristics different from data chunks received from the contributing device, and wherein the plurality of Stream Objects is generated in accordance with an entry configuration specifying what versions of the data stream shall be generated and stored at the server; and responsive to read requests received from the consuming device, enabling the consuming device to continuously read the most updated data chunks of a requested version of the data stream.

26. The non-transitory computer readable medium of Claim 25, wherein the operations further comprising: upon receiving from the consuming device a read request specifying the data stream and one or more characteristics of the required version of the data stream, selecting by the server a Stream Object corresponding to the required characteristics and enabling reading therefrom.

27. The non-transitory computer readable medium of Claim 26, wherein the operations further: when the required characteristics are not predefined by the entry configuration, generating, maintaining and adding to the plurality of Stream Objects a new Stream Object matching the required characteristics.

28. The non-transitory computer readable medium of Claim 27, wherein the required characteristics are related to at least one of: resolution of the data stream, encoding of the data stream, latency of the data stream.

29. The non-transitory computer readable medium of any one of Claims 25 – 28, wherein the operations further comprising: registering the contributing device for control commands associated with the data stream, upon receiving from the consuming device a control command related to the data stream, defining, in accordance with the server’s configuration, if the received control command is configured as a server-executable or as a contributor-executable; executing the received control command when it is server-executable or forwarding the received control command for executing by the contributing device when the command is contributor-executable.

30. The non-transitory computer readable medium of Claim 29, wherein the server defines a received control command related to updating a previously required characteristic as a server-executable command, the method further comprising selecting by the server, from the plurality of Stream Objects, a Stream Object corresponding to the required updated characteristic and enabling reading therefrom.

31. The non-transitory computer readable medium of any one of Claims 25 - 30, wherein the data chunks are media chunks and wherein the version of data stream in the at least one Stream Object is derived from the received data stream by one of: downscaling a resolution of the received media chunks, upscaling a resolution of the received media chunks, changing one or more encoding-related characteristics of the received media chunks.

32. The non-transitory computer readable medium of any one of Claims 25 – 31, wherein the entry configuration is the same for all contributing devices or varies by contributing devices and/or groups thereof.

33. The non-transitory computer readable medium of any one of Claims 25 – 32, wherein all Stream Objects in the plurality of Stream Objects maintain the same pre-defined number of data chunks that correspond to the same point-in-time in the data stream.

34. The non-transitory computer readable medium of any one of Claims 25 – 33, wherein enabling the consuming device to continuously read the most updated data chunks of the data stream comprises: continuously receiving from the consuming device a plurality of concurrently pending read requests, each request characterized, at least, by request ID and by a sequential number of the last chunk received from the server at the time of generating the request (LC); for each given received read request: comparing the LC with a sequence number of the last chunk received by the server from the contributing device at the time of receiving the given request (LS); when LC is less than LS, sending, at least, the last chunk received by the server to the consuming device; when LC is equal to LS, keeping the given read request in a cache of the server; and for each given new received chunk of the data stream, checking the cache for a read request with LC less than a sequence number of the given new received chunk and, when found, sending the given new received chunk to the consuming device.

35. The non-transitory computer readable medium of Claim 34 further comprising maintaining the cache so to keep, merely, read requests that are valid at respective points-in-time.

36. The non-transitory computer readable medium of Claims 34 or 35, wherein a number of concurrently pending read requests is defined by a number of credits assigned by the server to the consuming device.

37. A non-transitory computer readable medium usable by a server to enable streaming a data stream between a contributing device and a consuming device both operatively connected to the server, the computer readable medium comprising instructions that, when executed by a processor and memory circuitry (PMC) comprised in the server, cause the PMC to perform operations comprising: upon establishing a connection with the contributing device, generating a Manifest Object informative of the contributing device and the data stream and accessible by the consuming device when initiating the connection with the server; continuously receiving from the contributing device chunks of the data stream and writing the chunks and/or derivatives thereof in association with the Manifest Object; continuously receiving from the consuming device a plurality of concurrently pending read requests, each request characterized, at least, by request ID and by a sequential number of the last chunk received from the server at the time of generating the request (LC); for each given received read request: comparing the LC with a sequence number of the last chunk received by the server from the contributing device at the time of receiving the given request (LS); when LC is less than LS, sending, at least, the last chunk received by the server to the consuming device; when LC is equal to LS, keeping the given read request in a cache of the server; and for each given new received chunk of the data stream, checking the cache for a read request with LC less than a sequence number of the given new received chunk and, when found, sending the given new received chunk to the consuming device.

38. The non-transitory computer readable medium of Claim 37, wherein the operations further comprising maintaining the cache so to keep, merely, read requests that are valid at respective points-in-time.

39. The non-transitory computer readable medium of Claims 37 or 38, wherein a number of concurrently pending read requests is defined by a number of credits assigned by the server to the consuming device.

40. The non-transitory computer readable medium of any one of Claims 37 – 39, wherein the operation further comprising: generating and maintaining a plurality of Stream Objects associated with the data stream, wherein at least one Stream Object comprises a version of data stream with data chunks derived and having characteristics different from data chunks received from the contributing device, and wherein the plurality of Stream Objects is generated in accordance with an entry configuration specifying what versions of the data stream shall be generated and stored at the server.

41. The non-transitory computer readable medium of Claim 40 further comprising: upon receiving from the consuming device a read request specifying the data stream and one or more characteristics of the required version of the data stream, selecting by the server a Stream Object corresponding to the required characteristics and enabling reading therefrom.

42. The non-transitory computer readable medium of Claim 41, wherein the operations further comprising: when the required characteristics are not predefined by the entry configuration, generating, maintaining and adding to the plurality of Stream Objects a new Stream Object matching the required characteristics.

43. The non-transitory computer readable medium of Claim 42, wherein the required characteristics are related to at least one of: resolution of the data stream, encoding of the data stream, latency of the data stream.

44. The non-transitory computer readable medium of any one of Claims 40 – 42, wherein the operations further comprising: registering the contributing device for control commands associated with the data stream, upon receiving from the consuming device a control command related to the data stream, defining, in accordance with the server’s configuration, if the received control command is configured as a server-executable or as a contributor-executable; executing the received control command when it is server-executable or forwarding the received control command for executing by the contributing device when the command is contributor-executable.

45. The non-transitory computer readable medium of Claim 44, wherein the server defines a received control command related to updating a previously required characteristic as a server-executable command, the method further comprising selecting by the server, from the plurality of Stream Objects, a Stream Object corresponding to the required updated characteristic and enabling reading therefrom.

46. The non-transitory computer readable medium of any one of Claims 40 - 45, wherein the data chunks are media chunks and wherein the version of data stream in the at least one Stream Object is derived from the received data stream by one of: downscaling a resolution of the received media chunks, upscaling a resolution of the received media chunks, changing one or more encoding-related characteristics of the received media chunks.

47. The non-transitory computer readable medium of any one of Claims 40 – 46, wherein the entry configuration is the same for all contributing devices or varies by contributing devices and/or groups thereof.

48. The non-transitory computer readable medium of any one of Claims 40 – 47, wherein all Stream Objects in the plurality of Stream Objects maintain the same pre-defined number of data chunks that correspond to the same point-in-time in the data stream.