Patent ID: 12244876

DETAILED DESCRIPTION OF CERTAIN ILLUSTRATIVE EMBODIMENTS

Architecture

The present development relates to a method for providing multimedia contents to a user terminal1through a network10. In the following description, a given multimedia content that the user wants to retrieve will be referred to as “target multimedia content”. The multimedia contents could of be any type such as an image, an audio content or a video.

The present development is particularly applicable in the context of VOD, wherein the multimedia contents are videos which are “streamed”, i.e. directly played by the user terminal1while being received, by contrast to “direct downloading” where video files are entirely received by a user terminal before being played. However, the present method is not limited to the sole cases of VOD or streaming.

As represented byFIG.1, the network10is typically a Wide Area Network such as Internet.

The network10connects at least the user terminal1, a master server2and a slave server3. As it will be explained, there may be a plurality of slave servers3in particular associated to different geographical areas (for example one slave server3per country, the slave server3being advantageously physically located in the country it serves).

The user terminal1could be any electronic device for receiving and advantageously playing the target multimedia content such as a computer, a smart TV, a smartphone, a set-top box, etc. The user terminal1comprises a processing unit11(e.g. a processor) and a storage unit12(e.g. a memory, for example flash memory or a hard drive) for being delivered the target multimedia content.

In a preferred embodiment, the user terminal1is a “mobile” terminal, such as a smartphone or a touch tablet, i.e. a terminal with a small screen and comparatively lower resources with respect to other terminals such as a television or a computer, and thus generally consuming a version of the multimedia content adapted to the specifications of the mobile terminal, i.e. a “lower quality” (or “size-optimized”) multimedia content. In the following description, the wording “lower quality” should be understood relatively with respect to “higher quality”, and may be expressed in many ways (for a video, the quality may be a function of a resolution, bitrate, number of frames per second etc.). As an example, we will take as a lower quality multimedia content a SD video (resolution up to 720p) and as a higher quality multimedia content a HD video (resolution at least equal to 1080p). Note that the notion of lower/higher quality can be also expressed for other types of multimedia contents such as audio content. A lower quality version of a content always presents a sensibly smaller size (“size-optimized”) that a higher quality version.

Note that these lower quality versions of the multimedia contents can be provided by the content providers themselves, when they provide new contents in higher quality to the master server2, or can be generated by the master server2itself from the higher quality version when received (i.e. the master server2converts the higher quality version into a lower quality version and stores the two versions for future use).

The user terminal1may implement a dedicated client application for accessing the multimedia contents, in particular configurated for communicating with the slave server3(see below) and directly requests multimedia content under a adapted quality considering the terminal type (for instance a lower quality version for a mobile terminal).

The master server2is any typical content server, in particular a server of a CDN (for “Content Delivery Network”). Note that there may be a plurality of master servers2constituting a cloud, in any known fashion.

The master server2stores a set of “available” multimedia contents, referred to as first set. In other words, any multimedia content available at the master server2may be requested by the user terminal1. The terms “content available at a server” means here that the content is stored in this server and can be requested from this server by a user terminal.

The target multimedia content is considered to belong to said first set, i.e. it is available at the master server2. Multimedia content of the video type may be stored for instance as “.ts” packages. Note that, a given content available at the master server2could be available under a plurality of versions, in particular according to different qualities (at least a lower quality version and a higher quality version, as explained). In other words, several copies of the same multimedia content (having various sizes) may be simultaneously stored at the master server2.

Note that the first set may be regularly updated, for instance by adding new contents or deleting old contents.

Advantageously, the master server2also stores a first indexation file describing the first set of multimedia contents available at the master server2. Such first indexation file is typically a list of the multimedia contents of the first set, for example a “.m3u8” list. In case of un update of the first set, the first indexation file is automatically updated accordingly.

In an exemplary embodiment, the master server2is implemented using a combination of three open source containers which are working together to create the master server in VMware in Cloud, using the simplest and low resources demanding solution. The orchestration of containers can be made by docker swarm which is native in docker. Indeed, as it will be explained the present master server2does not need a high availability (contrary to the prior art VOD servers). In addition, in order to create a special portal for uploading the multimedia contents and make their management into a database, a fourth container can be used for collaborating with a host by using bash scripts.

The slave server3can be any simple server also comprising a processing unit31(e.g. a processor) and a storage unit32(e.g. a memory, for example flash memory or a hard drive), on which a web application for providing multimedia contents to the user terminal1is installed, for example a linux server with apache.

