Video streaming with a substitute segment in a shared transport environment

Abstract

To prevent an on-board train content player from malfunctioning, a streaming agent 162 cooperates with a cache unit 161 to provide stored media segments, a manifest unit 169 to provide track description files 125 and driver manifest files 126, a monitoring unit 163 to determine the quality of a connection with an external source CDN, a description unit 165 to obtain a textual description of requested media segments, and a substitution unit 164 to obtain substitute segments, for example, by generative AI generation from the textual description and optionally other segments of the same media content. The streaming agent 162 substitutes a media segment requested by the player with a substitute segment when the connection quality with the external source CDN is insufficient to provide the original media segments. [Fig. 1]

Description

Title of the invention: Video streaming with a substitute segment in a shared transport environment Scope of the 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 online media content without having to download a file to the playback device (phone, tablet, computer, augmented or virtual reality glasses, etc.). Streaming operates between two parties: on one side, a client equipped with a content player on the end user's playback device and, on the other, a server (or several servers grouped into a content delivery network or "CDN") that makes the media content available.

[0003] Adaptive content streaming, such as HLS (for "HTTP Live Streaming" by Apple - trade name) or DASH (for "Dynamic Adaptive Streaming over HTTP" - trade name, also known as MPEG-DASH), is natively designed to adapt to the quality of the connection between the client and the server at a given time, but also to adapt to fluctuations in bandwidth and connection quality over time.

[0004] The same media content is classically offered, in a descriptive file (known as "master playlist", "media playlist", "manifest" or "MPD" for "Media Presentation Description"), according to several qualities (or "tracks") chosen by the content player which "adapts" dynamically by switching from one quality to another, for example when there is a decrease or increase in available bandwidth, leading, after a detection time, to a decrease or increase in the audio / video quality delivered to the user.

[0005] The lowest available quality of media content allows for a substantial decrease in connection quality. However, when the decrease in connection quality is even more significant, as in the case of a connection interruption, playback of the media content can no longer continue, even at its lowest quality.

[0006] The content reader may then encounter an error and stop reading, requiring either restarting the reading later or waiting for a sufficient amount of data (a "buffering" mechanism) for an indefinite period before either stopping reading (in case of insufficient data) or resume playback in "fast forward" mode to gradually catch up with the live stream, or by maintaining the temporary offset, or by making a time jump to return to the live stream.

[0007] These mechanisms for interrupting reading are not satisfactory insofar as the user experience is poor.

[0008] They are even more destabilizing in the case of transport (car, train, plane, spaceship, etc.), a field in which the quality of connection fluctuates frequently over time.

[0009] Indeed, when a vehicle is moving, it may pass through areas with varying levels of communication network coverage (for example, depending on the presence or distance of base stations), thus affecting connection quality. Therefore, it is planned to equip vehicles with one (or more) embedded cache servers to retrieve and store locally all or part of the content from the external CDN in advance, thereby allowing passengers easier access. An "embedded" CDN is thus instantiated within the vehicle, which manages the cache server and responds to requests from content players to provide the streaming service via a local network (generally Wi-Fi – the commercial name) inside the vehicle.

[0010] However, the user can simultaneously use the vehicle's local network, which is of good quality, and at the same time experience an interruption in playback when, for example, the connection between the vehicle and the external CDN fails to retrieve the media data not stored locally. The content player therefore stops playback or goes into a waiting state, even though the user perceives a perfectly functional (local) network. This situation is therefore unsatisfactory.

[0011] Solutions have been proposed, for example in publication EP4093039, consisting of the content player displaying a multimedia resource (an image, for example) while the video requested by the user is loading. These solutions are not satisfactory because they require an adaptation of the content player. Furthermore, they lead to an interruption in the playback of the requested video. Description of the invention

[0012] There is also a need for an improved streaming system that reduces the risk of the content player malfunctioning, without modifying the player itself. This would improve the user experience.

[0013] To this end, a system for streaming media content stored on a streaming server is proposed, the system comprising a streaming agent configured to obtain media segments from media content on the streaming server. and to transmit a media segment in response to each media segment request by a content player, a system in which the transmitted media segment is a substitute segment different from the requested media segment when the connection quality with the streaming server is insufficient (particularly for obtaining the requested media segment from the server). The substitute segment is a media segment in the sense that the content player interprets it as if it were the requested media segment.

[0014] By configuring the streaming agent to proactively handle media data shortages in the content player, the latter is not notified of a potential connection problem and can continue playing content as if nothing had happened, using the transmitted replacement segments. Therefore, the content players already deployed on numerous user terminals do not need to be modified.

[0015] Of course, when the connection situation returns to normal, the streaming agent can resume the transmission of the requested media segments, allowing the correct video, audio, and subtitle to be displayed on the user terminal.

[0016] Correspondingly, a method for streaming media content stored on a streaming server is also proposed, the method comprising, at the level of a streaming agent, the following steps: to obtain media segments from media content from the streaming server; and to transmit a media segment in response to each media segment request by a content player, wherein the transmitted media segment is a substitute segment different from the requested media segment when the connection quality with the streaming server is insufficient

[0017] 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 process features.

[0018] In one embodiment, the replacement segment is stored at the URL (Uniform Resource Locator) of the requested media segment. This is the URL specified in the track selected by the player in the manifest file describing the media content. The streaming agent therefore directly substitutes the requested (unavailable) media segment with the replacement media.

[0019] This arrangement is advantageously implemented by a cache (or proxy) server separate from the streaming server and embedded either in the user equipment or in a vehicle in which the user equipment is located. This allows the use of the original, unmodified descriptive manifest files (from the streaming server), particularly when these are not reloaded by the player during media playback (typically for VOD content).

[0020] In another embodiment, the replacement segment is stored at a replacement URL different from the URL of the requested media segment, and a manifest file describing the media content is modified to reference the replacement URL instead of the URL of the requested media segment, before transmitting the manifest file describing the media segment to the content player. The modified manifest file can be a track description file in the case of the HLS format, or the MPD file in the case of the DASH format.

[0021] This provision advantageously allows content player requests to be easily redirected to replacement segments, particularly for live content where the descriptive manifest file of only a portion of the content is regularly reloaded by the content player.

[0022] In another embodiment, the replacement segment is stored at a replacement URL declared in a media content description manifest file, linked to a media content description track associated with a replacement path identifier that is different from a primary path identifier associated with another description track referencing the URL of the requested media segment. A steering manifest file (known as defining an ordered list of one or more path identifiers associated with the media content description tracks to prioritize access to the tracks by the content player according to said list order) indicating the replacement path identifier is passed to the content player. This arrangement uses the mechanism known as "Content Steering." Again, the modified manifest file can be a track description file in the case of the HLS format, or the MPD file in the case of the DASH format.

