Modulated pre-caching of media content in a mobile environment

Abstract

An external streaming system (100) accessed from a mobile environment (150), such as a train, has the disadvantages of a storage space (1522) that is too limited to cache a significant portion of a large catalog of content, and an unreliable communication link to an external CDN (110) to allow uninterrupted playback from the start of the content. A cache server (152) allowing only a beginning portion of one or more media contents to be pre-cached will be beneficial. Scores associated with the contents are obtained to choose the quality(s) of the content to be pre-cached and to quantify the length of their beginning portions. The bandwidth of the link, the storage space available in the cache, user preferences or history, and train journey times are taken into account. The beginning portions are pre-cached by simultaneous progressive loading. [Fig. 1]

Description

Title of the invention: Modulated pre-caching of media content in a mobile environment Field of invention

[0001] The present invention relates to the field of continuous broadcasting or “streaming” of content, typically multimedia. Previous techniques

[0002] Streaming is used to view or listen to media content online, without having to download a file to the playback device.

[0003] Streaming operates between two parties: on one side, a client equipped with a content player at an end-user's rendering device and, on the other, a server (or several servers) which makes the media content available.

[0004] In a streaming service, it is typical to have one or more content delivery networks (or CDNs for "Content Delivery Network") made up of content servers making the content available in the form of unicast streams. The available content is described in descriptive (manifest) files, the names of which vary from one technology to another, for example "master playlist", "media playlist" or "manifest" in HLS (Apple's HTTP Live Streaming - trade name) or "MPD" (for "Media Presentation Description") in MPEG-DASH. End users, typically content readers, can then access this content in successive segments via unicast HTTP requests, i.e. secure HTTP, to the URL addresses (for "Uniform Resource Locator") indicated in these files.

[0005] The same media content is conventionally offered, in a descriptive file, according to several qualities (for example resolutions, compression levels or corresponding bitrate, frame rates, subtitles, audio, accessibility options for people with hearing and / or visual impairments, etc.) at the choice of the content player which “adapts” dynamically by switching, if necessary, from one quality to another. Also, hybrid video streaming is said to be “adaptive”. Each quality is described in the descriptive file under a different track. The term “track” is thus used as a synonym for quality for a given content.

[0006] It goes without saying that a streaming service is only effective if the communication link between the client and the server is maintained at good quality throughout the streaming. Also, if the quality of the link decreases, the content player is inclined to switch to a lower quality track as proposed in the description file.

[0007] One area in which communication links frequently fluctuate over time concerns transportation. Indeed, a vehicle, when moving, may cross areas not covered by a communication network or temporarily move away from base stations, reducing the quality of communication. Conversely, it may also recover a better quality link at other times. The streaming experience in such vehicles may then suddenly degrade.

[0008] Similarly, in the air domain, if the communication link is rather stable once the flight has stabilized, its bandwidth is extremely reduced due to the sharing of a satellite link with several aircraft.

[0009] The presence of one (or more) on-board cache servers in these vehicles can improve this situation.

[0010] Indeed, such an embedded cache server, or "proxy", makes it possible to store certain content locally in advance and deliver it directly to any local user requesting it, without having to connect to external CDNs via the communication link with the outside. This advance storage is also known as "pre-caching" or "pre-caching" meaning caching prior to any request for the content concerned.

[0011] The main constraints of such systems concern the limited capacity of the memory of the onboard cache server to store content, as well as the fluctuating bandwidth of the communication link which may make it difficult to retrieve content not pre-cached in the cache server.

[0012] Application WO2020223607 proposes servers (“capacitors”) in stations that pre-cache content in order to provide better responsiveness when loading it into trains or other vehicles. Content, for example prioritized according to its popularity or size, is then loaded into the onboard cache servers of a train when the latter is in the station. This solution thus optimizes the chances that content requested by an onboard user corresponds to pre-cached content, i.e. pre-loaded content in the onboard server.

[0013] This solution is not, however, entirely satisfactory.

[0014] In particular, it is suitable for a limited and stable catalog of “on demand” (or VOD for “video on demand”) type content given the limited memory capacity of the on-board cache server.

[0015] Adapting it to an extensive catalog would require a considerable local cache size storing never-read content, or the frequent use of the unreliable communication link to retrieve entire non-precached content when requested by a user. However, reading out of cache degrades necessarily the user experience (long launch of content, risk of cutting out during playback).

[0016] Furthermore, its adaptation to a frequently updated catalogue would require the loading of a significant quantity of data (contents), sometimes not compatible with the time available at the station.

[0017] There is therefore a need for an improved streaming system that can better utilize the available onboard memory space in an ecological perspective, and offer a satisfactory user experience while facilitating the renewal of any part of the catalog. Statement of the invention

[0018] Noting the limitations of known techniques, the inventors propose a system controlling the pre-caching of contents with more progressiveness and more finesse in order to store and transmit a reasonable quantity of data and to ensure reliable reading on a large number of contents.

[0019] For this purpose, a media content streaming system is provided, comprising a mobile environment having a cache server in which media content data available from a content unicast server external to the mobile environment is pre-cached. The cache server is configured to pre-cache only a starting portion of one or more media contents.

[0020] The term "start portion" means the set of media data that makes up the start of the media content concerned (e.g., film), typically the first and subsequent media segments. A start portion or part of a media content is a sub-part of the latter, meaning that one or more media segments are not pre-loaded into cache memory.

[0021] By preloading only the beginning of media content, more content can be partially pre-cached, thus improving the average user experience when starting content playback. Furthermore, the amount of data to be loaded during a partial catalog refresh is reduced, limited to the beginning portions of new content to be preloaded.

[0022] Correlatively, a method for streaming media content in a mobile environment is also proposed, comprising a step of pre-caching, in a cache server of the mobile environment, media content data available from a unicast content broadcast server external to the mobile environment, method in which the pre-caching comprises the pre-caching of only a starting portion of one or more media contents.

[0023] Optional features of embodiments of the invention are defined in the appended claims. Some of these features are explained below with reference to a system, while they can be transposed into method features.

[0024] In one embodiment, a pre-caching manager is configured to obtain scores associated with respective media contents and to control the pre-caching of a starting portion of each media content, the length of which is a function of the associated score. Priorities may be placed on the media contents, for example based on the popularity of the media content or an editorial desire to highlight it.

[0025] The pre-cached start portion for a media content can thus be all the more important as the score associated with the content is high. A partial and modulated pre-caching of the media content is thus put in place.

[0026] Furthermore, no pre-caching can be carried out in the event of a score that is too low (below a low threshold), whereas the entire media content can be pre-cached in the event of a very high score (above a high threshold).

[0027] The mathematical relationship between the score (typically between the two thresholds) and the length of the starting portion to be pre-cached can be convex. Thus,

[0028] According to one characteristic, the length of the starting portion of a pre-cached media content corresponds to a percentage of said media content, determined according to the associated score.

[0029] Alternatively or in combination, the length of the start portion of a pre-cached media content corresponds to a duration of said media content, determined based on the associated score. It is thus possible to guarantee a minimum duration of playback of the media content without interruption.

[0030] In one embodiment, a length of the start portion of a pre-cached media content is a function of an estimate of a bandwidth available on a communication link between the mobile environment and the external unicast content server. This makes it possible to optimize the pre-cached portion so as to minimize the risks that the playback of the content catches up with the end of the cache. Indeed, as described below, the launch of the playback of the content can trigger the caching of the missing portions (media segments). The pre-cached start portion is sized so that the playback does not catch up with the media segments being retrieved. The available bandwidth can be a sub-portion of the total bandwidth available on the communication link, a sub-portion assigned to the content or to a partially pre-cached media content pool.

[0031] In one embodiment, media content is available in a plurality of qualities, and the pre-caching manager is configured to determine, based on the score associated with the media content, one or more of said qualities for which a starting portion is pre-cached. This arrangement makes it possible to improve the user experience by, for example, pre-loading video segments of the high quality in the event of a high probability (score) that users in the mobile environment will consume the media content. It also makes it possible to reduce the waste of memory space in the cache by, for example, only pre-loading video segments of the lowest quality in the event of a low probability (score) of viewing in the mobile environment.

[0032] According to one feature, a length of the start portion of a pre-cached quality is a function of the bit rate of the quality and the associated score. Indeed, the higher the quality of a track (and therefore with a high bit rate), the more useful it appears to be to pre-cache a larger portion of the track, because uninterrupted playback to the end of the content is more complex to guarantee. Conversely, with a low bit rate, it is easier to recover the missing video segments via the communication link.

[0033] In one embodiment, a length of the start portion of a pre-cached media content is a function of an available cache storage space. This space may be shared by all the contents to be pre-cached.

[0034] In one embodiment, a length of the start portion of a pre-cached media content is a function of users of the mobile environment between two cache synchronization sessions according to two distinct media content pre-caching plans.

[0035] In one embodiment, the scores associated with the media contents are a function of users of the mobile environment between two cache synchronization sessions according to two distinct media content pre-caching plans.

[0036] These pre-caching customizations improve the consumption of pre-cached media content between the two synchronization sessions, typically a trip or journey of a vehicle, and therefore reduce the waste of memory space in the cache. For example, synchronization sessions can be provided at each station used by a train in order to adjust the pre-cached content to the passengers boarding and alighting. Alternatively, the synchronization sessions can be provided only at the departure and arrival stations.

[0037] For illustration purposes, a high score may be assigned to episodes following an episode recently consumed by one or more travelers.

[0038] Still by way of illustration, the start portion of media content to be pre-cached may be extended beyond a last reading position of the content by one or more travelers, thus allowing them to continue their reading without interruption.

[0039] In one embodiment, the scores associated with the media content are a function of a schedule between two cache synchronization sessions according to two separate media content pre-caching plans. The pre-cached content is thus a function of the schedule of the trip in question, making it possible to prioritize the content generally consumed at that time compared to other media content.

[0040] In one embodiment, the cache server is configured to obtain an ordered list of media segments composing the start portions according to priorities assigned to the media segments, and to pre-cache the media segments in decreasing priority. This arrangement makes it possible to guarantee that in the event of incomplete synchronization, the highest priority media segments (therefore a priori the most likely to be consumed) are accessible to users, and thereby improve the user experience.

[0041] In one embodiment, the cache server is configured to pre-cache starting portions of a plurality of media contents by simultaneously progressively loading their starting portions. This arrangement ensures the pre-caching of the first video segments of all the media contents considered. Also, even in the event of incomplete synchronization of the cache memory before the departure of the train, passengers are able to start playing these contents.

[0042] In one embodiment, the cache server is configured to pre-cache starting portions of a plurality of media contents by prioritizing a low-quality starting portion of a media content over a high-quality starting portion of the same media content. This arrangement maximizes the compatibility of the content with the different players embedded in the mobile environment, even in the event of incomplete synchronization of the cache memory before the train departs.

[0043] In one embodiment, the cache server is configured to load, via a communication link between the mobile environment and the external unicast content server, missing portions of a media content, in response to the initiation of playback of the media content in the mobile environment. The start of loading may be immediate or may be slightly delayed (for a confirmation duration) pending confirmation that playback is continuing.

[0044] According to one feature, the missing portions of the media content include missing media segments of one quality being played and media segments of at least one other quality of the same media content.

[0045] Of course, it is possible that the missing media segments of the only quality currently playing are loaded.

[0046] The embodiments described above may be combined, unless expressly excluded.

[0047] The present invention also relates to a computer program comprising instructions for implementing the above method, when this program is executed by a processor.

[0048] This program may use any programming language (for example, an object language or other), and be in the form of interpretable source code, partially compiled code or fully compiled code.

[0049] The invention also relates to a non-transitory recording medium readable by a computer on which a program is recorded for implementing the above method, when this program is executed by a processor.

[0050] At least a portion of the methods of the invention may be computer-implemented. Accordingly, the present invention may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be collectively referred to herein as a "circuit," "module," or "system." In addition, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

[0051] Since the present invention may be implemented in software, the present invention may be embodied in computer-readable code for delivery to a programmable apparatus on any suitable medium. A tangible or non-transitory medium may include a storage medium such as a hard disk drive, a magnetic tape device, or a solid-state memory device and the like. A transient medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal, or an electromagnetic signal, for example, a microwave or RF (radio frequency) signal. Brief description of the drawings

[0052] Other characteristics, details and advantages of the invention will appear on reading the detailed description below. This is purely illustrative and must be read in conjunction with the appended drawings, in which:

[0053] [Fig.l] schematically represents an example of an adaptive video streaming system;

[0054] [Fig.2] illustrates an example of a descriptive manifest file or root “manifest” for media content;

[0055] [Fig.3] schematically illustrates a cache memory of an embedded cache server in a mobile environment;

[0056] [Fig.4] illustrates multiple pre-caching synchronization sessions over time for the same mobile environment;

[0057] [Fig.5] illustrates, using a flowchart, steps of a pre-caching method according to embodiments;

[0058] [Fig.6] illustrates an example of a mathematical relationship between a score assigned to a media content and the length of the starting portion to be pre-cached, according to embodiments;

[0059] [Fig.7] illustrates, using a flowchart, steps of a streaming process by a cache server according to embodiments; and

[0060] [Fig.8] represents a variant of adaptive video streaming system. Detailed description

[0061] An external streaming system accessed from a mobile environment, such as a train, has the disadvantages of a storage space that is too limited to cache a significant portion of a large catalog of content, and an unreliable communication link to an external CDN to allow uninterrupted playback from the start of the content. A cache server that can pre-cache only a starting portion of one or more media contents will be beneficial. Scores associated with the contents are obtained to choose the quality(s) of the content to be pre-cached and to quantify the length of their starting portions. The bandwidth of the link, the storage space available in the cache, user preferences or history, and train journey times are taken into account. The starting portions are pre-cached by simultaneous progressive loading.

[0062] [Fig.l] illustrates an adaptive streaming system 100 for media content, such as video on demand (VOD). Only the equipment and functions useful for the explanations below are illustrated, to simplify the explanations. Nevertheless, those skilled in the art will recognize the additional equipment or functions that are conventionally used for the operation of a streaming system.

[0063] The representation of the equipment and functions is purely schematic. An illustrated block or module can be implemented within one or more physical equipment (server type). Similarly, two or more illustrated blocks / modules can be implemented within the same physical equipment.

[0064] The system 100 conventionally comprises one or more public unicast content distribution networks or “CDNs” 110, one or more manifest servers 120, a communication network 130 to which the servers 110, 120 are connected and to which client terminals equipped with content readers 199 can connect, and an alternative communication network, for example a mobile telephone network 140 interfacing certain client terminals with the network 130.

[0065] A CDN 110 comprises one or more servers for storing multimedia content in a format allowing its continuous distribution (streaming). Multimedia content may correspond to a film, a documentary, a series episode, a live event (sporting or not), etc.

[0066] Typically, an initial media content is encoded according to different resolutions or qualities, for example in a 4K or ultra high definition (UHD) version, a Full HD (FHD) version, a high definition (HD) version and a low definition (SD) version. Of course, a different number of versions can be produced as well as other definitions or formats (e.g. HDR, HFR, etc.). Similar to these examples of different video qualities, different qualities can be offered for audio tracks. Thus, the initial media content (film, documentary, sporting event, etc.) can give rise to N (entire) media files accessible to users in the streaming system 100.

[0067] As is known, a large number of criteria can be used to differentiate several media files from the same initial media content: for example, resolution, quality, bit rate, frame rate, codec, audio language, subtitle, etc.

[0068] The media files thus produced are fragmented (packaged) into unicast media segments that satisfy a unicast streaming format. Typically, the media segments of the same media file have the same file name supplemented, for example, by an incrementing counter.

[0069] The media segments (i.e. the media file of a given quality) are stored under these names permanently in the CDN servers to allow on-demand access (VOD).

[0070] The Figure illustrates three CDNs 110 for unicast delivery of media segments corresponding to the different qualities of media content accessible in the streaming system shown. Of course, a different number of one or more CDNs is conceivable.

[0071] It should be noted that if the description subsequently focuses on video broadcasting, similar considerations apply to the other components of a multimedia service, typically audio tracks, subtitles, interactive data, etc.

[0072] The descriptive file server(s) or “manifests” 120 store the description files 125 of the different contents stored on the CDNs 110 and accessible to users.

[0073] In a known manner, a root description file is generated for each multimedia content (for example a TV channel, a VOD title). This description file is called a “manifest” or MPD in the MPEG DASH protocol (“Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP” - commercial name) and a “master playlist” in the HLS protocol (for “HTTP Live Streaming”). The root description file is generated once for a VOD media content or is generated dynamically for live filmed events.

[0074] An example of a root descriptive file 200 is illustrated in [Fig.2] in HLS format. This file is simplified to the useful elements, for reasons of clarity. In practice, other attributes are specified for the available tracks. The root descriptive file includes metadata (on the lines starting with the # tag) some of which define a plurality of tracks which correspond to the different media files available on the CDN 110, and therefore to the different accessible qualities. Each track is composed of a line of metadata specifying attributes of said track and a second line indicating the URL of an associated file, descriptive of the media segments constituting the media file.

[0075] In this example, track 220 defines audio content in French, details of the media segments of which are provided in the track description file “audio Lm3u8” stored on the CDN server “extemal.server.com”. Similarly, track 221 defines audio content in the original version, details of the media segments of which are provided in the file “audio2.m3u8”.

[0076] Tracks 230 define low resolution SD video content with distinct parameters such as resolution (416 pixels x 234 pixels, 640x360, 768x432, 960x540) or encoded bitrate (“bandwidth”). A detail of the corresponding media segments is provided in the files "wl_v_avc_0_234_416_0_190.m3u8", "wl_v_avc_0_360_640_0_300.m3u8", "wl_v_avc_0_360_640_0_300.m3u8", "wl_v_avc_0_540_960_0_110 0.m3u8", "wl_v_avc_0_540_960_0_1500.m3u8", "wl_v_avc_0_540_960_0 _2100.m3u8" stored on the server "external.server.com" respectively. Similarly, track 231 defines a high resolution HD (1280x720) video content, with details of the media segments provided in the file "wl_v_avc_10_720_1280_0_3400.m3u8" stored on the same server. Track 232 defines a Full HD (1920x1080) video content, with details of the media segments provided in the file "wl_v_avc_20_1080_1920_0_4500.m3u8" stored on the same server.

[0077] Each alternative track in the descriptive file 200 therefore corresponds to a second “m3u8” content descriptive file, or “track descriptive file”, which indicates the URL web addresses where the content player 199 obtains, by unicast requests, the different media segments constituting the content / track. This file includes a large number of descriptive elements corresponding to respective media segments, each descriptive element specifying the URL (relative if on the same server or absolute otherwise) where the corresponding media segment is stored. In other words, this file is basically a playlist of URLs.

[0078] The last descriptive element of the track description file corresponds to the last "available" media segment of the streaming. The previous descriptive elements correspond to the "earlier" media segments. Their presence in the descriptive file offers the user video player the possibility of a "startover" rewind. The "startover" depth (therefore the number of descriptive elements indicated) is adjustable.

[0079] The case of the DASH format is slightly different. The DASH MPD root descriptive file lists the different qualities / tracks available and directly includes, for each of these qualities / tracks, the URLs where the content player 199 obtains, by unicast requests, the different media segments of the track. Also, in the DASH format, there is no track descriptive file; the MPD root file merges, into a single file, both the HLS master playlist file and the multiple corresponding HLS media playlist files. The URLs can be absolute addresses for the case where the media segments are stored on a server other than the one delivering the MPD root file.

[0080] The descriptive files are obtained by the content player 199 upon requests from the server 120. In a known manner, the content player 199 requests the root descriptive file 200 of a multimedia content that it wishes to access, selects one of the tracks according to the desired (or supported) quality / resolution and requests, in the HLS case, the track descriptive file corresponding to the selected track. It is then that it can request the CDN 110 (by unicast requests) to obtain the successive media segments from the CDN, typically for an audio track, a video track and optionally a subtitle track.

[0081] CDNs 110 are classic infrastructures based on HTTP, typically standard secure DASH or HLS servers (therefore HTTPs). They perform unicast broadcasting / streaming of content, i.e. they deliver media segments to user content players upon request.

[0082] The requests and media segments returned transit through the public communications network 130, typically the Internet network, possibly via another communications network, for example a mobile telephone network 140 in the case where the user content reader equips a telephone-type user terminal connected to the network 140.

[0083] [Fig.l] illustrates an adaptation of the system to a collective environment (airport, train station, etc.), and in particular to a mobile environment such as collective transport such as a vehicle (train, plane, boat / ferry, bus, etc.). Although only one collective environment 150 is shown, several may exist simultaneously in which users have access to the streaming service as described below. Typically several trains may operate simultaneously. The remainder of the description is based on a mobile environment such as a train for illustrative purposes only. It therefore applies to any other mobile environment.

[0084] As illustrated in the Figure, the train 150 comprises a communication interface 151 with the outside (in particular the CDNs 110), a cache server 152 and one or more user terminals equipped with content readers 199, as well as a local communication network 160 to which these different entities are connected. The local communication network 160 may be wired or not, typically an on-board WLAN network. The train is also connected to an external communication network, such as the network 130 or 140, giving it access to the external servers 110 and 120.

[0085] Subsequently, the notion of “local” relates to the elements and operations on board the train 150 as opposed to the elements and operations of the servers 110 and 120.

[0086] A user terminal can take the form of a smartphone, a tablet, a laptop or desktop computer, a connected object (television, watch, camera, virtual or mixed reality glasses, etc.). A user terminal is connected to the local network by wired (Ethernet cable) or wireless (Wi-Fi) connection. A user terminal, typically a telephone or a tablet, can also be connected to the mobile telephone network 140 (in particular when the user leaves the train). Such a terminal therefore has the possibility of switching from one network (local) to another (mobile).

[0087] Access to the streaming service by the user content players 199 can be done using a dedicated playback application executed on the user terminal or through a web browser of the user terminal which executes said video player. For example, a telephone connected to the mobile telephone network 140 accesses the streaming service in a conventional manner by unicast requests to the CDN (to retrieve the manifest files 125 then the media segments). A terminal connected to the on-board or “local” WLAN network 160 accesses the streaming service in a conventional manner by unicast requests to the CDN, which can be intercepted by the cache server 152.

[0088] The cache server 152 is a server dedicated to the temporary local saving (or “caching”) of various previously consulted media contents, typically accessed media segments. By recording this data, the cache server speeds up access to it during subsequent consultations, while reducing the bandwidth demand on the communication link to the CDNs 110.

[0089] The cache server 152 is a proxy server (or delegation server) which interfaces the local network 160 with the external network 130, intercepts user requests to the external network 130 and processes them locally to the extent possible. Any unicast request for a track description manifest file or a media segment stored on a CDN 110 is thus intercepted by the cache server 152 which provides the requested data if they are in the cache memory of the server 152, without requesting the CDN 110, or which retransmits the unicast request on the external network 130 to the CDN 110 if the requested data is not in the cache memory.

[0090] Certain data (track descriptive manifest files or media segments) may be pre-cached in the server 152 memory in order to increase accelerated access to media content. “Pre-caching data” means storing this data in the cache server memory even before a user has consulted it. The expression “pre-caching” used interchangeably has the same meaning: pre-loading data into the cache memory before any consultation / request of this data.

[0091] [Fig.3] schematically illustrates a memory 1520 of cache server 152, of storage memory type with a capacity of one or more terabytes (TB).

[0092] This memory can be divided into two parts, one 1522 for data pre-caching and the other 1524 for classic data caching (i.e. when consulting the data by a local user). The proportion of available memory dedicated to pre-caching and dedicated to classic caching can be adjusted according to needs. A static distribution can be used, for example 80% for pre-caching and 20% for caching or for example a given quantity corresponding to the travel time multiplied by the average bandwidth can be reserved for caching. A dynamic distribution can also be implemented where media segments to be cached which have a higher priority than pre-cached segments replace the latter, modifying the distribution of the memory 1520.

[0093] This dynamic approach also allows the use of a 1520 memory without division: lower priority stored media segments being replaced by higher priority segments during caching in the event of a lack of memory space.

[0094] Data (typically media segments) of media content available from the external CDN(s) 110 are pre-cached in memory 1522 of the onboard cache server 152, for example in a departure station of the train 150.

[0095] In particular, only a portion or beginning part of one or more media contents is pre-cached in memory 1522. This involves putting in memory 1522 the Media segments that make up the beginning of the media content, one or more of its qualities / tracks and not their entirety, before a user views them.

[0096] [Fig.3] illustrates that a large number of media content starts VI, V2, ..., Vi, can thus be pre-cached, making it possible to make the playback of a larger number of media contents more reliable by users local to the train 150. The playback of the rest of the media content can be carried out “on the fly”, that is to say by retrieving the video segments from the CDNs 110 during the train's journey. In this figure, VI represents all the media segments pre-loaded for the content VI, including any multiple tracks of this media content.

[0097] The following description sets forth embodiments for determining these starting portions to pre-cache.

[0098] [Fig.l] also illustrates a pre-caching manager 153 dedicated to these pre-caching operations in the train 150. This pre-caching manager 153 can be an on-board device separate from the cache server 152 (as in the Figure) or be integrated into the cache server 152 itself. In this case, the pre-caching manager 153 takes care of the pre-caching operations in the train 150 only. Alternatively, the pre-caching manager can be external (not shown) and manage the pre-caching of a fleet of trains, each train having its own pre-caching plans and its own synchronization sessions according to these operational plans.

[0099] A pre-caching plan defines the media segments affected by a pre-caching 1522, i.e. the media contents affected, including the tracks affected and their respective start portion lengths.

[0100] As illustrated in [Fig.4], a first pre-caching synchronization session can be launched according to a first plan PI when the train 150 is in a first station G1; a second subsequent pre-caching synchronization session is launched according to a second plan P2, distinct from PI, when the train 150 is in a second station G2; a third subsequent pre-caching synchronization session is launched according to a third plan P3, still distinct from the previous one, when the train 150 is in a third station G3.

[0101] Media segments, therefore media content, can thus be raised or lowered in cache priority even before a first consultation by a user. The Figure illustrates a possible frequency of refreshing the pre-cache 1522.

[0102] Stations G1 to G3 are, for example, departure stations for distinct train journeys, in which case plans PI to P3 are likely to be substantially different. Departure stations have the advantage of having longer train immobilization times, allowing for better quality pre-caching synchronization.

[0103] Stations G2 and G3 may alternatively be intermediate stopping stations for the train on a given journey. Plans PI to P3 are then likely to be substantially similar, with adjustments being able to be made (as described below), depending on passengers getting off and getting on at intermediate stations, or even depending on new content (for example with very high audience) made available during the train's journey. The synchronization sessions are then compatible with a shorter immobilization of the train in these stations.

[0104] Depending on the time spent at the station, synchronizations may be complete at the station or partial and continue during the train's journey, possibly at a subsequent intermediate stop station.

[0105] [Fig.5] illustrates, using a flowchart, steps of a method for establishing a pre-caching plan P and carrying out the corresponding synchronization session. These steps are implemented by the pre-caching manager 153.

[0106] In step 50, the pre-caching manager 153 obtains decision parameters which may concern all or part of the information relating to the contents, the journey and the passengers.

[0107] Actionable information relating to content includes, for example, an audience forecast. This forecast can be established by time window, since certain content is in fact more consumed at certain specific times.

[0108] Audience forecasts include, for example, an editorial indication, an indication of whether the media content has a high audience, whether it is an episode of a high audience series, whether it is highlighted on the streaming service (typically on a home page), whether it is newly added to the catalog.

[0109] Decision information relating to the journey includes, for example, the schedule between stations G1 and G2 of two successive synchronization sessions.

[0110] Decision-making information relating to travelers includes, for example, preferences or consumption wishes of travelers participating in the journey between stations G1 and G2 of two successive synchronization sessions. These preferences may include a typology of media content consumed, a list of series currently being viewed, content currently being viewed (with their current reading position).

[0111] In step 52, the pre-caching manager 153 determines a score for each media content, from this decision-making information, in particular a score on the upcoming journey between stations G1 and G2. The score can be a number between 0 and 10 or a percentage between 0 and 100.

[0112] Simply put, a correspondence table, with multiple entries if necessary, can match values ​​or states of this decision-making information to a score.

[0113] One objective is to determine the contents, and therefore their media segments, which will have the greatest chance of being read on this journey. If the next synchronization time is not known, a pre-set duration can be used, for example 2 hours or 3 hours for a train. Pre-caching of media contents can thus be optimal for consumption during this journey.

[0114] The scores typically reflect the chances or probability of viewing the media segments of these contents considered. Also, the scores are calculated based on decisional information relating to the contents: a media content with a high audience is assigned a higher score than a media content with a low audience. Any correspondence function between an audience indicator and a score (for example between 0 and 10) can be implemented.

[0115] In one embodiment, the scores associated with the media contents are a function of the users of the train between the two synchronization sessions. Typically, the following episodes of a series currently being viewed are assigned a high score, for example 8. Similarly, the media contents currently being viewed are assigned a high score, for example 8.

[0116] Optionally, users can declare the content that they plan to view during the journey, in which case this media content can be assigned a high score, or even a maximum of 10. This score can be higher if the number of users having made such a declaration is high.

[0117] In another embodiment, the scores associated with the media content are a function of a schedule between the two synchronization sessions. For media content whose audience is likely to vary over time, the journey schedule is taken into account here to use the corresponding theoretical audience in calculating the score.

[0118] In step 54, the pre-caching manager 153 determines the quality(s) (or tracks) to be pre-cache as well as the lengths of the portions to be pre-cache for each of the media contents, based on the score obtained for the content considered. The manager's role is in fact to control the pre-caching 1522 of the media contents.

[0119] An objective of step 54 is to provide pre-caching at the beginning of the journey of a maximum of media content for a better user experience.

[0120] Step 54 comprises two sub-steps: the determination 540 of the quality(s) to be pre-cached and the determination 542 of the length to be pre-cached either for the media content as a whole or for each quality to be pre-cached.

[0121] In a simple manner, each sub-step can implement a correspondence table which associates, on the one hand, the above score values ​​with tracks / qualities to be preloaded, possibly according to one or more other criteria mentioned below, and on the other hand, the score values ​​with lengths of media content to be preloaded, possibly according to one or more other criteria mentioned below.

[0122] The two sub-steps can be carried out simultaneously via a common correspondence table. For example, the scores make it possible to distinguish between: very low score contents for which nothing is pre-cached, higher low score contents for which only a small part of the SD track is pre-cached, higher average score contents for which only a larger part of the SD track is pre-cached, higher good score contents for which part of the HD track is pre-cached, in addition to all or part of the SD track, high score contents for which a large part of the HD track is pre-cached, in addition to all or a large part of the SD track, and maximum score contents for which all of the HD and SD tracks are pre-cached.

[0123] A ranking of the contents is thus obtained based on their scores.

[0124] Of course, this example can be adjusted to a larger number of tracks and with a greater number of levels of distinction. SD and HD tracks are used for illustrative purposes, and other tracks including HD, FHD can be used instead. Track “parts” can be considered in terms of percentage as discussed later.

[0125] Step 54 can be implemented for media content whose associated score is greater than a low trigger threshold SI (as described below). In the example above, for low-scoring content, nothing is pre-cache.

[0126] The determination 540 of the qualities (or tracks) to be pre-cached is optional insofar as certain media contents may only be available according to a single quality or insofar as it may be decided to pre-catch all the available qualities of a media content in an identical manner.

[0127] The choice of the quality(s) / track(s) to pre-hide is a function of the score obtained for a given media content, as illustrated in the example above.

[0128] A pre-caching scheme may provide that for media content with a very high audience (high score), high quality is pre-cached to provide a high user experience. On the other hand, for media content with a lower probability of viewing, only low quality may be pre-cached to reduce the waste of memory space in the event of non-viewing.

[0129] According to a complementary pre-caching scheme, several qualities of a very high audience media content can be pre-cached, to maximize compatibility and quality. Typically, 4K, HD and SD tracks can be pre-loaded, the 4K track not being readable by all user terminals. In a particular embodiment, a low quality (for example SD) is systematically pre-cached to guarantee maximum compatibility.

[0130] On the other hand, for content with a low viewing probability, pre-caching a single low-quality track compatible with all user terminals proves sufficient.

[0131] As an illustration, media contents having scores between SI and an intermediate threshold S3 ([Fig.6] described below) are only (and partially) pre-cached in this low quality (track) compatible with all terminals. In the example above, for contents with an average score, only a small part of the track SD is pre-cached.

[0132] Furthermore, media contents having scores beyond a second intermediate threshold S4 are pre-cached with a high quality track and optionally with one or more lower quality tracks. In the example above, for high score contents, a large part of the HD track is pre-cached in addition to all or part of the SD track.

[0133] Between the two intermediate thresholds, pre-caching of tracks of intermediate quality can be considered. In the example above, for content with an average or good score, a larger portion of only the SD track is pre-cache than for lower scores, or even a portion of the HD track in addition to all or part of the SD track.

[0134] Beyond a maximum threshold S2, full pre-caching of all or part of the available tracks can be considered. In the example above, for maximum score content, all HD and SD tracks are pre-cache.

[0135] Thresholds SI and S2 may be omitted.

[0136] In one embodiment, the determination of the quality(s) / track(s) to be pre-cache is a function of the storage space available in cache memory 1522. Indeed, if this memory space is limited compared to the size of the media content catalog, it may be decided to pre-cache media segments of only one track (or a limited number of tracks) per media content at most.

[0137] More generally, the available storage space may condition the number of media contents whose media segments can be partially pre-cached, for an estimated quantity to be pre-cached per media content.

[0138] In another embodiment, the determination of the quality(s) to be pre-cache is a function of an estimation of a bandwidth (or flow rate) available on the communication link between train 150 and CDN 110. Indeed, if the communication link is of good quality, on-the-fly loading of high-quality media segments should be possible. In this case, pre-caching of high-quality tracks may be preferred for certain content (particularly those with a high score). Conversely, poor average communication link quality may lead to only authorizing pre-caching of intermediate and / or low-quality tracks.

[0139] The average bandwidth is estimated for the journey where the contents will be consumed by the passengers, typically between stations G1 and G2 of two successive synchronization sessions. It can be known from previous journeys made between the same two stations. Alternatively, a pre-fixed bandwidth, average for an entire rail network, can be used.

[0140] Also, different correspondence tables can be used depending on the size of the catalog, the storage space available in cache memory 1522, the bandwidth estimate.

[0141] [Fig.6] illustrates, using a graph, an example of track length (therefore quantity of media segments) to pre-cache (between 0 and 100% of the content) as a function of the score (between 0 and max) obtained for the media content concerned.

[0142] Several graphs can be implemented, one to determine the length of the start portion of an SD track, another for the HD track, etc. Indeed, as in the example above, distinct quantities can be pre-cached for two distinct tracks.

[0143] Alternatively, the same graph may apply to several, or even all, tracks of a media content.

[0144] This example of [Fig.6] applicable to a quality type / track shows that no media segment of the track is pre-cached in cache memory 1522 for content with a score that is too low (lower than the low threshold SI), that all the media segments of the track are pre-cached for content with a very high score (higher than the high threshold S2), and that the quantity of media segments of the track to be pre-cached increases progressively as a function of the score for content with intermediate scores (between SI and S2).

[0145] Step 540 can thus determine the track(s) / qualities to be pre-cache partially or entirely, as well as the quantity of media segments (start portion) to be pre-cache in the case of partial pre-caching.

[0146] Reference is made hereinafter to the start portion of the media content to mean the start portion of any of the qualities to be pre-cached when the qualities are processed separately or to mean the start portion commonly for all of the qualities to be pre-cached in the other case. A start portion corresponds to a quantity of media segments that begin the relevant track.

[0147] The Figure shows that the length to be pre-cached, i.e. the quantity of media segments starting the track in question, is significant for high-scoring media content (high probability of being viewed) and that it decreases rapidly with the score. Here the mathematical relationship between the score (typically between the two thresholds SI and S2) and the length of the beginning portion to be pre-cached is convex (curve under the dashed inclined line). This makes it possible to optimize the average user experience by guaranteeing greater local playback for high-scoring content (i.e. high probability of being viewed) while ensuring a seamless start to playback for other content likely to be consumed locally.

[0148] In one embodiment, partial pre-caching may be limited to a maximum percentage less than 100%, for example 50%, meaning that the first half of a track of media content whose score is just below S2 is pre-cached while the entire track is pre-cached for a score just above S2.

[0149] As in this example, the length of the beginning portion of a media content to be pre-cached may correspond to a percentage of said media content. The percentage of video segments to be pre-cached is therefore determined based on the score associated with the media content.

[0150] Alternatively, this length may correspond to a duration of said media content. Here, the aim is to guarantee a playback duration without interruption, a duration which is therefore determined according to the score associated with the media content, i.e. the probability of local playback of the media content during the journey. Partial pre-caching may be limited to a maximum duration less than the total duration of the media content considered. In this case where the quantity of media segments to be pre-cached is determined from the pre-caching duration, long media content will ultimately have a lower percentage of pre-cached media segments compared to very short content having the same score (playback probability).

[0151] In one embodiment, the lengths of the starting portions of the media content to be pre-cached are a function of the storage space available in cache memory 1522. Indeed, the available storage space conditions the quantity of media segments that can be pre-cached per media content or track, for a known number of contents or tracks to be pre-cached.

[0152] An optimization of the lengths can be obtained, by calculation, simulation or modeling, to allow at least partially pre-caching a given number (or percentage) of media contents of the catalog. In particular, the thresholds SI, S2 (or even S3 and S4), as well as the slope of the curve of [Fig.6] between SI and S2 can be adjusted to maximize the use of the memory space available with this given number of contents pre-cached at least partially.

[0153] In one embodiment, the length of the start portion of a media content to be pre-cached is a function of an estimate of the bandwidth available on the communication link between the train 150 and the CDNs 110. Since it is desired that the playback of the media content does not suffer from cutoff, the quantity of pre-cached media segments (corresponding to a pre-cached duration) should be such that the recovery of the missing media segments is sufficiently progressive with the available bandwidth to avoid the playback catching up with the end of the cache.

[0154] This progressive recovery is a function of the bitrate of the track / quality played, this bitrate information being indicated in particular in the descriptive manifest file 125 (metadata “BANDWIDTH” in the example of [Fig.2]). Also, the length of the starting portion to be pre-cached of a quality (or track) can also be a function of the bitrate of the quality and the score associated with the media content. The higher the quality of a track (therefore with a high bitrate), the more useful it appears to be to pre-cache a larger part of the track, because uninterrupted playback to the end of the content is more complex to guarantee. Conversely, with a low bitrate, it is easier to recover the missing video segments via the communication link.

[0155] The bandwidth estimation may also include information on possible interruptions of the communication link to the CDNs 110, typically during tunnels or uncovered areas. In this case, the pre-cached length may be at least as high as the maximum interruption (in time) of the communication link, in order to reduce the risks of a cut-off in the playback of the media content.

[0156] For illustrative purposes only, a simple example of determining the lengths of the start portions to be pre-hidden can be based on the following rules:

[0157] For scores between 0 and 1 (SI threshold), no track pre-caching.

[0158] For scores between 1 and 3 (threshold S3), pre-caching of the first 10% segments SD track media.

[0159] For scores between 3 and 5, pre-caching of the first 25% media segments of the SD track.

[0160] For scores between 5 and 7 (threshold S4), pre-caching of the first 25% media segments of the SD track and pre-caching of the first 10% segments of a high quality track (HD or FHD or UHD).

[0161] For scores between 7 and 9 (threshold S2), pre-caching of the first 25% media segments of the SD track and pre-caching of the first 25% segments of a high quality track (HD or FHD or UHD).

[0162] For scores between 9 and 10, pre-caching of the entire SD track and one (or more) high quality tracks (HD or FHD or UHD).

[0163] In a variant based on the duration to pre-cache, 10% can be replaced by 5 or 15 minutes to pre-load and 25% by 15 or 30 minutes to pre-cache.

[0164] Step 54 ([Fig.5]) is followed by the optional step 56 of adjusting the start portions to be preloaded, as determined in step 54.

[0165] This optional step may in particular depend on the train users 150 between stations G1 and G2 of two successive synchronization sessions. As indicated above, some media content may have been previously paused by passengers on the train. The playback (or pause) positions are retrieved and, for example, the most advanced per media content (possibly below a maximum advancement threshold) is obtained.

[0166] The most advanced playback position of a media content is taken into account to extend the length of the start portion to be pre-cached for this media content beyond this playback position, typically extended by the percentage (10% or 25%) or duration (5 min or 15 min) mentioned above.

[0167] Step 56 thus allows travelers to continue their reading already started, without interruption.

[0168] Optionally, this step 56 makes it possible to adjust lengths to be pre-loaded to data already in cache memory 1522 (from a previous synchronization session). Indeed, it may be beneficial to reduce the quantity of data to be pre-loaded in cache memory 1522 during a synchronization session.

[0169] For example, if a track is already pre-cached at 25% for a media content, the pre-caching may be kept unchanged even if step 54 may have determined that another track should be partially pre-cached.

[0170] At the end of step 56 (or step 54 in the absence of step 56), a pre-caching plan P is obtained which defines the media contents (and their qualities) concerned by a pre-caching and their media segments (tracks concerned and length of the start portions) which should be pre-cache in memory 1522.

[0171] Thus, in step 58, this pre-caching 1522 is carried out in accordance with plan P. This involves loading into cache memory 1522 the media segments corresponding to the determined start portions.

[0172] This step is typically carried out when train 150 is immobilized in the workshops before a journey or simply at the station (G1, G2 or G3).

[0173] The bandwidth available during train immobilization may be sufficient to pre-cache all desired media segments. This is illustrated by the pre-caching at station Gl in [Fig.4].

[0174] However, it may happen, for example in the event of a short stoppage in an intermediate station G2, that the synchronization session according to plan P2 is not finished when train 150 leaves. In this case, as still illustrated in [Fig.4], the synchronization session can continue during the start of the journey, using the communication link with the CDN 110, and / or continue at the next stop in an intermediate station, as long as a new synchronization session is not started.

[0175] Several policies for prioritizing media segments for their pre-loading in cache memory 1522 can be envisaged. These prioritization policies determine an ordered list of media segments according to priorities assigned to the media segments, and the pre-loading of the media segments in cache memory 1522 is then carried out by decreasing priority.

[0176] Priorities are therefore determined for the media segments to be pre-cached.

[0177] In a first embodiment, the media segments of a track can be assigned a priority based on the score of the media content. In the event of incomplete synchronization, the start of each media content with a high viewing probability is thus in cache memory 1522, guaranteeing possible reading of the media content by travelers.

[0178] For example, the priority may be equal to the score of the media content: the media segments of the high-scoring content are thus given higher priority for pre-loading into cache memory 1522.

[0179] In one embodiment, priority is given to media segments at the beginning of the track over subsequent ones. In this case, the priority may be based on the score of the corresponding media content and a function of the position of the media segment in the media content, typically decreasing with advancing position.

[0180] For example, a continuous, possibly linear, or stepped function can define the priority between a high priority (corresponding for example to the score of the media content) for the first segment of the start portion to be pre-loaded and a low priority (for example 0 or a percentage such as 50% of the high priority) for the last segment of the start portion to be pre-loaded.

[0181] In one embodiment, priority is given to loading the beginning portions of low quality tracks (SD track type) over the beginning portions of high quality tracks, for the same media content. Also, higher priorities are assigned to the media segments of the low quality tracks over the media segments of the high quality tracks.

[0182] This maximizes compatibility since low quality and compatible tracks will be pre-cached even if the sync session is not completed in time.

[0183] For example, all media segments of SD tracks are pre-cached before those of HD tracks, themselves before those of FHD and finally 4K (UHD) tracks.

[0184] In one embodiment, preference is given to simultaneous progressive loading of all the starting portions, possibly by track quality (SD, then HD, then FHD and 4K).

[0185] Typically, the beginning of each media content (or track) is pre-cached by progressively advancing the caching percentage of each media content. For example, the first percent of each SD track is loaded into cache 1522 before pre-loading the next percent, and so on. Of course, a step other than the percentage can be used, for example from 5% to 5% or from minute to minute or from media segment to media segment.

[0186] In the latter case, for example, the priority assigned to a media segment is a function of its position in the media content. For example, the first media segment of a track is assigned a maximum priority of 1, the second media segment a priority of 2, and so on.

[0187] Here too, it is a question of ensuring, in the event of incomplete synchronization, that the start of each media content with a high probability of viewing is in cache memory 1522, and that travelers will be able to read the start of the media content.

[0188] [Fig.7] illustrates, using a flowchart, steps of a streaming method in a system providing partial pre-caching of media content. These steps are implemented by the onboard cache server 152.

[0189] When starting the playback of a track of media content, the content player 199 retrieves the track manifest file listing the media segments to be retrieved, as described above. Thus, the streaming operations mainly consist of the player sending successive requests to the CDNs 110 for the retrieval of the media segments.

[0190] If playback is started at the beginning of the media content, the first media segments are requested. Pre-caching allows them to be quickly returned to the player 199.

[0191] If playback is started in an advanced position of the media content, the corresponding media segments are requested, which may or may not be pre-cached.

[0192] In step 70, the cache server 152 intercepts a unicast request from the player 199 to a CDN 110 to obtain a media segment.

[0193] The cache server 152 determines in a conventional manner whether it already has the requested media segment in cache memory.

[0194] If so, it provides the media segment in response to the unicast request, which is not forwarded to the CDN 110.

[0195] In the other case, the server 152 transmits the unicast request to the CDN 110, which returns the requested segment to the player 199, via the cache server

[0196] The provision of the media segment corresponds to step 72.

[0197] Furthermore, the cache server 152 determines whether this is new media content played by a traveler since the last synchronization session. This is the case if no unicast request has been received for this media content.

[0198] If this is the case, the cache server 152 triggers (step 74) the loading, via the communication link with the CDNs 110, of the missing media segments of the track currently being played.

[0199] The objective here is to anticipate the recovery of the media segments that will be necessary for the complete reading of the media content, without interruption.

[0200] Since a user may play media content and quickly decide not to watch it in full, in one embodiment, the triggering of the loading of missing media segments is performed after a confirmation delay, for example a minimum number of media segments provided to the same player 199.

[0201] Similarly, if the user(s) subsequently stops playing the media content, typically for a threshold duration (eg, 5 minutes), then the loading in progress of step 74 can be stopped, so as not to use the communication link to the CDNs 110 unnecessarily and not to unnecessarily occupy memory space in memory 1524.

[0202] In the optional step 76, the cache server 152 may also trigger (and therefore stop if necessary) the loading, via the communication link with the CDNs 110, of the missing media segments of another quality (than that currently being played) or of several (or even all) other qualities of the same media content. Typically, the cache server 152 may attempt to retrieve the media segments of the HD or 4K track when an SD track playback is launched, in order to offer a better viewing quality to the user.

[0203] [Fig.4] illustrates for example a user Ui who starts playing the media content Vi, triggering the loading, into memory 1524, of the missing media segments of the SD track currently being played but also of the media segments of the HD track. Thus, the player 199 can, after a while, switch to the HD track.

[0204] [Fig.3] illustrates the state of the memory after or during loading of these missing media segments. The media segments of the beginning portion of the media content have been pre-cached in cache memory 1522 allowing immediate reading of the beginning of the media content by the player 199. Then the media segments not initially pre-cached from the SD and HD tracks are progressively loaded into memory 1524.

[0205] [Fig.8] illustrates a hardware architecture for any equipment or device of the streaming system 100 of [Fig.l], including servers and user terminals.

[0206] The device 800 comprises a communication bus 801 to which are preferably connected:

[0207] - one or more central processing units 802, such as one or more processors CPU and / or one or more processors or GPU graphics cards and / or one or more microprocessors;

[0208] - a storage memory 803, of the ROM and / or hard disk and / or flash memory type, for the storage of computer programs intended to implement all or part of the operations described above;

[0209] - a random access memory 804, of the RAM or video RAM (VRAM) type, for storage executable code of computer programs as well as the registers adapted to record variables and parameters necessary for their execution;

[0210] - a communication interface 805 connected to a network 130, 140 or 160 in order to communicate with one or more other devices of the streaming system 100; and

[0211] - one or more I / O 806 inputs / outputs allowing a user or administrator to interact with computer programs, both in configuration and in operation. Typically, the inputs / outputs may include a screen serving as a graphical interface with the user and rendering video content, and / or a speaker to render audio content and / or a keyboard or any other pointing means allowing the user to select media content from an interactive catalog, to start playing selected media content, but also to define intentions for viewing media content in advance of a trip.

[0212] Preferably, the communication bus 801 provides communication and interoperability between the various elements included in the computing device 100 or connected thereto. The representation of the bus is not limiting and, in particular, the central unit can be used to communicate instructions to any element of the computing device 800 directly or by means of another element of the computing device.

[0213] The executable code stored in memory 803 may be received by means of the communication network, via the interface 805, in order to be stored there before execution. Alternatively, the executable code is not stored in non-volatile memory 803 but may be loaded into volatile memory 804 from a remote server via the communication network for direct execution. This is the case in particular for web applications (web apps).

[0214] The central unit 802 is preferably adapted to control and direct the execution of the instructions or parts of software code of the computer program(s). Upon power-up, the program(s) that are stored in non-volatile memory 803 or on the remote server are transferred / loaded into the RAM 804, which then contains the executable code of the program(s), as well as registers for storing the variables and parameters necessary for implementing the invention.

[0215] Of course, the present invention is not limited to the embodiments described above as examples; it extends to other variants. Other embodiments are possible.

[0216] For example, in one embodiment, all or part of the track manifest files of the media content available from the CDNs 110 are pre-loaded into the cache server 152. This arrangement makes it possible to provide the manifest files quickly when starting the playback of a media content, and thus reduce the latency time, for a low storage cost (the manifest files being small compared to the media data).

[0217] While reference is primarily made to VOD-type media content, the above explanations also apply to “live” content. In this case, a delay relative to live is applied so as to allow caching of the “live” segments on the embedded cache server 152 before their broadcast, and thus reduce the risk of cutoff.

[0218] Furthermore, while reference is mainly made to mobile environments such as public transport for which the quality of the communication link with external CDNs is likely to vary, other non-mobile collective environments, such as an airport, a train station or even a private residence may be concerned.

[0219] For example, a decoder or network attached storage (NAS) device acting as a cache server 152 may be provided to a user for their home, on which decoder / NAS early portions of media content are pre-cached. This makes it possible to optimize media playback in the event of a weak Internet connection (e.g. ADSL or satellite).

Claims

Claims

1. A system (100) for streaming media content, comprising a mobile environment (150) having a cache server (152) in which media content data available from a unicast content server (110) external to the mobile environment is pre-cached (1522), wherein the cache server (152) is configured to pre-cache only a beginning portion of one or more media content.

2. System (100) according to claim 1, wherein a pre-caching manager (153) is configured to obtain scores (S) associated with respective media contents and to control the pre-caching of a starting portion of each media content and whose length is a function of the associated score.

3. The system (100) of claim 2, wherein the length of the leading portion of a pre-cached media content corresponds to a percentage of said media content, determined based on the associated score.

4. The system (100) of claim 2, wherein the length of the start portion of a pre-cached media content corresponds to a duration of said media content, determined based on the associated score.

5. The system (100) of one of claims 2 to 4, wherein media content is available in a plurality of qualities, and the pre-caching manager (153) is configured to determine, based on the score associated with the media content, one or more of said qualities for which a starting portion is pre-cached.

6. The system (100) of claim 5, wherein a length of the start portion of a pre-cached quality is a function of the bitrate of the quality and the associated score.

7. System (100) according to one of claims 2 to 6, wherein a length of the start portion of a pre-cached media content is a function of at least one of: an estimate of an available bandwidth on a communication link between the mobile environment and the external unicast content server, an available cache storage space, and users (Ui) of the mobile environment between two synchronization sessions (Gl, G2, G3) of the cache memory (1522) according to two separate plans (PI, P2, P3) for pre-caching media content.

8. System (100) according to one of claims 2 to 7, in which the scores associated with the media contents are a function of at least one of: users (Ui) of the mobile environment between two synchronization sessions (Gl, G2, G3) of the cache memory according to two distinct plans (PI, P2, P3) of pre-caching of media contents, and a schedule between two synchronization sessions of the cache memory according to two distinct plans of pre-caching of media contents.

9. The system (100) of one of claims 1 to 8, wherein the cache server (152) is configured to obtain an ordered list of media segments comprising the start portions according to priorities assigned to the media segments, and to pre-cache the media segments in descending priority.

10. The system (100) of one of claims 1 to 9, wherein the cache server (152) is configured to pre-cache starting portions of a plurality of media contents by simultaneously progressively loading their starting portions.

11. The system (100) of one of claims 1 to 10, wherein the cache server (152) is configured to pre-cache starting portions of a plurality of media contents by prioritizing a starting portion of a low quality of a media content over a starting portion of a high quality of the same media content.

12. The system (100) of one of claims 1 to 10, wherein the cache server (152) is configured to load, via a communication link between the mobile environment and the external unicast content server, missing portions of media content, in response to initiating playback of the media content in the mobile environment.

13. The system (100) of claim 11, wherein the missing portions of the media content include media segments missing media segments of one quality being played and media segments of at least one other quality of the same media content.

14. Method for streaming media content in a mobile environment (150), comprising a step (58) of pre-caching (1522), in a cache server (152) of the mobile environment, media content data available from a unicast content distribution server (110) external to the mobile environment, wherein the method pre-caching comprises pre-caching only a starting portion of one or more media contents.

15. A non-transitory recording medium readable by a computer on which is recorded a program for implementing the method according to claim 14, when this program is executed by a processor.

Images