Slave Server—Synchronization

The present method originally uses the slave server3as a low cost replicate of the master server2, thanks to an original synchronization process.

It is noted here that this synchronization process is totally different from the caching process used in traditional caching VOD architectures.

In particular, the traditional process of caching a content in a local server implies storing temporarily this content in an accessible temporary storage location of this local server after that this local server has received a first request from a user to obtain this content. This caching operation allows the local server to directly provide the same cached content to other users (or even to the same user) if there are more requests received for this content during the temporary storage of this content, i.e. during a certain duration of time.

On the contrary, the synchronization of contents between a master server and a slave server implies that, once a content is stored in the slave server (e.g. after that the same content had been added in the master server, possibly in a different version, in a set of contents to be synchronized between both servers), this content remains stored in the slave server as long as it is also stored in the master server, and the storage of this content in the slave server only ends when the same content is removed from the master server.

Thus, in the present method, when the user wants to access a multimedia content from its terminal1, this multimedia content is downloaded from the slave server3where it is made available through synchronization with the master server2, and not from the master server2as would be the case in a caching architecture whenever the requested content is not already cached in the local server.

This enables controlling, and potentially reducing, the data traffic on the networks interconnecting the servers storing the contents and the local (slave) servers serving the users, by contrast with a traditional cache architecture which potentially generates traffic continuously between the remote content server and the local caching servers in an uncontrolled way for the interconnecting networks operators. Using such a synchronization process also avoids download interruptions for the user, which may occur in the traditional VOD architecture when network connections between the remote content server and the local caching server (e.g. on internet) are unstable. This also enables customizing the application on a slave server per slave server (i.e. country per country) basis.

The present method for providing to the user terminal1the target multimedia content belonging to the first set of multimedia contents is performed by the processing unit31of the slave server3.

As represented byFIG.2, it comprises a main step (a) of synchronizing the slave server3with the master server2, so that each multimedia content of said first set of multimedia contents available at a master server2is also available at the slave server3. This step (a) can be made any time deemed necessary. This step (a) is advantageously periodically performed, in particular at least once every hour, preferably at least once every ten minutes, and for example once every three minutes. It is to be understood that this step (a) is preferably performed at the initiative of the slave server3, i.e. the multimedia contents are “pulled” from the master server2, and not “pushed” by the master server2, so as to be as resource effective as possible.

In more details, the slave server3also stores a set of available multimedia contents, referred to as second set, that is intended to be as similar as possible the first set thanks to the synchronization step (a), so that any multimedia content available at the master server2could be retrieved by the user terminal1directly from the slave server3. If the synchronization has been performed, the target multimedia content shall belong to said second set as it already belongs to the first set, i.e. be available at the slave server3.

In other words, step (a) preferably comprises synchronizing (a) the slave server3with the master server2so that a multimedia content is made available in the second set if, and only if, it is available in the first set.

Note that such synchronization does not imply that the first and second sets are identical, only that their contents are equally available. Indeed, as explained, a given multimedia content could be available at the master server2under a plurality of versions, while being available at the slave server3only under a subset of said plurality of versions, in particular according to the lowest qualities. In other words, in the case wherein a lower quality version (e.g. a few teens of megabytes in size) and a higher quality version (e.g. several gigabytes in size) are available for the same content at the main server2, only the lower quality version of this content is preferably available at the slave server3. It is to be understood that for a content to be considered available, only one version is required, so that even if less versions of this content are available at the slave server3than at the master server2, the multimedia contents are considered equally available. To rephrase again, the first set and the second set could be different.

By downloading only the lower quality versions of the multimedia contents at the slave server3, the transfer of the multimedia content consumes even less bandwidth than in the prior art architecture. For instance, when the low quality version of the content has a few teens of megabytes in size, this version can be segmented .ts files each having a few kilobytes in size, which are very easy to provide to the slave server3during the synchronization step (this may be achieved in a few minutes for an entire movie). Furthermore, for storing for example several hundreds of hours of video in a low resolution for mobile terminals, only a few gigabytes of memory are needed in the slave server3.

Besides, the CPU consumption of the slave server3stays very low because all lower quality multimedia contents are ready to be delivered to user terminals. This way, the slave server3does not need to live decode (for instance with ffmpeg) the videos in order to forward them to the mobile terminals, which requires a high processor and memory consumption process. Such a processing is not necessary because the size optimization process was made only once, in the master server2.