[0023] The alternate path identifier can thus define an alternate virtual CDN transmitting alternate segments different from those of the media content. This arrangement allows the content player to be redirected to the alternate virtual CDN to obtain the alternate media segment. Advantageously, since the driver manifest file is reloaded regularly by the content player, it is possible to dynamically adapt the content player's redirection according to changes in the quality of the connection with the streaming server.

[0024] This redirection can be performed as the primary method. In this case, the alternate path identifier is specified first in the driver manifest file.

[0025] It can also be performed as a backup, that is, in the event of a failure—detected by the content reader—of one or more other CDNs to provide the requested segments. In this case, the alternate path identifier is indicated after the primary path identifier in the driver manifest file.

[0026] In a particular embodiment, a plurality of alternative substitution segments are stored at respective substitution URLs and declared in the file descriptive manifest, linked to respective descriptive tracks associated with different alternate path identifiers, The streaming agent is configured to select an alternate path identifier or an order of alternate path identifiers based on connection quality information and / or the availability of an alternative alternate segment, and to indicate the selected identifier or order in the driver manifest file,

[0027] For example, different replacement segments can be chosen and displayed depending on different causes of poor connection, such as passing through a tunnel or an unknown connection loss. Similarly, if a replacement segment cannot be generated, for example due to the absence of a textual description of the media content (as described below), the corresponding replacement path identifier is not selectable.

[0028] This provision allows for more precise dynamic control, in order to improve the user experience.

[0029] In one embodiment, the streaming agent is hosted in a cache server embedded in a vehicle, and the content player is embedded in a user device connected to the cache server via a local network of the vehicle.

[0030] In another embodiment, the streaming agent is embedded in the same user equipment as the content player.

[0031] In one embodiment, the system includes a vehicle-mounted monitoring unit configured to determine connection quality information between the vehicle and the streaming server and transmit the connection quality information to the streaming agent.

[0032] For example, this could involve determining the available bandwidth for media content in a communication link between the vehicle and the external broadcast server. This information then makes it possible to determine when the available bandwidth falls below the bandwidth associated with the minimum quality offered by the determined media content tracks, i.e., when the bandwidth becomes insufficient. It therefore makes it possible to determine when to use a replacement segment.

[0033] In one embodiment, the system includes a description unit configured to obtain a textual description of the requested media segment or media content, and a substitution unit configured to generate a substitution segment from the textual description. This generation can typically be performed using a generative artificial intelligence engine for images, videos, or audio. This arrangement enhances the user experience by enabling the smooth progression of the rendered media content.

[0034] In a particular embodiment, the replacement unit is configured to generate the replacement segment from one or more other media segments of the media content, for example, obtained segments that precede the requested media segment in the media content. These may be audio, video, or subtitle segments that have already been loaded. This combination of several sources allows for a "multimodal" generation of the replacement segment, which improves the quality of the replacement segment for a better user experience. For example, the other media segments allow for the generation of replacement segments that maintain the same voice timbre, background music, cinematic style, etc.

[0035] In another embodiment, a substitution segment includes an informational message or a countdown, correlated with connection quality information.

[0036] In particular, the system may include a monitoring unit mounted in a vehicle and configured to determine a duration of interruption of connection with the streaming server, said countdown being defined in relation to the duration of interruption.

[0037] In a particular embodiment, the streaming agent is configured to select a replacement segment from the following list, based on connection quality information and / or the availability of replacement segments in the list: a replacement segment including an informative message, a replacement segment including a countdown timer, and a replacement segment generated from the textual description of the requested media segment or media content, and optionally also from one or more other media segments of the media content.

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

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

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

[0041] At least part of the methods according to the invention can be implemented by computer. Accordingly, the present invention can take the form of a fully hardware embodiment, a fully software embodiment (comprising firmware, resident software, microcode, etc.) or of an embodiment combining software and hardware aspects, all of which can be collectively referred to herein as a "circuit," "module," or "system." Furthermore, the present invention can take the form of a computer program product embedded in any tangible medium of expression having computer-usable program code embedded in the medium.

[0042] Since the present invention can be implemented in software, the present invention can be incorporated in the form of computer-readable code for provision to a programmable device on any suitable medium. A tangible or non-transient medium may include a storage medium such as a hard disk drive, a magnetic tape device, or a semiconductor 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

[0043] Other features, details, and advantages of the invention will become apparent upon reading the detailed description below. This description is purely illustrative and should be read in conjunction with the accompanying drawings, in which:

[0044] [Fig.l] schematically represents an example of an adaptive video streaming system according to embodiments;

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

[0046] [Fig.2a] illustrates an extension of the file in [Fig.2] to tracks of a local CDN accessible on a server embedded in a vehicle, according to embodiments;

[0047] [Fig.2b] illustrates an additional file extension of [Fig.2] or [Fig.2a] to a possible alternative CDN instantiated on the embedded server, according to various implementation methods;

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

[0049] [Fig.4] illustrates a driver manifest file referencing a local virtual CDN and a External CDN, according to embodiments;

[0050] [Fig.4a], [Fig.4b], [Fig.4c] and [Fig.4d] illustrate pilot manifest files referencing one or more alternative CDNs according to embodiments;

[0051] [Fig.5], [Fig.5a] and [Fig.5b] illustrate, using flowcharts, steps in process according to embodiments;

[0052] [Fig.6] represents a variant of an adaptive video streaming system, according to methods of implementation. Detailed description

[0053] Figure 1 illustrates an adaptive streaming (or "continuous broadcasting") system for media content, such as video on demand (VOD) or live programs. Only the equipment and functions relevant to the explanations below are shown, for the sake of simplicity. However, those skilled in the art will recognize the additional equipment or functions that are typically used in the operation of a streaming system.

[0054] The representation of the equipment and functions is purely schematic. An illustrated block or module can be implemented within one or more physical devices (such as servers). Similarly, two or more illustrated blocks / modules can be implemented within the same physical device.

[0055] The system 100 conventionally comprises one or more public unicast content delivery networks or "CDN" 110, one or more servers 120, a communication network 130 to which the servers 110, 120 are connected and to which terminals or user or client equipment UEs, each equipped with a content player 199, can connect, and an alternative communication network, for example a mobile telephone network 140 interfacing certain equipment UEs with the network 130.

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

[0057] Typically, 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 standard definition (SD) version. Of course, a different number of versions can be produced, as well as other resolutions. 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 (integer) media files accessible to users in the streaming system.

[0058] 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, encoding, audio language, subtitle, etc.

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

[0060] Media segments (i.e., media files of a given quality) are stored permanently under these names on the CDN servers to enable on-demand access (VOD). Alternatively, they are generated (encoded) on the fly, typically during live events, in which case they are stored temporarily under these names on the CDN servers. A server can store both segments permanently and segments temporarily.

[0061] The Figure illustrates two CDNs 110 for unicast distribution 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 possible.

