Adaptive video streaming in a shared transport environment

Abstract

To centrally control the quality of media content played by onboard players (199) in a vehicle (150), an adaptive streaming system comprises a steering server (120, 153) configured to modify, as a function of a current target quality (Q'), the ordered list of path identifiers (PATHWAY-ID) of the Steering Manifest file (126) between several identifiers respectively associated with sets of tracks of the same media content, the sets having different maximum qualities. When the conditions do not allow the recovery of the media segments of a high quality track, the Steering Manifest file is modified to prioritize a PATHWAY-ID corresponding to lower quality tracks. The player is thus forced to switch to one of these tracks. [Fig. 1]

Description

Title of the invention: Adaptive video streaming in a shared transport 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 traditionally 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 from one quality to another, for example when the connection to the CDN fluctuates. 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 or CDN is maintained at good quality throughout the streaming. This link generally passes through the Internet. However, the Internet connection, of fluctuating and reduced quality, is also shared by a growing number of users, and for multiple uses. This results in a generally degraded Internet connection for an individual user, particularly for applications requiring intensive and permanent data usage.

[0007] If the quality of the connection decreases, the content player is inclined to switch to a lower quality track as proposed in the description file.

[0008] One area in which communication links frequently fluctuate over time is 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.

[0009] This is why it is planned to equip these vehicles with one (or more) on-board cache servers to store the content locally and thus allow passengers to access it more easily. A CDN "on-board" in the vehicle is therefore instantiated, which manages the cache server and responds to requests from content players to offer the streaming service inside the vehicle. To do this, all or part of the tracks in the descriptive file retrieved by the player indicate a URL of the on-board CDN and no longer of a traditional external CDN. The on-board CDN is therefore exposed locally to the content players present in the vehicle.

[0010] Content catalogs can be large and the storage capacity of the embedded cache server can be limited, particularly for cost reasons. Also, only part of the catalog is generally stored locally in the embedded server, typically content with high potential or high audience. It is also common for certain content to have only part of its tracks (and therefore the available qualities) stored locally in the embedded cache server, typically low-quality tracks.

[0011] Given the large number of users who may frequent a public transport environment, it is important to maintain access to a larger part of the catalog (typically the entirety) in all or part of the qualities, for example a subset comprising qualities compatible with all players to the extent that certain players are only compatible with certain qualities (particularly in terms of resolution). Also, the descriptive file retains the tracks for content and qualities not stored locally in the onboard CDN. A content player operating in the vehicle may therefore find itself requesting the onboard CDN to obtain segments of a track not available locally.

[0012] The on-board CDN can then use a communication link from the vehicle to the external CDN(s) (typically via a mobile network link) to retrieve the missing segments.

[0013] The operation of this streaming system is not, however, satisfactory. Indeed, since the upstream communication link to the external CDNs is subject to fluctuations, it does not guarantee the timely recovery of requested segments that are not available locally. This disadvantage is accentuated with the number of simultaneous users in the vehicle because each player tends to request the best quality compatible track, whether it is available locally or not. The communication link to the external CDNs can quickly become saturated.

[0014] Furthermore, on a large catalog of content, the consumption distribution curve is very spread out, requiring a very large storage space so that the external CDNs are used as little as possible.

[0015] This then poses a difficulty in synchronizing the on-board CDN (the quantity of data to be synchronized is very large, going beyond what can sometimes be technically feasible) and risks of waste given the number of synchronized contents which will never be read in the public transport environment.

[0016] There is therefore a need for an improved streaming system that offers better control over content consumption to reduce the risk of saturation of the upstream communication link, while allowing content readers to benefit from a wide or even complete range of available tracks, and this from an extensive and rapidly changing catalog. Such a system would be suitable for an on-board streaming service in a collective environment (airport, train station, etc.), and in particular in a collective transport environment such as a vehicle (train, plane, boat / ferry, bus, etc.). Statement of the invention

[0017] The inventors have found that the Content Steering mechanism developed by Apple (https: / / developer.apple.com / streaming / HLSContentSteeringSpecification.pdf) can be cleverly hijacked to move some of the track selection intelligence (qualities) from the content player to the servers providing the streaming service.

[0018] The Content Steering mechanism was developed to allow clients to be assigned to different servers or CDNs in order to better distribute the load between servers, particularly in the event of high traffic. A steering manifest file or "Steering manifest" is obtained by content readers from a dedicated server for requested content.

[0019] In practice, the control manifest file defines an order of priority between different "pathway IDs" (path identifiers) which are entered at the level of each track of the content descriptive manifest file, the tracks indicating URLs to various servers. A player is then forced to switch between only the tracks assigned the highest priority pathway ID.

[0020] The reader therefore moves from one "pathway" to the next, according to the order of priorities in the control manifest file when all the tracks of a used path trigger reading errors. The reader thus switches from an inaccessible track corresponding to a URL on a server to another operational track targeting the URL of another server. The set of tracks in the descriptive file to which the client is authorized to move is then limited to those assigned the pathway ID selected by the reader.

[0021] Noting that the control manifest file allows the client to be directed towards particular tracks to the detriment of others, the inventors considered using the paths, no longer to direct the readers towards particular servers, but to control the tracks, and therefore the qualities - in particular maximum - to which the readers can claim. Also, the control manifest file can be dynamically modified to provide a path limiting a maximum quality (for example a single track of low SD quality). As a consequence, the readers engaged on the content concerned are forced to switch to one of the tracks corresponding to the modified path, offering for example a reduced maximum quality (track). A control of the quality of the contents read by the readers is thus deported outside of the latter.

[0022] Dynamic control can be obtained by dynamically adjusting the control manifest file according to the conditions of use of the service (highly requested contents) and according to the network conditions of the communication link (difficulty or impossibility of loading missing segments on the fly) to favor or force the reading of certain tracks available in the cache server.

[0023] For this purpose, there is proposed an adaptive streaming system for media content available in a plurality of qualities, comprising a control server configured to transmit, at each request of a content player, a control manifest file defining an ordered list of one or more path identifiers associated with descriptive tracks of said media content according to several qualities to prioritize access to the tracks by the content player according to said order of the list, each track referencing a URL where to access the media segments of the corresponding quality, characterized in that the control server is configured to modify, according to a current target quality, the ordered list of path identifiers for a next control manifest file to be transmitted to the content player.

[0024] The system thus operates a dynamic control of the qualities accessible by the content readers, and in particular of a maximum accessible quality, by activating or deactivating the corresponding CDNs (via their path identifier). This dynamic control is carried out according to a desired target quality which fluctuates over time, for example with the arrival of new customers and / or the variable use and quality of the communication link to the external CDNs.

[0025] Since lower quality tracks consume less bandwidth, dynamic control towards a lower target quality can reduce the demand on the communication link and increase the pre-caching depth (amount of data stored in the onboard cache server). This improves the user experience.

[0026] Clients can thus be forced to play the same tracks, typically those available on the cache server, or a limited number of tracks, for example reducing the burden on the embedded CDN to load, in cache, the missing segments of a track that a player would have otherwise selected. This makes it possible, for example, to maximize uninterrupted playback of media content by players while maximizing the quality played, depending on the state of the cache server, the use of the service (for example the number of clients) and the connectivity with external CDNs.

[0027] Correlatively, there is also proposed a method for adaptive streaming of media content available in a plurality of qualities, comprising the transmission, by a control server at each request of a content player, of a control manifest file defining an ordered list of one or more path identifiers associated with descriptive tracks of said media content according to several qualities to prioritize access to the tracks by the content player according to said order of the list, each track referencing a URL where to access the media segments of the corresponding quality, characterized in that it comprises an additional step, by the control server, of modification, as a function of a current target quality, of the ordered list path identifiers for an upcoming driver manifest file to be passed to the content reader.

[0028] 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.

[0029] In one embodiment, different path identifiers are associated with different sets (or groups) of one or more tracks of the same media content, each set having a different maximum quality, and modifying the ordered list of path identifiers comprises (1) selecting one of the path identifiers in function of the maximum qualities of the associated sets and the current target quality, and (2) the prioritization of the path identifier selected in said ordered list. Management of path identifiers by sets having a different maximum quality simplifies the operations of modifying the ordered list, in particular to limit the maximum quality accessible by readers to said current target quality.

[0030] In one embodiment, two tracks of the same quality in two different games reference the same URL or the same media file (via, for example, two URLs targeting the same physical file), and this is contrary to the conventional use of the Steering Manifest. It is therefore the same track that is present in both games. This configuration makes it possible to use the same media file for two Pathway IDs, and consequently to limit the use of storage resources. This configuration is therefore particularly well suited to a streaming service embedded in a vehicle. The same track or the same file (for example, the one with the lowest quality) can populate a large number of concurrent games.

[0031] In one embodiment, a first set having a first maximum quality comprises the track(s) of a second set and an additional track of quality equal to the first maximum quality. In this configuration, the dynamic adjustment according to the invention makes it possible to delete or add only the additional track of maximum quality when the target quality varies from one maximum quality to the next, ensuring that the other tracks of lower quality are always available to the players.

[0032] For example, n sets Jk of maximum quality Qk comprise k tracks of quality Qi to Qk, with k an integer from 1 to n, and Qi <Qj pour i<j. A titre d’illustration, un premier jeu Ji est formé de la piste Qi (par exemple SD pour « small définition » ou « faible définition »), un deuxième jeu J2 des pistes Qi et Q2 (par exemple SD et HD Ready), un troisième jeu J3 des pistes Qb Q2 et Q3 (par exemple SD, HD Ready et full HD) et un quatrième J4 jeu des pistes Qh Q2, Q3 et Q4 (par exemple SD, HD Ready, full HD et UHD).

[0033] Of course, other configurations can be contemplated such as sets J'k comprising only the tracks Qi and Qk. It is also possible to combine sets Jk and J'k to concentrate the cache on certain tracks (those of J'k).

[0034] In these cases, the tracks of quality Q; can reference the same URL or the same media file in the n games Jk (or even J'k). This makes it possible in particular not to multiply the media files on the servers for the same content quality. This configuration is therefore particularly well suited to a streaming service embedded in a vehicle where local storage capacities are limited.

[0035] In one embodiment, said games having different maximum qualities only comprise tracks referencing a URL of a cache server embedded in a vehicle, and at least one additional set of tracks, associated with a distinct path identifier, references a URL of a unicast streaming server for content external to the vehicle. This arrangement promotes media consumption via the embedded cache server, while ensuring access to external content for users when the cache server (and therefore the embedded streaming service) malfunctions or its connection with the embedded system is lost or the user leaves the vehicle.

[0036] In one embodiment, the descriptive tracks referencing a URL of the embedded cache server are included in a content descriptive manifest file transmitted by a manifest server and / or are generated by the content player by cloning (or "pathway cloning") one or more paths existing in a content manifest file transmitted by the manifest server. This also means that some of these tracks can be included directly in the file while others are generated by cloning.

[0037] In one embodiment, the ordered list of path identifiers is modified to include, in order of priority, a single path identifier assigned to a set of tracks referencing a URL of a cache server embedded in a vehicle and selected according to the current target quality, then one or more path identifiers assigned to one or more additional sets of tracks referencing a URL of a content server external to the vehicle. The other local track sets (with URL of the embedded cache server), in particular of higher maximum quality, are then deactivated, thus ensuring that the readers cannot request tracks of quality higher than the target quality, from the embedded server.

[0038] In one embodiment, the URLs reference a cache server embedded in a vehicle. The invention is particularly applicable to a streaming service embedded in a vehicle.

[0039] According to one embodiment, the embedded cache server is a cache server temporarily storing one or more segments of the media content obtained from an external unicast content distribution server. The embedded server then serves as a proxy for the media segments.

[0040] According to one embodiment, the steering server is external to the vehicle and receives, from a management agent on board the vehicle, a message indicating said current target quality, for example a command to modify the ordered list of path identifiers. This arrangement makes it possible to keep the Content Steering mechanism (or equivalent) active even if the user moves away from the vehicle.

[0041] According to another embodiment, the control server is embedded in the vehicle, descriptive tracks of said media content according to several qualities are included in a descriptive manifest file of content transmitted by an external manifest server to the vehicle, and the descriptive content manifest file references the on-board control server as the priority server for obtaining a media content control manifest file and references a second control server, external to the vehicle, as a fallback server for obtaining a media content control manifest file.

[0042] Unlike the conventional use of control manifest files, two alternative control servers are referenced here. This configuration avoids the interruption of refreshing the control manifest file for the content player, for example, when the user leaves the vehicle. In addition, it allows the maximum quality accessible by the players present in the vehicle to be adapted locally (to the vehicle), according to conditions specific to each vehicle.

[0043] In a variant offering the same advantage, the control server is embedded in the vehicle and is exposed locally with a domain name identical to that of a second control server, external to the vehicle. A local DNS or proxy of the vehicle then sends any reader requesting the domain name to the embedded control server. On the other hand, as soon as the reader leaves the vehicle, the second control server is requested, via the same domain name. The second server can therefore operate as a fallback server to obtain a control manifest file. This also avoids the interruption of refreshing the control manifest file.

[0044] In one embodiment, the control server or a management agent onboard the vehicle is configured to determine the current target quality based on a status of availability of the tracks on a cache server onboard the vehicle and / or a bandwidth available on a communication link between the vehicle and an external content server. The availability status may relate to the total availability of the media file (all the segments) on the server or the availability of at least part of the media segments. Modifying the control manifest file is thus made simpler and more precise due to real-time (and better) knowledge of the status of the cache server (stored tracks, current caching status for certain tracks) and the status of the communication link to the outside (interruption, saturation, available bandwidth).

[0045] For example, the server or agent can determine whether the available bandwidth allows to recover, on the embedded cache server, all the missing segments of a current target quality (i.e., during streaming) of the media content taking into account a current playback position of the media content and without catching up with the end of the cache, and in the event of a negative determination, reduce the current target quality, for example towards the quality of the media content allowing to recover all of its missing segments. Symmetrically, the server or agent can determine whether the available bandwidth allows to recover, on the embedded cache server, all the missing segments of a higher quality (in terms of bitrate / resolution) than the currently playing quality of the media content given a current playing position of the media content and without catching up with the end of the cache, and in case of positive determination, increase the current target quality towards the higher quality.

[0046] As another example, it may involve detecting that a new track is cached in the embedded cache server, and using the quality of the new track as the current target quality. This arrangement allows clients (content players) to upgrade in quality, without altering the communication link to external servers used for caching other tracks or media content for example.

[0047] As another example, this may involve detecting the removal of a track from the embedded cache server (e.g., to free up memory space for other content to be cached), and using the best available quality for the remaining media content on the embedded cache server as the current target quality. This arrangement allows forcing clients to leave a track removed from the cache.

[0048] As yet another example, it may involve determining an available bandwidth for the media content in a communication link between the vehicle and the on-board cache server, determining a track with the best throughput (throughput indicated in the descriptive manifest file) under the determined bandwidth, and using the quality associated with the determined track as the current target quality. This arrangement makes it possible to dynamically adjust the best quality for clients even in the absence of caching of the content on a cache server. Such an arrangement applies in particular to “live” content for which pre-caching is not possible.

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

[0050] 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.

[0051] 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.

[0052] 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 a embodiment combining software and hardware aspects which may all 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.

[0053] 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

[0054] 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:

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

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

[0057] [Fig.2a] illustrates an extension of the file of [Fig.2] to tracks of a local CDN ac transferable on a server embedded in a vehicle;

[0058] [Fig.2b] illustrates a further extension of the file of [Fig.2] and [Fig.2a] to tracks from other local virtual CDNs accessible on the embedded server;

[0059] [Fig.3] illustrates an example of a steering manifest file or “steering manifest” referencing external CDNs;

[0060] [Fig.3a] illustrates “steering cloning” or cloning of tracks using a file pilot manifest;

[0061] [Fig.3b] illustrates a variant of “steering cloning”;

[0062] [Fig.4a][Fig.4b][Fig.4c][Fig.4d] illustrate different control manifest files each referencing a local virtual CDN and / or a single external CDN to limit maximum playback quality;

[0063] [Fig.5] schematically illustrates steps of operations of the streaming system of [Fig.l];

[0064] [Fig.6] schematically illustrates the operating steps of a content reader in the streaming system of [Fig.l];

[0065] [Fig.7] schematically illustrates steps for monitoring and updating the current target quality of a media content, to control the activated virtual CDN; and

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

[0067] [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.

[0068] 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.

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

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

[0071] Typically, an initial media content is encoded in 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. 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.

[0072] 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, frame rate, codec, audio language, subtitle, etc.

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

[0074] 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). Alternatively, they are generated (encoded) on the fly, typically during live events, in which case they are stored under these names temporarily in the CDN servers. A server can store both segments permanently and segments temporarily.

[0075] 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.

[0076] For live broadcasting, the created media segments may be stored for a limited duration allowing the user to "roll back". This rollback mechanism is also known as "startover".

[0077] The remainder of the description focuses primarily on initial media content encoded at the above three or four resolutions. Of course, similar considerations apply to all media content available in the system 100, regardless of the criteria (resolution, quality, etc.) for creating the corresponding 1 to N media files.

[0078] It should be noted, furthermore, that while 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.

[0079] The server(s) 120 store the description files 125 of the various contents stored on the CDNs 110 and accessible to users. These servers performing the function of providing the description files 125 are called descriptive file servers or “manifests”.

[0080] As is known, 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 typically generated once for a VOD media content. However, it can be generated dynamically to adapt the qualities to each user device and / or to network conditions. That of live filmed events is generated dynamically.

[0081] 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 that 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, describing the media segments constituting the media file.

[0082] 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”.

[0083] 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_1100.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.

[0084] Each alternative track in the descriptive file 200 therefore corresponds to a second descriptive content file “m3u8”, or “track descriptive file” or “media playlist”, which indicates the URL web addresses where the content player 199 obtains, by unicast requests, the different media segments constituting the corresponding 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.

[0085] 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 format DASH, there is no track description file; the MPD root file merges, into a single file, both the HLS master playlist file and the multiple corresponding HLS media playlist files. URLs can be absolute addresses in case the media segments are stored on a different server than the one serving the MPD root file.

[0086] 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.

[0087] The server(s) 120 also store descriptive steering files or “Content Steering” 126 for the media content. These servers performing the function of providing the steering files 126 are called steering servers.

[0088] Manifest and control servers can be implemented within the same physical server 120 or a group of the same physical servers. Alternatively, the manifest server and control server are implemented within separate physical servers. For the remainder of this document, generic reference is made to the server 120, the function used (manifest or control) of which will become apparent from the description.

[0089] The Content Steering mechanism is described for example in the file https: / / developer.apple.com / streaming / HLSContentSteeringSpecification.pdf. It allows, among other things, to prioritize access to one CDN 110 rather than another.

[0090] A Content Steering file 126 is retrieved by the content player 199 at the URL indicated in the EXT-X-CONTENT-STEERING tag descriptive element (210) of the root descriptive file 200 in the HLS illustrated case. The Content Steering file 126 is specific to the multimedia content, the one identified by the 'video' parameter (video=00012 in the example of the Figure).

[0091] The Content Steering file 126 operates in collaboration with an attribute called “PATHWAY-ID” indicated at the track level of the root descriptive file 200 in order to prioritize tracks (those bearing a specific PATHWAY-ID) in relation to other tracks, and indirectly to prioritize a CDN 110 (“external.server.com” in the example of [Fig.2]) rather than other CDNs. In other words, the “PATHWAY-ID” attribute is nothing other than an attribute for prioritizing tracks, and therefore indirectly paths to the CDNs.

[0092] To illustrate this operation, the descriptive file 200 also includes a track 233 similar to Full HD track 232, except that the track description file (and media segments) is stored on another CDN's server, here "external2.server.com". Similarly, tracks 233' define the same audio and subtitle tracks, available on the other CDN "external2.server.com". Tracks 230-232 are assigned the attribute PATHWAY-ID = CDN-A 241 while tracks 233 and 233' are assigned the attribute PATHWAY-ID = CDN-B 242.

[0093] [Fig.3] illustrates an example of a Content Steering file 126, in which the ordered list of path identifiers 300 defines the order of priority of the CDNs, here CDN-A having priority over CDN-B.

[0094] Also, when, as illustrated in [Fig.2], tracks are declared with different PATHWAY-ID attributes 241, 242, one equal to “CDN-A” and the other to “CDN-B”, the user content player 199 exploiting this root descriptive file 200 is authorized to switch between the “CDN-A” tracks only (tracks 220, 221, 230, 231, 232 of the Figure), and to move to the “CDN-B” tracks (tracks 233, 233') only if no “CDN-A” track is available. The content player 199 therefore requests, initially, only the “external.server.com” server.

[0095] In the opposite case where the ordered list 300 defines CDN-B as a priority over CDN-A, the example of [Fig.2] first imposes the use of tracks 233 and 233', on the reader 199.

[0096] Note that in the absence of a Content Steering file 126 (not available or not yet obtained or loaded), an attribute is defined by default as priority, at the end of the descriptive element 210. In the example, “CDN-A” is the default attribute of the priority tracks. Alternatively (e.g. in the absence of such a default attribute, or if it is not present in alternative tracks), the order of the tracks in the root descriptive file 200 can be taken as the default priority order.

[0097] The Content Steering file 126 transmitted to the players varies over time, for example to direct certain user video players to one CDN 110 rather than another, and thus balance the load between CDNs. The Content Steering file 126 is reloaded by the user content player 199 (by successive requests to the server 120) periodically, every TTL seconds as indicated in the file 126. In the example of [Fig. 3], TTL is set to 30.

[0098] The same Content Steering file format 126 is used in the HLS protocol and the DASH protocol, only the PATHWAY-ID attributes are defined in different locations in the content description files 125. In DASH, it can be defined in each tag <baseurl>specifying the base URL of a CDN, as proposed in the DASH contribution “Content Steering for DASH”, version 0.9.0 dated July 10, 2022, available at https: / / dashif.org / docs / DASH-IF-CTS-OOXX-Content-Steering-Community-Review.pd f. Again, the PATHWAY-ID allows different paths to be prioritized for content.

[0099] Returning to [Fig.l], CDNs 110 are classic infrastructures based on HTTP, typically standard DASH or HLS secure servers (therefore HTTPs). They carry out unicast broadcasting / streaming of content, that is to say they deliver media segments upon request from user content readers.

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

[0101] [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.

[0102] As illustrated in the Figure, the train 150 comprises a streaming agent 151, a media content cache server 152 and one or more user terminals equipped with content players 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 Wifi (trade name) 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.

[0103] 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.

[0104] A user terminal can take the form of a smartphone, a tablet, a laptop or desktop computer, a connected object (television, watch, camera, connected 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, but also continuously if the telephone decides to retrieve certain files via cellular network). Such a terminal therefore has the possibility of switching from one network (local) to another (mobile).

[0105] Access to the streaming service by 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 that runs 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, 126 then the media segments).

[0106] The cache server 152 is, like the CDNs 110, a local streaming server, i.e. a unicast broadcast server for media segments corresponding to the locally accessible content. To do this, it instantiates a local web server to respond to unicast requests from the content players 199. The local web server can be a simple http server or be set up as an HTTPs server, i.e. a secure one, ideally HTTPs / 2 or HTTPs / 3 with TLS 1.3 or later.

[0107] Locally accessible content corresponds to media content offered by external CDNs 110, even if other content may be provided for local use only.

[0108] Locally available tracks may thus correspond to all or part of the tracks available on the external CDNs 110, for a given media content. The local web server therefore stores track-descriptive manifest files corresponding to the locally available tracks, and also stores media segments of these tracks.

[0109] [Fig.2a] illustrates an example of a continuation of the root manifest file 200 of [Fig.2] to declare locally available tracks on the train.

[0110] In this example, the local web server of the cache server 152 is exposed on the local network with a dedicated domain name, here "local.server.com" which can be publicly exposed or not be publicly exposed. The use of a domain name allows identical deployment of qualities in several trains by a single declaration of the tracks in the root manifest file 200 (all trains instantiate a local web server with the same dedicated domain name). As an alternative to a fully qualified domain name (FQDN), an IP address can be used, which requires a declaration of each track, specific to each train in the root manifest file 200.

[0111] The exposure of the web server under this dedicated domain name, within the local network, is made possible by its registration (in association with the local IP address of the cache server 152) in a local DNS server.

[0112] In the example of [Fig.2a], the audio and subtitle tracks are taken locally as well as three video tracks, the SD track (416x234) whose track manifest file is “wl_v_avc_0_234_416_0_190.m3u8” stored on the local web server “local.server.com”, the HD track (1280x720) corresponding to track 231 and whose track manifest file “wl_v_avc_10_720_1280_0_3400.m3u8” is also stored on the same local server, and the Full HD track (1920x1080) corresponding to track 232 and whose track manifest file "wl_v_avc_20_1080_1920_0_4500.m3u8" is also stored on the same server. Of course, another number of tracks can be downloaded locally.

[0113] For simplicity of implementation, the track manifest files of the external CDNs 110 and the local ones are identical (thanks to relative URLs), so that the media segments to be provided are also the same. This allows the cache server 152 to retrieve the track manifest files and media segments from the external CDNs 110. Furthermore, if absolute URLs are used, it is simply sufficient to change the domain name of the server in the track manifest files.

[0114] In this example, it is the root manifest file 200 that references the cache server, for obtaining the track manifest files. In a variant, the track manifest files can also be stored on the external server 120. In this case, the root manifest file 200 can use relative URLs for obtaining the track manifest files on the same server 120, and it is the track manifest files that reference the cache server 152 (absolute URL) for obtaining the media segments on the cache server. The description below refers to the first case, but it applies similarly to the variant. The first case applies particularly well to live content while the variant is suitable for on-demand content.

[0115] This variant also corresponds to the case of DASH where the single MPD manifest can therefore reference the cache server 152 (absolute URL) to obtain the media segments on the cache server. For “live” content in DASH, it can be provided that the MPD manifest is stored on the cache server 152 and that the player 199 thus requests the cache server 152 to obtain the multiple successive MPDs describing the live content.

[0116] As a variant of these examples where the descriptive tracks of a media content according to several qualities are included in the descriptive content manifest file 125, they can be generated by the user content player 199 by cloning (or “pathway cloning”) of one or more paths existing in the content manifest file 125 transmitted by the manifest server 120. Pathway cloning is a function declared in the control file 126, which is based on the PATHWAY-ID of the tracks to perform a partial cloning of the track URLs.

[0117] [Fig.3a] illustrates the cloning of all the tracks of a PATHWAY-ID (here “CDN-A”) into new tracks whose server name is replaced with “local.server.com”. The created tracks are then assigned a new PATHWAY-ID (here “CDN-1”) to allow separate prioritization.

[0118] [Fig.3b] illustrates a variant of cloning a part of the tracks using identifiers entered at the track level in the description manifest file 125 (identifiers not shown in [Fig.2]). A STABLE-RENDITION-ID identifier can be entered for tracks tagged "EXT-X-MEDIA" (audio tracks and subtitles). Similarly, a STABLE-VARIANT-ID can be entered for tracks tagged "EXT-X-STREAM-INF" (video tracks). Different ID values ​​can then be used to distinguish between tracks.

[0119] The control manifest file of [Fig.3b] provides for example the replacement described above for [Fig.3a] (to a server “external2.server.com” in the example of the Figure) with the exception of tracks with particular identifiers for which another URL change is proposed. In the example of the figure for example, the video tracks (from “CDN-A”) whose STABLE-VARIANT-ID is “video-SD-HD-FHD” have their URL modified to the “new URL 1” as defined in the PER-VARIANT-URIS metadata. Other values ​​of the identifier allow other replacement URLs to be provided if necessary. Similarly, the audio or subtitle tracks (from “CDN-A”) whose STABLE-RENDITION-ID is “audio-FR” have their URL modified to the “new URL 2” as defined in the PER-RENDITION-URIS metadata. Other values ​​in the identifier allow for alternative URLs to be provided if necessary.Multiple values ​​for the same ID can be declared to clone multiple tracks differently.

[0120] The use of the control manifest file ultimately allows the prioritization of external tracks (“CDN-A”) or local tracks (“CDN-1”). For example, the file in [Fig.4b] requires the content player 199 wishing to access the media content concerned (video=00012) to navigate between the “CDN-1” tracks provided by the local CDN “local.server.com”. When these local tracks are not accessible (for example, the user leaves the train), the content player 199 is authorized to switch to the “CDN-A” tracks of the external CDN.

[0121] Given the limited memory space in the train 150, it is generally not feasible to store all the media segments of a complete catalog of multimedia content.

[0122] Some media segments may be preloaded into the cache server 152, typically at the station before the train departs. In one embodiment, the media segments of an SD track of a media content are preloaded to ensure access to the media content. In one embodiment, the media segments of a 4K, FHD or HD track of a media content to be voted on are preloaded to ensure a satisfactory user experience.

[0123] Some media segments are loaded on demand (on the fly), for example during a train journey when a content player 199 requests playback or with live content. For this purpose, the streaming agent 151 is responsible for retrieving the remaining media segments of a track currently being played, from the external CDN(s), via the communication network 130 or 140. The retrieved segments are stored in the cache server 152 for provision to the content player 199. Preferably, the streaming agent 151 works to preload all missing media segments of a media content being played.

[0124] The cache server 152 then cooperates with the streaming agent 151 to retrieve, via the network 130 and / or the mobile network 140 (generally the train is equipped with a communication interface with the mobile network, itself connected to the Internet network), the requested video segments.

[0125] This upstream communication link to the external CDNs 110 is not stable over the train's path, sometimes experiencing cuts (e.g. tunnel). The cache server 152 may not be able to retrieve a media segment in time, i.e. before reaching the end of the cache, and provide it to the content player 199 requesting it. The content player 199 controls, in this case, a drop in quality by selecting another track.

[0126] Since each content player controls the quality of the media content at its own level, the multiplication of simultaneous users using varied qualities risks saturating the communication link, which is detrimental to the user experience.

[0127] [Fig.2b] illustrates the creation of several virtual local CDNs to centrally control the (maximum) quality at the content players 199. The tracks in this figure complement those of [Fig.2] (“CDN-A” to the external CDNs 110, the “CDN-B” tracks can be omitted if necessary) and [Fig.2a] (“CDN-1” to the embedded server 152) for a given media content. Several media contents (see all those in the catalog) can be affected by this approach.

[0128] These local CDNs (i.e., with embedded server URL) are called “virtual” because they do not implement other servers than the existing one, but simulate several servers in order to offer different availability of tracks for the same media content.

[0129] The control between these different local virtual CDNs is carried out using the control manifest file 126. In particular, the manifest server 120 is configured to modify, according to a current target quality, the ordered list of path identifiers 300 for a next control manifest file to be transmitted to the content player. For example, by putting first in this list 300 a local virtual CDN whose maximum quality is limited, the content players 199 playing the media content concerned are forced locally to a limited maximum quality, for example that of tracks preloaded in the cache server 152 to reduce the load on the communication link.

[0130] In the example in the Figure, three local virtual CDNs are instantiated through the PATHWAY-ID: CDN-1, CDN-2, CDN-3. Each virtual CDN corresponds to a different maximum quality: FHD for CDN-1, HD for CDN-2 and SD for CDN-3 in the example. Any other number can be considered. In particular, as many local virtual CDNs can be instantiated as there are possible quality combinations depending on the reading situations.

[0131] For example, on media content that is fully cached across all of its qualities (4K and / or FHD, HD, SD), a local virtual CDN-1 contains all qualities, which is enabled by default, and a CDN-2 contains the SD and HD tracks, which is enabled to reduce the maximum quality accessible to content players 199 to HD quality. Such activation makes it possible to force players 199 to exit 4K / FHD playback and free the 4K or FHD cache for other content.

[0132] On fully cached, but SD-only media content, a local CDN-3 contains the SD track only, enabled by default, and a local CDN-2 contains both the SD track and the HD track, which is enabled when the HD track becomes fully available (agent 151 taking care of caching it in server 152 during the journey).

[0133] On media content with partial cache (for example 5% of the start loaded) in SD and HD or not yet pre-cached in the server 152, a local CDN-4 contains the SD track only, activated by default, a local CDN-3 contains the SD track and the HD track, activated when the HD track becomes fully available or when the throughput of the communication link allows switching to the HD track without the playback catching up with the end of the cache (segments which are progressively pre-loaded in the cache server 152), an optional local CDN-2 contains the SD, HD and FHD tracks, activated when the FHD track becomes fully available or when the throughput of the communication link allows switching to the FHD track without the playback catching up with the end of the cache, and an optional local CDN-1 contains the SD, HD, FHD and 4K tracks,activated when the 4K track becomes fully available or when the communication link speed allows switching to the 4K track without playback catching up with the end of the cache. Note that CDN-1 or CDN-2 or CDN-3 can be disabled if the communication link speed reduces such that playback is likely to catch up with the end of the cache, leading to reactivating a previous CDN (CDN-2 or CDN-3 or CDN-4).

[0134] Generally speaking, local virtual CDNs, i.e., different path identifiers, are associated with different sets or groups of one or more tracks of the same media content, each set having a different maximum quality. Each group of a local virtual CDN exposes a set of qualities. These quality groups may overlap from one group to another.

[0135] In the example of the Figure, two tracks of the same quality in two different sets (different virtual CDNs) reference the same URL or the same media file, which allows the media segments to be stored only once in the cache server 152.

[0136] Similarly, a first set having a first maximum quality includes the track(s) of a second set and an additional track of quality equal to the first maximum quality. In the example of the Figure, CDN-2 includes the SD track of CDN-3 plus the HD track defining its maximum quality. Similarly, CDN-1 includes the SD and HD tracks of CDN-2 plus the FHD track defining its maximum quality.

[0137] We thus define a set of local virtual CDNs incrementally, by adding the track defining the maximum quality of each CDN: n sets Jk of maximum quality Qk are created, which include k tracks of quality Qi to Qk, with k an integer from 1 to n, and Qi <qj pour i<j.

[0138] Alternatively, it is possible to omit certain intermediate quality tracks, in order to limit segment preloads in the cache server 152. For example, CDN-1 may include the UHD (4K) and SD tracks, CDN-2 the FHD and SD tracks, CDN-3 the HD and SD tracks, and CDN-4 the only SD track. In this case, each set J'k includes only the tracks Qi and Qk.

[0139] In these examples, a low quality SD track is systematically referenced in each of the local virtual CDNs. This ensures compatibility with all content players 199, some of which are not able to play high quality formats. The presence of intermediate quality tracks provides fine adjustment of the rendered quality, and therefore a better user experience.

[0140] Note that the presence of the CDN-A and possibly the CDN-B in the descriptive manifest file 125 (therefore of tracks with a URL of a server external to the train) allows access to the content in the event of a malfunction of the local server 152 or when the user leaves the train. A prioritization of CDN-A over CDN-B or vice versa is obtained via the control manifest file 126.

[0141] The different virtual CDNs can be referenced from the start in the descriptive manifest file 125.

[0142] Alternatively, they can be created on the fly by the content player 199, via the cloning pathway mechanism described above. In particular, the PER-VARIANT-URIS and PER-RENDITION-URIS functions can be used to duplicate only the desired variants on the local virtual CDN, in which case the HOST ([Fig.3b]) can be set to a non-existent or inoperative server (so as to force the players to the variants of the local virtual CDN only). Any evolution of the cloning pathway allowing the cloning of only part of a declared CDN will make it possible to avoid the indication of a non-existent or inoperative server.

[0143] In another variant, some virtual CDNs can be referenced from the start (for example the virtual CDN having all the tracks available locally) and others can be created on the fly (the other virtual CDNs with only part of these tracks available locally).

[0144] As indicated above, the control between the different local virtual CDNs is carried out using the control manifest file 126. In one embodiment, the ordered list 300 of path identifiers is modified to include, in order of priority, a single path identifier assigned to a local virtual CDN (whose tracks reference the URL of the embedded cache server 152) and selected according to the current target quality, then one or more path identifiers assigned to an external CDN 110 (for example CDN-A and / or CDN-B).

[0145] It is thus possible to ensure that the content players 199 remain on qualities / tracks available in the local cache or on qualities / tracks available that the embedded server 152 is able to retrieve without the current reading reaching the end of the cache. More generally, it is possible to force a content player to read only a subset of tracks on a particular CDN, a subset that varies over time and is controlled by the manifest server.

[0146] Figures 4a to 4d illustrate, for example, four control manifest files 126 that the manifest server 120 can use for this centralized control of the qualities accessible to the embedded readers 199. Of course, a different number of control manifest files can be envisaged to cover a different number of control possibilities of the qualities accessible to the readers.

[0147] The file in [Fig.4a] is used in the absence of an onboard cache server 152 (train not provided or user outside the train). The files in Figures 4b to 4d first reference one of the virtual CDNs and then an external CDN (here CDN-A).

[0148] In the case of the file in [Fig.4b], the player 199 can switch between the qualities of CDN-1, for example between FHD, HD and SD for the example in [Fig.2b]. Here the player has access to a high quality of the desired media content. In the case of the file in [Fig.4c], the player 199 can switch between the qualities of CDN-2, for example between HD and SD. The player has access to an intermediate quality of the desired media content. Finally, in the case of the file in [Fig.4c], the player 199 can switch between the qualities of CDN-3, here only using the SD track. The player therefore only has access to a low quality of the desired media content.

[0149] Depending on the desired target quality, the manifest server 120 therefore transmits to the reader 199 either the file of [Fig.4b], or that of [Fig.4c], or that of [Fig.4d]. In this way, it can modify in real time, the ordered list 300 and the maximum quality accessible by the reader 199.

[0150] The desired target quality may be determined based on a track availability status on the onboard cache server 152. For example, a quality is only accessible when the track is fully accessible in the onboard cache server 152, i.e., fully stored. Also, the target quality may simply be the best quality (track) for which all media segments are already stored. in server 152.

[0151] In this case, it is detected that a new track is cached in the embedded cache server, and the quality of the new track is used as the current target quality if no higher quality is stored entirely. Symmetrically, if it is detected that an old track is deleted from the embedded cache server (for example to free up memory space for other content to be cached), the best quality available for the remaining media content on the embedded cache server is used as the current target quality.

[0152] The desired target quality can be determined based on the available bandwidth on the communication link between the train and the external CDNs (used to retrieve the media segments). For example, only qualities (tracks) whose bitrate is lower than the available bandwidth can be declared as accessible. Also, the target quality can simply be the best quality (track) whose bitrate is lower than said bandwidth. This ensures that the loading time of the missing segments is lower than the remaining playback time of the content, so that no playback interruptions should occur.

[0153] To avoid permanent changes, the bandwidth of the communication link can be evaluated (for example an average) over a sliding time window (for example of a few tens of seconds).

[0154] The desired target quality may also be determined based on the playback position of the content by at least one content player 199. For example, it may be determined at what maximum quality it is possible (for the streaming agent 151) to load all the missing media segments onto the embedded server 152, taking into account the remaining playback time (therefore playback position) and the bandwidth available on the communication link. The objective is to obtain the media segments without the current playback catching up with the end of the cache in the embedded server 152. This maximum quality may define the target quality.

[0155] When multiple content players 199 play the same media content, the most advanced playback position is taken into account in this evaluation.

[0156] These different parameters for determining the target quality can be combined.

[0157] Of course, the target quality varies over time. Also, a current target quality is defined, which changes with the caching of media segments and / or the variation of bandwidth of the communication link and / or the playback position of the media content.

[0158] Thus, in the case where a player 199 catches up with the end of the cache (of the loaded media segments) or suddenly advances the reading position, it is possible, still via the control file 126, to force the player (and the others) to go down to a lower quality to avoid reading cuts.

[0159] The availability status of the tracks (therefore the quantity of media segments stored in the embedded server 152) can be determined by the streaming agent 151 by examining the memories of the embedded server 152. Similarly, the bandwidth of the communication link to the external CDNs can be determined by the streaming agent 151, using conventional bandwidth or throughput measurement tools. Finally, the reading positions of the media contents can be uploaded by the web server of the embedded server 152 and addressed to the streaming agent 151.

[0160] In one embodiment, the streaming agent 151 regularly updates the current target quality (for example every five seconds) according to these different parameters. It can transmit this value to the manifest server 120 which can then determine the ordered list 300 for the next control manifest file 126 to be transmitted for the media content concerned. It selects one of the virtual CDNs (or PATHWAY-ID) according to the associated maximum qualities and the current target quality, for example the virtual CDN having the maximum quality less than or equal to the current target quality. Then it prioritizes the selected virtual CDN by placing its path identifier (PATHWAY-ID) first in said ordered list 300. As indicated above, it may simply be a matter of choosing the appropriate file from predefined control manifest files (such as those in Figures 4b to 4d).

[0161] Alternatively, the streaming agent 151 itself determines the virtual CDN to be selected (or even the appropriate file) and sends, to the server 120, an instruction to modify the control manifest file 126 of the media content concerned, indicating to it which virtual CDN to prioritize or appropriate file to use.

[0162] In an alternative embodiment, the streaming agent 151 sends directly to the server 120 the values ​​of the parameters used to determine the target quality (bandwidth, cache status, reading position). In this case, the server 120 itself calculates the current target quality, and adapts if necessary the ordered list 300 of the manifest file for controlling the media content concerned.

[0163] [Fig.5] and [Fig.6] illustrate, using flowcharts, process steps at the level of the streaming equipment ([Fig.5]) and at the level of a content player 199 ([Fig.6]).

[0164] The methods begin when a reading of a media content is triggered (step 600) by a content player 199 hosted in a user terminal. This player first calls a routing server 129 ([Fig.l]) which, depending on various parameters including the public IP address of the messages received, decides on the best CDNs to use on the network at that time.

[0165] Typically, the routing server 129 knows the list of public IP addresses corresponding to the different trains. This routing server identifies the train (or its operator), determines whether it has an available cache server 152, as well as the domain(s) of the local CDN (i.e. the domain names used). The routing server then provides the address of the server 120 to the player 199, typically a descriptive manifest file URL for the media content, with potentially parameters.

[0166] Alternatively, for example in DASH for live content, the routing server can directly provide the address of a manifest server on board the train, to obtain the MPD root file.

[0167] The reader 199 requests (step 605) the manifest server 120 to obtain the descriptive manifest file 125, which is transmitted (step 500).

[0168] The descriptive manifest file 200 of Figures 2, 2a and 2b is for example obtained.

[0169] The file includes the tracks corresponding to the local virtual CDNs, the tracks corresponding to the external CDNs 110, the CDN activated by default (preferably a local CDN) and the URL of the control manifest file 126. The whole allows the launch of the reading while retrieving the first control manifest file 126 (sent in step 505).

[0170] Typically, the player 199 can select (step 610) the most suitable track from the tracks of the CDN activated by default, and retrieve (step 615) the corresponding track manifest file from the CDN servers. Using this file, the player 199 retrieves (step 620) the first media segments from the CDN, launching the playback of the media content and its rendering (step 625).

[0171] In the case where it is the embedded server 152 which is requested to provide the video segments of a track, it retrieves them from the external CDNs if it does not already store them. In parallel, different caching policies can be adopted, by which the embedded server 152 attempts to retrieve the other tracks not yet stored locally, which it must make available. Depending on the policy applied, only the qualities lower than the read quality are retrieved. Alternatively, only the qualities higher than the read quality are retrieved. Alternatively, all the other qualities are retrieved. Other variants can be envisaged where some of the lower qualities and higher qualities are retrieved.

[0172] The player 199 then determines (step 630) whether there is a quality change event. A quality change event may include a network error (inability to obtain the requested media segments) or the detection of an upstream rate allowing a better quality to be requested. Such an event typically causes the player 199 to switch to another quality of the active CDN by looping back to step 610. Another quality change event is the obtaining of a control manifest file 126 which modifies the active CDN. In this case, the player 199 also loops back to step 610.

[0173] In the absence of a change event, the reader 199 checks whether it should retrieve or reload the control manifest file 126 (step 635). When starting the playback of the media content (step 600), the player 199 systematically retrieves the control manifest file 126 from the manifest server 120 at the URL indicated in the descriptive manifest file 125. During the playback of the media content, the player 199 reloads the control manifest file 126 periodically every TTL seconds as indicated in the last received control manifest file.

[0174] If test 635 is successful, the reader 199 requests, in step 640, the manifest server 120 to obtain the control manifest file 126, which is transmitted (step 505).

[0175] The reader 199 loops back to step 630 to check whether the new driver manifest file 126 triggers a quality change. If so, it loops back to step 610. Otherwise, it waits until the next driver manifest file load.

[0176] Of course, during this time, the player 199 continues to retrieve the media segments and to render them.

[0177] Also, when the virtual CDN-1 is active (control manifest file of [Fig.4b] in progress) and the maximum quality (FHD) has been selected by the player, the reception of a different control manifest file, for example that of [Fig.4d] (activating the virtual CDN-3), leads the player to select (step 610) a track from those available for the CDN-3, namely the only SD track. Thus, by changing the control manifest file 126, the control server 120 has forced the player (and more generally all the players of the same media content) to switch to a lower quality. Centralized control of the qualities played is thus obtained.

[0178] As indicated previously, this control is operated according to parameters, such as the bandwidth of the communication link from the train to the external CDNs, the state of the caches storing the tracks accessible on the local server 152, and / or the current reading position of the media content.

[0179] Also, the control server 120 determines, continuously and jointly with the streaming agent 151, the current target quality at step 510. The target quality can be determined by the streaming agent and transmitted to the server 120. Alternatively, the previously listed parameters can be sent by the streaming agent to the server 120, which calculates the current target quality.

[0180] In step 515, the server 120 determines whether the new current target quality is identical to that associated with the active CDN. If so, the server 120 loops back to step 510 of determining the current target quality, which step can be performed at regular intervals, for example at intervals of a few seconds. On the other hand, if not, the manifest server 120 modifies the ordered list 300 of the control manifest file 126 which will soon be transmitted to the content player. 199.

[0181] Typically, the ordered list 300 first references the local virtual CDN corresponding to the current target quality (whose maximum quality is equal to the current target quality, otherwise the closest one lower than it). One or more external CDNs may also be indicated subsequently, in order to guarantee access to the media content even outside the train. Preferably, only one local virtual CDN is provided, as is the case in the examples of Figures 4b to 4d.

[0182] [Fig.7] illustrates operations for tracking and updating the current target quality of a media content, driving the activated virtual CDN. This figure corresponds to the aforementioned steps 510 to 520.

[0183] In one embodiment, they are carried out by the streaming agent 151. As mentioned previously, certain steps can however be implemented by the server 120.

[0184] The current target quality is denoted Q, while the next target quality is denoted Q'.

[0185] The initial Q quality (step 700) corresponds to that of the CDN activated by default.

[0186] In step 705, the streaming agent 151 records the current states of the parameters used for updating the target quality. Those indicated above include the state of the caches storing the tracks of the media content accessible on the local server 152, the state of the bandwidth of the communication link to the external CDNs and / or the state of the current playback positions of the media content. Real-time monitoring (of the order of a second) can be implemented.

[0187] In step 710, the streaming agent 151 determines whether these current states have changed sufficiently since the last determination of Q (current quality), to update the target quality. These events may include the end of the full loading of a track on the cache server 152 or, symmetrically, the deletion of the media segments of a track from the server. They may also include the decrease (or increase) of the bandwidth beyond a trigger threshold. They may include the determination of a quality whose missing media segments (typically a function of a playback position) can be obtained without catching up with the end of the cache.

[0188] If no, the agent 151 returns to step 705. If yes in step 710, the streaming agent 151 determines a new target quality Q' from the current states of the monitored parameters. For example, the best quality among the tracks (of the media content) entirely in memory of the cache server 152 is chosen. In another example, the best quality among the tracks (of the media content) having a bit rate lower than the monitored bandwidth is chosen. In another example, the best quality among the tracks that can be cached in the cache server 152 is chosen. cache 152 without the reading catching up with the end of the cache, taking into account their media segments already in cache, the current reading position (in particular of the most advanced player) and the current bandwidth, is chosen.

[0189] Once the value Q' is known, it is compared to Q to determine (step 515) whether the control manifest file 126 of the media content must be modified. If not, the agent 151 returns to step 705. If so, the control manifest file 126 is modified in step 520 already described. For example, Q=Q' when the quality available for the content that is equal to Q' or immediately below is Q.

[0190] [Fig.8] illustrates a variant of [Fig.l] in which the mobile environment (eg, train 150) includes an on-board control server 153 which provides the control manifest file 126' of the media content played. This variant offers greater responsiveness for updating this file 126' and therefore contributes to a better user experience.

[0191] In one embodiment, this embedded server 153 only provides the function of providing the control manifest files 126' for the embedded content players 199.

[0192] The operation of this embodiment differs from what has been previously described in that the descriptive manifest file 125 of a media content references this embedded control server 153 for obtaining the control manifest file for the embedded content players 199.

[0193] As indicated above, the routing server 129 identifies the train concerned, for example from its public IP address. It is then able to provide, to the content reader requesting it, the URL of the descriptive manifest file (for the media content), which file references the on-board steering server 153 to obtain the steering manifest file (therefore reference at the level of the descriptive element of the EXT-X-CONTENT-STEERING tag 210).

[0194] In a variant, the content descriptive manifest file 125 references the onboard control server 153 as the priority server for obtaining a media content control manifest file and references the external control server 120 as a fallback server for obtaining a media content control manifest file. By declaring these two servers, the content player 199 can continue to load a control manifest file even when it leaves the train. In addition, since the two control manifest files provided by the two servers can be different, they can be adapted for the use of external CDNs only for the manifest server 120 and for the use of local virtual CDNs for the onboard manifest server 153. This contributes to a better user experience.

[0195] In a particular embodiment, the on-board control server 153 and the external control server 120 are exposed with the same domain name, lo calment for the on-board server 153 and publicly for the external server 120. A local DNS or proxy of the vehicle 150 can then forward any reader requesting this domain name to the on-board control server 153. It is only when the reader leaves the vehicle (or when the server 153 malfunctions) that the reader's requests reach the external control server 120.

[0196] This configuration has the advantage of a single control server declaration within the content-descriptive manifest file 125 while guaranteeing the existence of an external fallback server for obtaining the control manifest file. This avoids interrupting the refresh of the control manifest file.

[0197] A descriptive manifest file 125 referencing a greater number of manifest servers for obtaining the control manifest file can be envisaged. These servers can be organized according to an order of priority. Thus, the content reader 199 has better availability of the control manifest file in the event of failure of one of the servers or difficulty in accessing it.

[0198] In another embodiment (not shown), the embedded server 153 provides both the function of providing the descriptive manifest files and the control manifest files 126'. This is for example the case for live content, in DASH, where the MPD root file can be provided by the embedded server.

[0199] In this case, the routing server 129 can provide, to the content player requesting it, a URL on the embedded server 153 where to obtain the descriptive manifest file for the media content concerned. As in the previous embodiment, this descriptive manifest file references the embedded server 153 for obtaining the control manifest file (in HLS) or obtaining the media segments (in DASH).

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

[0201] While reference is primarily made to VOD-type media content, the preceding 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 153 before their broadcast, and thus reduce the risk of cutoff. In practice, this delay can be applied by the cache server 153 which provides the track manifest files (in HLS) or the MPD root file (in DASH) listing the broadcast media segments, by “removing” the most recent media segments from the file and shifting the broadcast date. This modification is invisible to the content player 199.

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

[0203] For example, a decoder acting as a cache server 153 may be provided to a user for their home, a decoder on which one or more qualities / tracks of media content are preloaded (either at the user's request or in anticipation, for example, based on an editorial recommendation). Depending on whether these tracks are being preloaded or already stored in the decoder, it may be interesting to instantiate several local virtual CDNs to control the quality accessible by any content player connected to the decoder.< / qj> < / baseurl>

Claims

Claims

1. Adaptive streaming system (100) of media content available in a plurality of qualities, comprising a control server (120, 153) configured to transmit, at each request of a content player (199), a control manifest file (126, 126') defining an ordered list (300) of one or more path identifiers (CDN-A, CDN-1, CDN-2, CDN-3) associated with descriptive tracks (220, 221, 230, 231, 232) of said media content according to several qualities to prioritize access to the tracks by the content player according to said order of the list, each track referencing a uniform resource locator or "URL" where to access the media segments of the corresponding quality, characterized in that the control server is configured to modify, according to a current target quality (Q'), the ordered list of path identifiers for a next driver manifest file to be passed to the content reader.

2. The system of claim 1, wherein different path identifiers are associated with different sets (CDN-1, CDN-2, CDN-3, CDN-4) of one or more tracks of the same media content, each set having a different maximum quality, and modifying the ordered list of path identifiers comprises (1) selecting one of the path identifiers based on the maximum qualities of the associated sets and the current target quality, and (2) prioritizing the selected path identifier from said ordered list.

3. The system of claim 2, wherein two tracks of the same quality in two different games reference the same URL or media file.

4. A system according to claim 2 or 3, wherein a first set having a first maximum quality comprises the track(s) of a second set and an additional track of quality equal to the first maximum quality.

5. A system according to one of claims 2 to 4, wherein n sets Jk of maximum quality Qk comprise k tracks of quality Qi to Qk or comprise the tracks of quality Qi and Qk, with k an integer from 1 to n, and Qi <Qj pour i<j, et les pistes de qualité Q; référencent le même URL ou le même fichier média dans les n jeux Jk.

6. System according to one of claims 2 to 5, wherein said games having different maximum qualities comprise only tracks referencing a uniform resource locator or "URL" of an on-board cache server (152) in a vehicle (150), and at least one additional set of tracks, associated with a distinct path identifier, references a URL of a unicast content distribution server (110) external to the vehicle.

7. The system of claim 2 to 6, wherein the descriptive tracks referencing a URL of the embedded cache server are included in a content descriptive manifest file (125) transmitted by a manifest server and / or are generated by the content player by cloning one or more paths existing in a content manifest file (125) transmitted by the manifest server.

8. System according to one of claims 2 to 7, in which the ordered list (300) of path identifiers is modified to comprise, in order of priority, a single path identifier assigned to a set of tracks referencing a URL of an on-board cache server (152) in a vehicle (150) and selected according to the current target quality (Q'), then one or more path identifiers assigned to one or more additional sets of tracks referencing a URL of a content server (110) external to the vehicle.

9. System according to one of claims 1 to 8, in which the URLs reference an on-board cache server (152) in a vehicle (150), and the control server (120) is external to the vehicle and receives, from a management agent (151) on-board the vehicle, a message indicating said current target quality (Q') to modify the ordered list of path identifiers.

10. System according to one of claims 1 to 8, in which the URLs reference an on-board cache server (152) in a vehicle (150), the control server (153) is on-board the vehicle, descriptive tracks of said media content according to several qualities are included in a descriptive manifest file (125) of content transmitted by a manifest server (120) external to the vehicle, and the descriptive manifest file of content references the on-board control server as a priority server for obtaining a control manifest file of the media content and references a second control server, external to the vehicle, as a fallback server for obtaining a control manifest file (126, 126') of the media content.

11. System according to one of claims 1 to 8, in which the URLs re- reference an embedded cache server (152) in a vehicle (150), and the control server (153) is embedded in the vehicle and is exposed locally with a domain name identical to that of a second control server (120), external to the vehicle.

12. System according to one of claims 1 to 11, in which the control server (120, 153) or a management agent (151) on board the vehicle is configured to determine the current target quality (Q') as a function of a state of availability of the tracks on a cache server (152) on board the vehicle and / or of a bandwidth available on a communication link between the vehicle and an external content server (110).

13. The system of the preceding claim, wherein determining the current target quality is further dependent on a current playback position of the media content.

14. A method for adaptive streaming of media content available in a plurality of qualities, comprising the transmission (505), by a control server (120, 153) at each request of a content player (199), of a control manifest file (126, 126') defining an ordered list (300) of one or more path identifiers (CDN-A, CDN-1, CDN-2, CDN-3) associated with descriptive tracks (220, 221, 230, 231, 232) of said media content according to several qualities to prioritize access to the tracks by the content player according to said order of the list, each track referencing a uniform resource locator or "URL" where to access the media segments of the corresponding quality, characterized in that it comprises an additional step, by the control server, of modification (520), according to a current target quality (Q'),of the ordered list of path identifiers for a next driver manifest file to be passed to the content reader.,

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