Synchronization step (a) advantageously comprises checking if at least one multimedia content has been added to the first set of multimedia contents available at the master server2, and downloading from the master server2each multimedia content added to said first set of multimedia contents available at the master server2to the second set of multimedia contents available at the slave server3(possibly under less versions than available at the master server2). Similarly, synchronization step (a) advantageously comprises checking if at least one multimedia content has been deleted from the first set of multimedia contents available at the master server2, and deleting each multimedia content deleted from said set of multimedia contents available at the master server2from the second set of multimedia contents available at the slave server3.

In the case where there is a first indexation file, the slave server3may similarly store a second indexation file describing the second set of multimedia contents available at the slave server3. Then, step (a) preferably comprises firstly downloading the first indexation file from the master server2and updating the second indexation file: therefore, the slave server3directly knows what are the added/deleted contents by comparing with the first and second indexation files.

In an exemplary embodiment, a script of synchronization is installed into the slave server3. This script checks for modification of multimedia contents stored in the master server. If such modifications exist, the new .ts package and updated .m3u8 list are downloaded from the master server2to the slave server3, and a “channels.json” file (which indicates the available contents) is updated.

Since usually, there are only a few new videos per week, and because the user does not directly connect to master server, the data consumption is very low (and cost can be reduced for the client). In addition, there is no need for a high internet connection stability as in the prior art architecture, since the slave server3and master server2connect with each other only periodically and if this connection is interrupted, it can be resumed later with little impact on the service.

Note that the periodical check costs near to zero in terms of bandwidth. In case of lower quality videos (e.g. videos adapted for display on a mobile terminal), downloading the new multimedia contents only generates a few megabytes of traffic per week.

Providing the Target Multimedia Content

The method further comprises a step (b) of providing said target multimedia content to the user terminal1from the slave server3.

As explained, this step can be totally independent from synchronizing step (a), that can be performed periodically, independently from any user demand.

By contrast, step (b) is preferably performed when receiving a request for said target multimedia content from the user terminal1. It is to be understood that the present method is performed by the processing means31of the slave server3, so that said request is directed to the slave server3and not to the master server2.

As already explains, the user terminal1preferably implements a dedicated client application for redirecting the user to the slave server3and generating said request. In other words, the user selects the target multimedia content on its user terminal1, in particular for directly playing it, and the user terminal1generated the suitable requests, sends it to the slave server3, and receives in response the content.

This client application preferably comprises a player for directly playing the content while it is received (streaming). Thus, there may be server module on the slave server3for communicating with the client application. More precisely, the slave server3may provide a portal (specific to a given slave server3and therefore country customized) listing the available multimedia contents to the user terminal1.

In the case of a mobile terminal, the dedicated client application advantageously automatically requests the lower quality version of said target multimedia content.

Consequently, everything is totally transparent to the user, which has nothing to choose and does not even know that he is communicating with a slave server3instead of the master server2.

In the case of video, this client application may be dedicated to VOD services only, or also used for accessing TV IP programs through the same server, thereby offering a single mobile interface for accessing both TV and VOD. This implementation is easy to implement since, in television, a continuous streaming is used while lower quality content may be continuously downloaded from a dedicated server (for instance preferably also the master server2—in other words, when the user selects a VOD content, a request is sent to the slave server3, while when the user selects a TV content, a request is sent to the master server2). Thus, adaptation for also dealing with the delivery of VOD is straight forward, while also providing the best user experience.

Slave Server and Computer Program

In a second aspect, the present development concerns a slave server3, adapted for carrying out the method for providing to a user terminal1a target multimedia content belonging to a first set of multimedia contents available at a master server2as previously described.

As already explained, the user terminal1is preferably a mobile terminal such as a smartphone or a touch tablet. The slave server3is connected to both the user terminal1and the master server2through a network10, and typically comprises a processing unit31and a storage unit32.

Said processing unit11is configured to implement:Synchronizing the slave server3with the master server2so that each multimedia content of said first set of multimedia contents available at a master server2is also available at the slave server3;Providing said target multimedia content to the user terminal1from the slave server3.

The development further proposes a computer program product, comprising code instructions for executing (in particular with a processing unit31of the slave server3) a method according to the first aspect of the development for providing to a user terminal1a target multimedia content belonging to a first set of multimedia contents available at a master server2; and a computer-readable medium (in particular a memory32of the slave server3), on which is stored a computer program product comprising code instructions for executing said method.