[0062] While the rest of the description focuses mainly on video streaming, similar considerations apply to other components of a multimedia service, typically audio tracks, subtitles, interactive data, etc., or even to audio-only media content.

[0063] Media content available on CDNs 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 ("Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP" - trade name). End users, typically content players, can then access this content in successive segments via HTTPS unicast requests, i.e., secure HTTP, to the URLs (for "Uniform Resource Locator") indicated in these files.

[0064] The server(s) 120 store the descriptive files 125 of the various media content stored on the CDN 110 and accessible to users. These servers, which perform the function of providing the description files 125, are called descriptive file servers or "manifest".

[0065] As is known, a root description file is generated for each piece of multimedia content (for example, a TV channel, a VOD title). This description file is called a "manifest" or MPD in the MPEG DASH protocol and a "master playlist" in the HLS protocol. The root description file is typically generated only once for each piece of VOD media content. However, it can be generated dynamically to adapt the quality to each user device and / or network conditions.

[0066] An example of a root 200 description file is shown in [Fig. 2] in HLS format. This file is simplified to the necessary elements for clarity. In practice, other attributes are specified for the available tracks. The root description file includes metadata (on lines beginning with the # tag), some of which defines a plurality of tracks corresponding to the different media files available on the CDN 110, and therefore to the different accessible qualities. Each track consists of a metadata line specifying attributes of that track and a second line indicating the URL of an associated file describing the media segments constituting the media file.

[0067] In this example, track 220 defines French audio content, details of which are provided in the track description file "audio Lm3u8" stored on the server "extemal.server.com" of CDN 110. Similarly, track 221 defines original version audio content, details of which are provided in the file "audio2.m3u8", and track 222 defines French subtitle content, details of which are provided in the file "subs.m3u8". Three different video tracks / qualities are offered: track 230 in low SD resolution (960x540), details of which are provided in the file "wl_v_avc_0_540_960_0_2100.m3u8" stored on the server "extemal.server.com", track 231 in HD resolution (1280x720), details of which are provided in the file "wl_v_avc_10_720_1280_0_3400".m3u8”, and track 232 in Full HD resolution (1920x1080), details of which are provided in the file “wl_v_avc_20_1080_1920_0_4500.m3u8”.

[0068] Each alternative track in the descriptive file 200 therefore corresponds to a second content descriptive file, "m3u8", or "track description file" or "media playlist", which indicates the web URLs where the content player 199 obtains, via 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.

[0069] In the case of VOD content, the track description file generally lists all the different media segments that make up the track, preventing the player from having to reload this file during playback. However, this is different for live media content because the "future" media segments are not yet available. Therefore, several successive content description files are generated (or equivalently, the same file is updated), each file adding a new portion of the media content that is about to be broadcast.

[0070] The case of the DASH format is slightly different. The DASH root MPD file lists the different available qualities / tracks and directly contains, for each of these qualities / tracks, the URLs where the content player 199 obtains, via unicast requests, the different media segments of the track. Also, in the DASH format, the track description file is the root MPD file, which 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 in the case where the media segments are stored on a server other than the one delivering the root MPD file. The MPD file is therefore updated regularly in the case of live media content.

[0071] The description files are obtained by the content player 199 by requesting them from the server 120. In a known manner, the content player 199 requests the root description file 200 of the multimedia content it wishes to access, selects one of the tracks according to the desired (or supported) quality / resolution, and, in the case of HLS, requests the track description file corresponding to the selected track. It can then, via unicast requests, query the server corresponding to the URLs of the track description file to obtain the successive media segments, typically an audio track, a video track, and optionally a subtitle track.

[0072] The server(s) 120 also store descriptive steering or "Content Steering" files 126 for media content. These servers, which perform the function of providing the steering files 126, are called steering servers.

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

[0074] The Content Steering mechanism is described for example in the file https: / / developer.apple.com / streaming / HLSContentSteeringSpecification.pdf.

[0075] It was developed to allow clients to be assigned to different servers or CDNs in order to better distribute the load between servers, particularly during periods of high traffic. It therefore prioritizes access to one CDN 110 over another. A steering manifest file is obtained by content players from a dedicated server for the requested media content.

[0076] In practice, the control manifest file defines a priority order between different "pathway IDs" which are entered at the level of each track in the content description manifest file, the tracks indicating URLs to various servers. A player is then forced to switch only between the tracks affected by the considered pathway ID, starting from the highest priority one to the lowest priority one.

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

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

[0079] The Content Steering file 126 operates in conjunction with the attribute named "PATHWAY-ID" specified at the track level of the root descriptor file 200 in order to prioritize tracks (those bearing a specific PATHWAY-ID) over other tracks, and indirectly to prioritize a CDN 110 ("external.server.com" in the example in [Fig. 2]) over other CDNs. In other words, the "PATHWAY-ID" attribute is simply a CDN prioritization attribute, and therefore indirectly a track prioritization attribute.

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

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

[0082] 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 descriptor file 200 is allowed to switch between "CDN-A" tracks only (tracks 220, 221, 230, 231, 232 in the Figure), and switch to "CDN-B" tracks (track 233) only if no "CDN-A" track (of the same type - video, audio, subtitles) is available. Content player 199 therefore initially only requests the server "external.server.com".

[0083] In the opposite case where the ordered list 300 defines CDN-B as a priority over CDN-A, the example in [Fig.2] first imposes the use of track 233, at reader 199.

[0084] Note that in the absence of a Content Steering file 126 (unavailable or not yet obtained or loaded), an attribute is defined by default as the priority, at the end of the descriptive element 210. In the example, "CDN-A" is the default attribute for 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.

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

[0086] The same Content Steering 126 file format is used in both the HLS and DASH protocols, with only the PATHWAY-ID attributes being defined in different locations within 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.pdf. Again, the PATHWAY-ID allows prioritizing different paths to content.

[0087] Returning to [Fig. 1], CDN 110 are classic HTTP-based infrastructures, typically secure standard DASH or HLS servers (i.e., HTTPS). They perform unicast content delivery / streaming, meaning they deliver media segments upon request from content players.

[0088] The requests and returned media segments pass 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 content player is fitted to a user equipment UE of the telephone type connected to the network 140.

[0089] Figure 1 illustrates an adaptation of the system to a collective environment (airport, train station, etc.), and in particular to a mobile environment such as public transport, like a vehicle (train, plane, boat / ferry, car, bus, spacecraft, etc.). Although only one collective environment is shown, several may exist. simultaneously, in which users have access to the streaming service as described below. Typically, several trains can operate simultaneously. The following description uses a train-like mobile environment for illustrative purposes only. It therefore applies to any other mobile environment.

[0090] As illustrated in the Figure, the train 150 comprises a cache server 160, a local communication network 170, and one or more user terminals (UEs) equipped with content readers 199. The cache server 160 and the terminals are connected to the local network 170 to enable communication. The local communication network 170 may be wired or wireless, typically an onboard Wi-Fi network (trade name). The train is also connected to an external communication network, such as network 130 or 140, giving it access to external servers 110 and 120.

[0091] Subsequently, the notion of "local" refers to the elements and operations embedded in train 150 as opposed to the elements and operations of servers 110 and 120.

[0092] A user terminal (UE) can take the form of a smartphone, tablet, laptop or desktop computer, or a connected device (television, watch, camera, smart glasses, augmented or virtual reality glasses or headset, etc.). A user terminal is connected to the local network via a wired connection (Ethernet cable) or wirelessly (Wi-Fi). A user terminal, typically a phone or tablet, can also be connected to the mobile network (particularly when the user gets off the train, but also continuously if the phone decides to retrieve certain files via the cellular network). Such a terminal therefore has the ability to switch from one network (local) to the other (mobile).

[0093] Access to the streaming service by content players 199 can be achieved using a dedicated playback application running on the user's terminal or through a web browser on the user's terminal running said video player. For example, a phone connected to the mobile network 140 accesses the streaming service in the conventional way by unicasting requests to the CDN (to retrieve the manifest files 125, 126 and then the media segments).

[0094] The cache server 160, like the CDN 110, is a local streaming server, that is, a local unicast CDN for media segments corresponding to content accessible locally in a cache unit 161. To do this, it instantiates, at the level of a streaming agent 162, a local web server to respond to unicast requests from locally connected content players 199. The local web server can be a simple HTTP server or be configured as an HTTPS server, that is, a secure server, ideally HTTPS / 2 or HTTPS / 3 with TLS 1.3 or later.

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

[0096] Locally available tracks may thus correspond to all or part of the tracks available on external CDNs 110, for a given media content. The local web server therefore stores media segments of these tracks (all or part of the media segments of the tracks).

[0097] In one embodiment, the local web server also stores the root description files and the corresponding track description manifest files for the locally available tracks. This allows content players to avoid having to query the 120 server. Alternatively, players can still query the 120 server to obtain at least the root manifest file.

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

[0099] In this example, the local web server of the cache server 160 is exposed on the local network with a dedicated domain name, here "local.server.com", which can be publicly exposed or not. Using a domain name allows for identical deployment of the qualities across multiple environments 150 (trains) through a single track declaration 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 separate track declaration for each train in the root manifest file 200.

[0100] 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 160) in a local DNS server.

[0101] 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_l 920_0_4500.m3u8" is also stored on the same server. Of course, a number of other tracks can be used locally.

[0102] For ease of implementation, the track manifest files of the external CDN 110 and the local ones are identical (thanks to relative URLs), so the media segments to be provided are also the same. This allows the cache server 160 to retrieve the track manifest files and media segments directly from the external CDN 110. Furthermore, if absolute URLs are used, it is sufficient simply change the server's domain name in the trace manifest files to point to the local server.

[0103] In this example, it is the root manifest file 200 that references the cache server 160 to retrieve the track description files, which are then stored in the manifest unit 169. 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 to retrieve the track manifest files from the same server 120, and it is the track manifest files that reference the cache server 160 (absolute URL) to retrieve the media segments from the cache server. The description below refers to the first case, but it applies similarly to the variant.

[0104] The first case applies particularly well to live content even though it can apply to on-demand content, whereas the variant is suitable for on-demand content, even though it also applies to live content.

[0105] This variant also corresponds to the case of DASH, where the single MPD manifest therefore references the cache server 160 (absolute URL) to obtain media segments from the cache server. For "live" content in DASH, the MPD manifest can be stored in the manifest unit 169 of the cache server 160, and the content player 199 can then query the cache server 160 to obtain the multiple successive (or updated) MPDs describing the live content.

[0106] The use of the driver manifest file allows prioritization of external ("CDN-A") or local ("CDN-1") tracks. For example, the file in [Fig. 4] forces content player 199, wishing to access the media content in question (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 gets off the train), content player 199 is allowed to switch to the "CDN-A" tracks of the external CDN.

[0107] Again, the steering manifest file can be generated and transmitted by the external server 120, or be stored (or even generated) in the manifest unit 169 and transmitted by the local cache server 160. In this second case, the root manifest file 200 typically references the cache server 160 (absolute URL in the EXT-X-CONTENT-STEERING tag 210) for obtaining the steering manifest file(s) on the cache server.

[0108] Given the limited memory space in the cache unit 161, it is generally inconceivable to store all the media segments of a complete catalogue of multimedia content.

[0109] Certain media segments are preloaded into the cache server 160, typically at the station before the train departs. In one embodiment, the media segments of a SD tracks of media content are pre-loaded to ensure access to the media content. In one embodiment, media segments of a 4K, FHD, or HD track of preferred media content are pre-loaded to ensure a satisfactory user experience.

[0110] Certain media segments are loaded on demand (on the fly), for example during a train journey when a content player requests playback or with live content.

[0111] The streaming agent 162 is for this purpose responsible for retrieving the media segments to be preloaded, for example those remaining from a track being played, from the external CDN(s), via the communication network 130 or 140. The retrieved segments are stored in the cache server 160 for making available to the content player 199. Preferably, the streaming agent 162 works to preload all the missing media segments of a media content being played.

[0112] It goes without saying that a streaming service is only effective if the communication link between the client and the external CDN is maintained at a good quality throughout the entire streaming process. This link generally passes through the Internet. However, Internet connections, which are of fluctuating and reduced quality, are increasingly shared by a growing number of users for multiple purposes. This results in a generally degraded Internet connection for individual users—and therefore for the media content they request—particularly for applications requiring intensive and continuous data usage.

[0113] This upstream communication link to the external CDNs 110 is therefore not necessarily stable along the train's route, sometimes experiencing interruptions (e.g., in a tunnel), or it may not offer sufficient bandwidth for the cache server 160 to obtain all the media segments requested by the onboard user terminals (UEs) and be able to serve them. In this case, the content players 199 switch to a lower-quality track, until they are no longer able to continue playback due to a lack of media segments.

[0114] To prevent the content player 199 from failing, the streaming agent 162 is configured to transmit a substitute segment different from the requested media segment when the connection quality with the external CDN 110 is insufficient, i.e. does not allow the cache server 160 to retrieve the requested media segment in time.

[0115] In the embodiment of [Fig. 1], the cache server 160 comprises, in addition to the cache unit 161 and the streaming agent 162 and the manifest unit 169, a monitoring unit 163, a substitution unit 164 and a description unit 165. All or part of these units may be implemented according to the functionalities offered by the cache server 160 as described later.

[0116] The monitoring unit 163 is configured to determine real-time connection quality information between the vehicle 150 and the CDN(s) 110. "Real-time" means a frequency higher than that of the video segments. In degraded embodiments, a lower frequency may be used.

[0117] The monitoring unit 163 can obtain all or part of the following information: a connection status with the CDN 110 (e.g. connection available or unavailable); bandwidth available with CDN 110; bandwidth allocated to media content in the communication link with CDN 110; the location of vehicle 150 and its speed.

[0118] Then, it can determine one or more connection quality indicators from this information. If this indicator reveals insufficient current or future connection quality, it can be accompanied by information on the time of return to a nominal situation.

[0119] For example, the availability or unavailability (i.e., interruption) of the connection is obtained from the connection status.

[0120] In another example, sufficient or insufficient bandwidth for a client and requested media content is determined based on whether the available or allocated bandwidth is above or below a threshold value. This threshold typically corresponds to the minimum bandwidth—i.e., the lowest quality bandwidth—required for the requested media content. The threshold can be adjusted depending on whether media segments of the content are already available in cache 161 of cache server 160. Also, a live channel may not be playable because it is not prioritized on the device (no allocated bandwidth).

[0121] In case of insufficient bandwidth, connection resumption information can be determined, for example when a resource allocation plan is set, allowing us to know when the media content will recover sufficient bandwidth with the CDN 110. The resource allocation plan can, for example, define time ranges where bandwidth on the communication link with the CDN 110 is allocated to a specific media content track for caching the corresponding media segments.

[0122] In another example, whether or not a vehicle is entering (or is nearing) a dead zone (tunnel, lack of network coverage) can be determined from the vehicle's location and a pre-established map of dead zones along the vehicle's route. It should be noted that information regarding the duration of the dead zone (and therefore the time it takes to exit the zone) can be determined using the vehicle's speed, taking into account the length of the dead zone on the map.

[0123] This connection quality information is transmitted in real time to the streaming agent 162 so that the latter can decide whether to use, immediately or at a later time, a substitute segment in the event of insufficient connection quality, whether present or future, or to resume transmission of the requested media segments if the situation returns to normal. It is this information, which is not available to the video player 199, that allows it to anticipate a playback error.

[0124] The streaming agent 162 obtains the substitute segment (different from the requested media segment) from the substitute unit 164, for example when the connection quality information obtained from the monitoring unit 163 reveals insufficient quality to serve the media segments of requested media content.

[0125] The substitution unit 164 can store default substitution media segments, typically including a generic hold message, or generate the substitution segments on demand, typically based on connection quality information or even on a textual description of the requested (and not served) media segment or the media content concerned.

[0126] The replacement segment returned by the replacement unit 164 is intended to replace the requested media segment. Therefore, the replacement segment chosen or generated by the replacement unit 164 has characteristics similar to those of the requested media segment, in terms of encoding, bitrate, resolution, frame rate, etc. These characteristics (or generation options) are, for example, defined in advance or indicated in the requested track 220, 221, 230, 231, 232, 233.

[0127] Also, several substitution segments having the same substitution media content (message, video, audio, etc.) but corresponding to several encoding / resolution configurations can be obtained by or stored in the substitution unit 164. In alternative or combination, this unit includes means for generating (encoding, not shown) substitution segments from substitution media content.

[0128] It is therefore the media content of the substitute segment (substitute media content) that differs from that of the requested media segment. In the case of an audio-type requested media segment, the substitute media content may be no audio, generic hold audio, or an oral explanation possibly related to the poor connection quality information. In the case of a subtitle-type requested media segment, the substitute media content may be no subtitle, generic hold subtitles, or a written explanation possibly related to the poor connection quality information. In the case of a video-type requested media segment, the substitute media content may be generic hold video or an explanatory video possibly related to the poor connection quality information. The explanation (audio, subtitle, or video) may Specifically, it should indicate the nature of the insufficient connection quality (outage, tunnel, non-priority media content, etc.) and / or indicate a time when normal playback will resume. Typically, a countdown timer may be included in the alternative media content, which is based on the information regarding the time of return to a normal state provided by monitoring unit 163. Such a countdown timer indicates the duration of the connection interruption with the CDN 110.

[0129] In one embodiment, the replacement unit 164 uses a generative artificial intelligence engine to generate the replacement segment from a textual description of the requested media segment or media content. This is referred to as the generation of the media segment content. These generative AI engines for images or audio are known to those skilled in the art. They make it possible to improve the perceived quality of the replacement segments for the user.

[0130] Description unit 165 is configured to retrieve the text description from CDN 110 (or any equivalent server). This text description can be generated by analyzing the video / audio content, using tools such as Valossa (non-commercial) to generate a detailed transcript of media content.

[0131] For VOD or live stock content, a complete transcription of the content can be performed in advance, preferably using sequential transcription segment by segment (or group of segments by group of segments) to provide a textual description that is contextual for each media segment. Textual descriptions of this content can be preloaded into description unit 165.

[0132] For live content from a live event, the transcription is performed progressively, media segment by media segment (or group of media segments by group of media segments). The text descriptions of the live content are therefore loaded progressively into the description unit 165, while this content is being played.

[0133] There is always a delay, of varying length, between the live event and the provision of the corresponding media content, enabling the transcription and sending of the text description to the cache server 160. The delay related to video processing (encoding, encapsulation, transmission time from the recording site to the servers) typically corresponds to several media segments. A delay of around 30 seconds is commonly observed. In some technical solutions aimed at reducing the risk of interruptions, this delay inherent in the broadcast technology is intentionally lengthened, for example, potentially reaching several minutes. Preferably, the text descriptions of the live content are transmitted via a priority, low-latency path, which could be another network. The communication method used to retrieve media segments from CDN 110 is different. This is particularly relevant for live content from events filmed live. However, for live broadcasts of stock content, text descriptions can be transmitted in advance, as with on-demand content.

[0134] Textual descriptions are time-stamped (relative to the media content concerned) to allow their rapid identification for a requested media segment.

[0135] When the substitution unit 164 needs to generate a substitution segment, it retrieves the textual description of the requested media segment (using the timestamp) and then runs the generative AI engine with this description to obtain the media segment.

[0136] In one embodiment, the generative AI engine also receives as input one or more other media segments of the same media content, for example, media segments preceding the requested media segment in the same track or simultaneous media segments of a different type (for example, a subtitle media segment to generate a video or audio media segment). This results in multimodal generation of the replacement segment. This makes it possible to improve the quality of the generated replacement segments and to make the generated content even closer to the original for the user (for example, by preserving a voice timbre, background music, cinematic style, etc.).

[0137] For example, the generative AI engine receives the corresponding subtitle-type media segments (having the timestamp of the requested media segment or a close timestamp) in order to extract the subtitles and use them as a supplementary textual description.

[0138] In an alternative embodiment, the textual description derived from subtitle-type media segments is used instead of transcripts. This alternative can, in particular, be used for the simplified generation of audio substitution segments.

[0139] Note that for a requested media segment, the substitution unit 164 can be configured to provide several substitution segments, for example, one or more substitution segments including one or more informational messages, a substitution segment including a countdown timer, and one or more substitution segments generated from the text description. The substitution unit 164 or the streaming agent 162 can choose one of them based on their availability (for example, if there is no text description, no segment is generated by AI) and / or based on the connection quality information obtained from the monitoring unit 163. For example, in the case of a known durational outage (tunnel), the countdown timer may be chosen, while a An uncontrolled interruption of the connection may lead to the selection of a generic waiting message.

[0140] Once the replacement segment is obtained, the streaming agent 162 is able to deliver it to the relevant content player 199 (which requested the media segment). Several embodiments are described below, implementing either a segment substitution at the URL of the requested media segment, or a URL modification in the content description manifest file to redirect the content player to the replacement segment, or management via a control manifest file.

[0141] Figure 5 illustrates, using a flowchart, the steps of a process according to embodiments implementing segment substitution for the normal URL of the requested media segment. This process can be implemented in response to the detection of insufficient connection quality, or in anticipation of a connection quality about to become insufficient (for example, tunneling in progress, or nearing the end of the media segment cache for the content being played).

[0142] These steps are implemented by streaming agent 162.

[0143] The process begins at step 500 where the streaming agent 162 determines (by reaction or anticipation) that it is / will not be able to retrieve and deliver a media segment of media content being played on a content player 199. This step may be subsequent to the receipt of a unicast request for the media segment (reactive approach) or prior to the request for the media segment because the track is being played (anticipation approach).

[0144] In step 510, the streaming agent 162 obtains, from the substitution unit 164, the substitution segment corresponding to the media segment that cannot be provided. Any type of substitution segment as described above is obtained here.

[0145] At step 520, the streaming agent 162 stores the replacement segment at the URL of the media segment in question. This allows the replacement segment to be sent in response to the unicast request, replacing the requested segment. Preferably, this storage is temporary—for a temporary substitution—either only for the time required to respond to the unicast request, or for a predefined period, or until a nominal connection state with the external CDN 110 is restored.

[0146] This embodiment is particularly suited to VOD content for which the content player loads the track description file of the media content played only once. Indeed, this embodiment does not require modifying the description files.

[0147] In the simplest case, the substitution segment is stored locally in cache unit 161, meaning that the track being read is a CDN track local instantiated by cache server 160 (corresponding for example to the dedicated domain name "local.server.com" in [Fig.2a]).

[0148] Figure 5a illustrates, using a flowchart, the steps of a process according to embodiments implementing a URL modification in the content-descriptive manifest file to redirect the content player to the replacement segment. As with Figure 5, this process can be implemented in response to the detection of insufficient connection quality, or in anticipation of connection quality about to become insufficient (for example, tunneling in progress, or nearing the end of the media segment cache for the content being played).

[0149] These steps are implemented by streaming agent 162.

[0150] The process begins at step 500 already described, followed by step 510 of obtaining the substitute segment corresponding to the media segment that cannot be supplied.

[0151] At step 530, the streaming agent 162 stores the replacement segment at a replacement URL different from the URL of the media segment in question. The replacement URL is preferably a local URL, i.e., of the cache unit 161.

[0152] At step 540, the streaming agent 162 modifies the manifest description file of the currently playing track to reference the replacement URL instead of the URL of the relevant media segment, before transmitting the manifest description file to the content player. This redirects the content player, without its knowledge, to the replacement segment. From now on, the content player will no longer send a segment request to the original URL of the desired media segment, but to the replacement URL for that media segment, resulting in the delivery of the replacement segment.

[0153] This embodiment is particularly suited to live content for which the content player frequently reloads the track description file in order to be able to retrieve the following media segments.

[0154] The track descriptive manifest file is modified for future segments in response to a first segment that could not be provided, or in anticipation of connection quality predicted to be insufficient in the near future.

[0155] Advantageously, when the track description file is reloaded over time, it may include an EXT-X-DISCONTINUITY tag (in HLS) at the beginning and end of the substitution period, in order to facilitate transitions (from a media segment to a substitution segment, and vice versa) for the content player 199. In DASH, the presence of a "Period" type metadata helps to facilitate transitions.

[0156] The embodiment is also adapted to the case where the track description file is provided to the content readers by the cache server 160 and is therefore stored in the manifest unit 169.

[0157] Figure 5b illustrates, using a flowchart, the steps of a process according to embodiments implementing content steering via a manifest file. As with Figure 5, this process can be implemented in response to the detection of insufficient connection quality, or in anticipation of connection quality about to become insufficient (for example, an approaching tunnel, or proximity to the end of the media segment cache for the content being played).

[0158] In these embodiments, the cache server 160, in addition to instantiating a local CDN to provide media content locally, also instantiates a local replacement CDN configured to provide replacement segments. This replacement CDN is implemented similarly to the local CDN; however, the segments it returns are replacement segments obtained by the replacement unit 164 and not the media segments of the media content.

[0159] Also, the media content track description file includes at least one track whose (substitute) segments are stored on the cache server 160 (for example, at the URL "local.server.com") at corresponding substitute URLs. This track is associated with a dedicated path identifier, which allows, via the driver manifest file 126, prioritizing or not the substitute segments or at least declaring them as the local substitute CDN to which to fall back (and thus obtain the substitute segments) in case of playback failure of the tracks from the external and local CDNs.

[0160] Figure 2b illustrates an additional track for using the local alternate CDN, to be added to the root manifest file 200 of Figure 2. Although only a single video track is shown, other track types (e.g., audio and subtitles) and / or a larger number of alternate CDN tracks can be declared. In the example in Figure 1, the video track is declared locally at minimum SD resolution (416x234) with the track manifest file "substitution.m3u8" stored on the local cache server "local.server.com". The local alternate CDN is associated with the path identifier "CDN-SUBS" for Content Steering.

[0161] The root manifest file 200 may already provide this alternative track at the server level 120. Alternatively, when the cache server 160 provides the root manifest file to the embedded user terminals, it may modify the file retrieved from the server 120 to include the alternative track before transmitting it.

[0162] In this example, we can thus find at least two CDNs in the root manifest files with different path identifiers: one (or more) CDNs corresponding to a local CDN to serve the original media segments (for example, the local CDN CDN-1 or the external CDN CDN-A) and a replacement CDN for serve the replacement segments (CDN-SUBS). In addition, tracks from the (external) CDN 110 can also be added to allow, in particular, the content player to continue playing content even when exiting the vehicle 150.

[0163] The process of [Fig.5b] is implemented by the streaming agent 162.

[0164] The process begins at step 500 already described, followed by step 510 of obtaining the substitute segment corresponding to the media segment that cannot be supplied.

[0165] At step 550, streaming agent 162 stores the substitution segment at the substitution URL of the local substitution CDN.

[0166] At step 560, the streaming agent 162 modifies the driver manifest file to indicate the path identifier "CDN-SUBS" of the fallback CDN so that the player receiving this driver file is able to at least switch over to the fallback CDN if it is unable to play the content from the other CDNs (local or external).

[0167] Preferably, the path identifier "CDN-SUBS" is specified first in the driver manifest file, forcing the content player to switch directly to the fallback segments. This is the case, for example, in [Fig. 4a], which shows a driver manifest file declaring only the fallback CDN.

[0168] At the end of the period requiring substitutions, the pilot manifest file is modified to return to the nominal situation, for example without the identifier "CDN-SUBS" but with the identifier of the local (CDN-1) or external (CDN-A) CDN serving the original media segments or both.

[0169] Preferably, the refresh rate of the driver manifest file is set to the duration of a media segment to provide maximum responsiveness. Of course, a refresh rate corresponding to several media segments is possible.

[0170] This embodiment can be efficiently implemented when the driver manifest file is served by the cache server 160 (by the manifest unit 169) to the embedded content readers.

[0171] Alternatively, a primary path identifier of a CDN serving the original media segments, by way of the path identifier of a local (CDN-1) or external (CDN-A) CDN, is specified before the fallback path identifier "CDN-SUBS" in the driver manifest file. This is, for example, the case in [Fig. 4b], which shows a driver manifest file declaring the local CDN CDN-1 first, then the fallback CDN CDN-SUBS in the event that the local CDN is unable to provide the requested segments. [Fig. 4c] shows another driver manifest file declaring the local CDN CDN-1 first, then the external CDN CDN-A, and finally the fallback CDN CDN-SUBS in the event that the content player fails over first. on the external CDN if the local CDN is no longer operational, and finally switches to the replacement CDN if the external CDN is also unavailable.

[0172] In these variants, there is no need to modify (step 560) the driver manifest file, the content player automatically switching to the alternative CDN.

[0173] The embodiments of [Fig.5b] natively facilitate transitions to the substitution segments, because they implement a mechanism integrated into the content reader 199.

[0174] In another embodiment related to [Fig. 5b], several alternate CDNs can be instantiated on the cache server 160 (see multiple embedded servers) to provide different types of alternate segments. For example, one alternate CDN can serve alternate segments generated by a generative AI engine. Another alternate CDN can serve alternate segments with a static message "No network due to tunneling." Another CDN can serve alternate segments with a static message "Currently unavailable channel, please select another channel." Yet another CDN can serve alternate segments with a countdown timer. These examples are not limiting.

[0175] Each alternate CDN has its own alternate path identifier (e.g., CDN-SUBS1, CDN-SUBS2, etc.), and tracks for multiple alternate CDNs are declared in the root descriptor file. Therefore, by specifying one of the alternate path identifiers in the driver manifest file, the 160 cache server is able to redirect the content reader to a particular type of alternate message to be displayed.

[0176] To this end, the streaming agent 162 can, at step 540, select one of the alternate path identifiers or an order of alternate path identifiers based on the connection quality information obtained from the monitoring unit 163 and / or the availability of alternate segments in the corresponding alternate CDNs, and then indicate the selected identifier or order in the driver manifest file,

[0177] This embodiment further provides the cache server 160 with the ability to change the type of message as the situation experienced by vehicle 150 changes.

[0178] Figure 4d shows, for example, a control manifest file declaring a first CDN as a fallback CDN, CDN-SUBS3 (for example, for AI-generated fallback segments), and a second CDN as a fallback CDN, CDN-SUBS1 (for example, for static message-type fallback segments). Content player 199 thus switches primarily to its fallback CDN. delivering AI-generated segments, and in the absence of these, switches to the substitute CDN delivering static messages.

[0179] Note that local and / or external CDNs can also be declared as shown in [Fig.4b] and [Fig.4c]. For example, the driver manifest file can declare the local CDN CDN-1, then the external CDN CDN-A, and finally the replacement CDN(s).

[0180] The embodiments of [Fig.5] (or 5a) and [Fig.5b] can coexist. For example, it may be possible to prioritize the delivery of replacement segments via the requested URLs (either the original URL - [Fig. 5] - or the modified URL - [Fig. 5a]). However, if the 162 streaming agent is unable to obtain the replacement segments and store them at the relevant URLs in time (timeout), the content player may switch to other (also faulty) quality levels until it reaches a replacement CDN ([Fig. 5b]).

[0181] Regardless of the embodiment, when an embedded content player 199 requests a media segment from the cache server 160, the latter returns either the requested media segment or a substitute segment without even knowing that the latter is not the original.

[0182] From a content reader's point of view, the reader plays the requested media segment without error, even if it is a substitute segment.

[0183] From a user's point of view, the video and / or audio and / or subtitles rendered by the content player no longer correspond to those of the original media content, but allow the user to continue playing (via AI-generated replacement segments) or to be informed of the situation, without error from the player.

[0184] Thus, since the content player is not aware of the connection problem occurring, it continues to play the content as if nothing had happened, and when the situation returns to normal, the correct video, audio, subtitle is returned to the user.

[0185] In summary, the invention makes it possible to improve the user experience, both for live and on-demand reading, by explaining the situation of a failed connection and why reading the original media content is not possible, possibly indicating via a countdown when the situation will be resolved, preventing the content player from falling into error, and / or possibly continuing reading via an AI-generated video, audio or subtitle.

[0186] The embodiments described above provide that the streaming agent 162 is entirely hosted in the cache server 160.

[0187] Other embodiments may involve relocating certain technical components to the user equipment (UE) rather than to the vehicle's shared infrastructure, as illustrated in [Fig. 6]. In particular, a streaming agent is embedded in the same user equipment (UE) as the content player. In other words, it is possible to manage the replacement of original media segments. by using replacement segments directly at the user device level. In particular, this approach can leverage the computing power of user devices to generate replacement segments using generative AI.

[0188] The system always includes a cache server 160 instantiating, via the streaming agent 162, a local unicast CDN for media segments corresponding to the content accessible locally in the cache unit 161. The streaming agent 162 is therefore always in charge of delivering the original media segments to user equipment.

[0189] The cache server 160 also includes the monitoring unit 163, whose connection quality information can be communicated (directly or via the streaming agent 162) to the embedded user equipment.

[0190] The UE user equipment includes, in addition to the content player 199, a proxy module 660 comprising a streaming agent 662 linked to a cache unit 661, a manifest unit 669, a monitoring unit 663, a substitution unit 664 and a description unit 665.

[0191] The streaming agent 662 instantiates a local CDN on the user's equipment (hereinafter referred to as the user CDN). The streaming agent 662 is responsible for retrieving the remaining media segments of a currently playing track from the local CDN instantiated by the embedded cache server 160, via the communication network 170. The retrieved segments are stored in the cache unit 661 for local (internal to the user's equipment) provisioning to the content player 199, via the instantiated user CDN. The streaming agent 662 therefore transmits a segment in response to each request from the content player 199.

[0192] Preferably, the streaming agent 662 undertakes to preload all missing media segments of a media content being played, either directly from the external CDN 110 or indirectly via the local CDN 160 (which itself obtains them from the external CDN 110).

[0193] Manifest unit 669, similar to unit 169, retrieves (directly from server 120 or via manifest unit 169) and modifies, if necessary, the descriptor files 125 and 126 to make them available locally to the content player 199. The modifications may include, similarly to what was described above, adding tracks referencing the URL of the local CDN to the user's equipment and / or modifying URLs in the root descriptor files, and modifying path identifiers in the driver manifest files. It should be understood that in the descriptor files, where in previous embodiments (Figures 1 to 5) the URL pointed to the local CDN of the cache server 160, here the URL points to the local proxy 660. URLs that pointed to an external CDN 110 continue to point to the external server.

[0194] Monitoring unit 663 retrieves in real time (directly or via streaming agent 162) the connection quality information generated by monitoring unit 163. Part of the processing of monitoring unit 163 may be offloaded to monitoring unit 663. For example, monitoring unit 163 may provide the connection status with CDN 110 and / or the bandwidth available with CDN 110 and / or the bandwidth allocated to a given media content, and it is monitoring unit 663 that determines one or more connection quality information from this information.

[0195] The monitoring service offered by the monitoring unit 163 (either autonomously or via the streaming agent 162) can be instantiated as a monitoring server and discovered by the user equipment UE using any service discovery protocol, for example the mDNS Bonjour protocol.

[0196] Description unit 665 is configured to retrieve (directly or via streaming agent 162) from CDN 110 or description unit 165 the text descriptions of media segments or media content. Storing the text descriptions in description unit 165 and retrieving them from description unit 165 offers the advantage of resilience to connection interruptions.

[0197] The substitution unit 664 is similar to the substitution unit 164 for generating and / or providing substitution segments to the streaming agent 662, as described above. As such, it can perform multimodal generation of substitution segments, i.e., also based on other media segments of the same content.

[0198] The streaming agent 662 can therefore implement the processes described above, in particular those of Figures 5, 5a and 5b.

[0199] Depending on the connection status as determined by the connection quality information, the 662 streaming agent either does not drive any media segment substitution or decides that one or more media segments should be substituted. Depending on the situation and embodiment, the 662 streaming agent may return the substitution segment in place of the media segment requested at the original URL, or it may modify the URL in the content descriptor manifest file to redirect the content player to the substitution segment, or it may redirect the content player to a substitution CDN (implemented in the 662 streaming agent) by modifying the driving manifest file.

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

[0201] If reference is mainly made to mobile environments such as public transport for which the quality of the communication link with the CDN external factors are likely to vary; other non-mobile collective environments, such as an airport, a train station, or even a private residence, may be involved.< / baseurl>

Claims

Demands

1. System (100) for streaming media content stored on a streaming server (110), the system comprising a streaming agent (162, 662) configured to obtain media segments from media content from the streaming server and to transmit a media segment in response to each media segment request by a content player (199), system in which the transmitted media segment is a substitute segment different from the media segment requested when a connection quality with the streaming server is insufficient.

2. System (100) according to claim 1, wherein the substitution segment is stored at the URL of the requested media segment.

3. System (100) according to claim 1, wherein the substitution segment is stored at a substitution URL different from the URL of the requested media segment, and a descriptive manifest file (125) of the media content is modified to reference the substitution URL instead of the URL of the requested media segment, before transmitting the descriptive manifest file to the content player.

4. System (100) according to claim 1, wherein the substitution segment is stored at a substitution URL declared in a media content descriptive manifest file (125), linked to a descriptive track associated with a substitution path identifier (CDN-SUBS) different from a primary path identifier (CDN-1, CDN-A) associated with another descriptive track (220, 221, 230, 231, 232, 233) referencing the URL of the requested media segment, and a driver manifest file (126) indicating the substitution path identifier is passed to the content player (199).

5. System (100) according to claim 4, wherein the alternate path identifier is indicated first in the driver manifest file or is indicated after the primary path identifier in the driver manifest file.

6. System (100) according to claim 4, wherein a plurality of alternative substitution segments are stored at respective substitution URLs and declared in the descriptive manifest file, linked to respective descriptive tracks associated with different substitution path identifiers, the streaming agent (162, 662) being configured to select an alternate path identifier or an order of alternate path identifiers based on connection quality information and / or the availability of an alternative alternate segment, and to indicate the selected identifier or order in the driver manifest file,

7. System (100) according to any one of claims 1 to 6, wherein the system comprises a description unit (165, 665) configured to obtain a textual description of the requested media segment or media content, and a substitution unit (164, 664) configured to generate a substitution segment from the textual description, and optionally from one or more other media segments of the media content.

8. System (100) according to any one of claims 1 to 6, wherein a substitution segment includes an informational message or a countdown, correlated with connection quality information.

9. System (100) according to the preceding claim, comprising a monitoring unit (163, 663) mounted in a vehicle (150) and configured to determine a duration of interruption of connection with the streaming server, said countdown being defined with respect to the duration of interruption.

10. System (100) according to any one of claims 1 to 6, wherein the streaming agent is configured to select a replacement segment from the following list, based on connection quality information and / or availability of replacement segments from the list: a replacement segment comprising an informational message, a replacement segment comprising a countdown timer, and a replacement segment generated from the textual description of the requested media segment or media content, and optionally also from one or more other media segments of the media content.

11. System (100) according to any one of claims 1 to 10, wherein the streaming agent (162) is hosted in a cache server (160) embedded in a vehicle (150), and the content player (199) is embedded in a user equipment (UE) connected to the cache server via a local area network (170) of the vehicle.

12. System (100) according to any one of claims 1 to 10, wherein the streaming agent is embedded in the same user equipment as the content player.

13. System (100) according to any one of the preceding claims, comprising a monitoring unit (163) embedded in a vehicle (150) and configured to determine connection quality information between the vehicle and the streaming server and transmit the connection quality information to the streaming agent.

14. A method for streaming media content stored on a streaming server (110), the method comprising, at the level of a streaming agent (162, 662), the following steps: obtaining media segments from media content from the streaming server; and transmitting a media segment in response to each media segment request by a content player, the method wherein the transmitted media segment is a substitute segment different from the media segment requested when the connection quality with the streaming server is insufficient.

15. Non-transient computer-readable recording medium on which a program is recorded for the implementation of the method according to claim 14, when this program is executed by a processor.

Images