Enhanced hybrid adaptive video streaming

Abstract

MABR streaming is eco-friendly because it prioritizes multicast broadcasts to a gateway agent (300) at the subscriber's premises. The gateway agent converts the retrieved multicast stream into a unicast stream and makes it available to video players (152) on the local network (150), using a local web server that it instantiates. Advantageously, the local web server is exposed on the local network with a dedicated domain name. This allows for the instantiation of an HTTPS web server, and therefore a secure one, with certificates accepted by the conventional browsers on user terminals. The manifest files reference the converted unicast stream, on this domain name, in addition to the native unicast streams typically served by public CDNs. Dynamic prioritization between these identical streams, converted unicast and native, using the Content Steering mechanism, ensures a smooth failover, without video interruption, for a user terminal. [Fig. 1]

Description

Title of the invention: Enhanced hybrid adaptive video streaming Scope of the invention

[0001] The present invention relates to the field of video streaming, of the adaptive hybrid type. Previous techniques

[0002] Current video streaming solutions combine traditional unicast video streaming mechanisms with more recent multicast streaming mechanisms. They are referred to as "hybrid" or "MABR" (for Multicast Adaptive Bitrate). Multicast streaming allows, in particular, the pooling of resources (network bandwidth) for a large number of end users, thereby substantially reducing energy consumption through less congestion on the Internet. Typically, multicast streaming is preferred for live events with large audiences.

[0003] Document WO 2016 / 147092 describes, for example, a hybrid adaptive bitrate (ABR) video streaming solution, combining these mechanisms.

[0004] In these systems, it is common to have one or more content delivery networks (CDNs) made up of content servers that provide content in the form of unicast streams. The available content is described in descriptive 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 unicast players, can then access this content via HTTPS unicast requests, that is, secure HTTP, to the addresses indicated in these files.

[0005] The same content is typically offered in several resolutions, qualities, and characteristics (audio and / or video, including accessibility settings for people with hearing and / or visual impairments), at the discretion of the video player, which dynamically "adapts" by switching, if necessary, from one resolution / characteristic / quality to another. Therefore, hybrid video streaming is called "adaptive" or "Multicast ABR."

[0006] Some of this unicast content is transcast (i.e., converted and then broadcast) into multicast streams by dedicated converter equipment. This is typically the case for a program with a large audience, for example a live event.

[0007] Due to the unicast nature of video players on user terminals, this multicast distribution requires the implementation of a multicast-to-unicast converter, generally at the level of a home gateway on the local network (such as a home Wi-Fi network) to which the user equipment belongs. The home gateway is typically an internet box (from an internet service provider) or a TV box, installed in a private residence or a public space (airport, train station, airplane, etc.). The home gateway sets up an HTTP server on the local network to deliver the converted content as a unicast stream. The converter can also, in some cases, simply be a software component present directly on the user terminal (typically, embedded directly in an application).

[0008] One of the challenges of these hybrid distribution systems is the management, at the level of users' local networks, of content from multicast distribution. Indeed, this content is generally only available on certain very specific local networks (home, airport, train station, etc.).

[0009] In particular, when moving, a user may cause their terminal to change communication networks, for example, switching from a home Wi-Fi network to a public mobile network (typically when leaving home). This network change is likely to introduce a video interruption visible to the user. This is especially true when the user is viewing the original multicast unicast stream and leaves the home environment. They then lose access to the home gateway that performs the multicast-to-unicast conversion, and therefore the corresponding unicast stream. This is also the case if the converter is located directly in the terminal, with the multicast stream only being available within the home environment. The video content is only recovered after the stream loss is detected and the stream is switched to a native unicast stream (i.e., one obtained from the CDN). The aforementioned WO 2016 / 147092 document does not offer a solution to this problem.

[0010] On the other hand, management at the level of domestic gateways can quickly become complex.

[0011] For example, in the same WO 2016 / 147092 document, the home gateway, designated M2AP proxy, must manipulate the "manifest" descriptive file during unicast data retrieval before switching to and converting the multicast stream. Manifest manipulation represents a load for the gateway and is prone to errors. Experience shows that any manifest manipulation outside the operator's platform poses a significant risk to platform reliability and quality, and presents a high risk of incidents for end users, in addition to shifting significant implementation and maintenance complexity to a large number of applications. Therefore, there is a desire to reduce, or even eliminate, this manipulation.

[0012] Furthermore, since recently (2021), web browsers have used HTTPS by default for connections to remote web servers, particularly those of CDNs. Video players are often implemented in these web browsers. Insecure access (i.e., simple HTTP) now requires a deliberate action from the user (accepting the insecure connection), thus degrading the user experience. However, setting up a secure local server (HTTPS) to avoid this constraint is complex, especially when dealing with a network of millions of home gateways.For example, it becomes necessary to obtain and load private certificates for each gateway, and it is unacceptable from a cybersecurity perspective to install publicly available domain certificates in so-called "unsecured" environments (such as those used by individuals), given the risks of theft and reuse of these certificates, which could then enable high-risk "man-in-the-middle" attacks for clients. Therefore, there is a need to simplify the secure management of the local unicast stream originating from the multicast stream. Description of the invention

[0013] To this end, the inventors observed that by exposing the local server with a dedicated public domain name, not used outside of the users' local networks, it is possible to establish secure connections (i.e., an HTTPS server) with public certificates directly accepted by web browsers and applications installed on the various operating systems, while also allowing the declaration of converted unicast streams (resulting from multicast) without modification of the manifest by the home gateways. Improved (simplified) management of multicast streams by the gateways is thus achieved.

[0014] Furthermore, the inventors have observed that the Content Steering mechanism developed by Apple (https: / / developer.apple.com / streaming / HLSContentSteeringSpecification.pdf) can be cleverly repurposed to manage a smooth transition (i.e., without video interruption for the user) in the event of a network change, with an extremely simplified implementation in the various web and installed applications.

[0015] Also, the invention proposes a hybrid adaptive video streaming system comprising: equipment for distributing manifest files describing content accessible via a public unicast content distribution network, and at least one gateway agent on a local network that a user video player accesses, the gateway agent comprising a multicast-to-unicast stream converter and a local web server making the converted unicast stream available to the user video player (on the local network), characterized in that the local web server is exposed on the local network with a dedicated domain name, and the manifest files reference the converted unicast stream, on that domain name.

[0016] The term "content delivery network" refers to one or more public CDNs that typically make content available, with segments accessible via unicast requests. The term "gateway agent" refers to any software component or piece of equipment on a local network that has access to a public network (via a physical gateway if necessary) to retrieve the multicast stream and thus acts as a gateway, at least for this stream, to the home network. This could be a local HTTP proxy, an IP gateway, an internet box, a TV box, a router, a software component running on a user terminal hosting a video player, etc. By definition, the "local network" includes its own IP address, not accessible on public networks (e.g., the internet), to which it can be connected via a gateway (hosting the above-mentioned agent or not).

[0017] The term "local server" refers to a server accessible only on the local network. By definition, the same server, i.e., having the same IP address, can be implemented within a different local network. Therefore, it is traditionally considered inadvisable, given the risks to computer security, to obtain public certificates (e.g., SSL / TLS) for domain names that have a public existence for local servers.

[0018] If the local server is capable of making available to video players and user terminals several unicast streams from several multicast streams received by the gateway agent, it is also envisaged that this agent may implement several local servers (then associated with different dedicated domain names) to process different converted unicast streams.

[0019] Such a local server is said to be "exposed with a dedicated domain name" when it is associated, within the local network, with a domain name typically reserved for public websites (the Internet). Such exposure consists, for example, of configuring a local DNS (Domain Name System) server, generally implemented in software by the gateway agent or other dedicated equipment on the local network. The local IP address of the local server is registered in this local DNS server in association with the dedicated domain name, to ensure the redirection of unicast requests from the video player targeting the domain name to the local server.

[0020] By "referencing the converted unicast stream, on the domain name", it should be understood that the URLs on which the segments of the stream content are accessible are URLs formed from the domain name.

[0021] Thus, the invention forces the use of a dedicated domain name, different from the public "unicast" domain name (for the public unicast broadcasting network), for a The local server allows for its indexing within the manifest files distributed by the public CDN, even before the local server is instantiated and the multicast stream is converted. Therefore, gateway agents no longer need to manipulate manifest files, nor do they need public domain name certificates to perform "routing" to the local network when necessary. Consequently, managing streaming via the multicast stream is simplified and secured.

[0022] Correspondingly, the invention also relates to a device (for example, a home gateway) comprising a gateway agent capable of being connected to a local network accessed by a user video player, the device comprising: a multicast agent capable of receiving a multicast stream from a public network, a converter of the multicast stream into a unicast stream, and a local web server making the converted unicast stream available to the user's video player, characterized in that the gateway agent is configured to expose the local web server on the local network with a dedicated domain name.

[0023] The invention also relates to a hybrid adaptive video streaming method in a video streaming system comprising equipment for distributing descriptive manifest files of content accessible from a public unicast content distribution network, and at least one gateway agent on a local network accessed by a user video player, the method comprising the following steps: convert, via the gateway agent, a multicast stream into a unicast stream, and make the converted unicast stream available to the user's video player via a local web server in the gateway agent. the process being characterized in that it comprises: the gateway agent configuration to expose the local web server on the local network with a dedicated domain name, and the configuration of the broadcast equipment to broadcast manifest files that reference the converted unicast stream, on this domain name.

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

[0025] The local server exposed (locally) with a domain name still has no public existence / exposure. Ideally, it can be reserved to prevent its reservation by a third party, which would open the door to cyberattacks. This advantageously allows the same domain name to be used for a network of gateways. domestic, typically for Internet boxes deployed in subscribers' homes. Also, in some embodiments, the system includes a plurality of gateway agents associated with a plurality of respective local networks which user video players access, and the local web server of each gateway agent is exposed with the same domain name.

[0026] Of course, it is possible to organize a network of home gateways (typically Internet boxes) into subgroups of home gateway (agents), each subgroup being assigned a respective domain name to expose its local web server. The subgroups can be formed according to various criteria, for example, according to the access provider, a geographical area, or a subscription taken out with a given access provider, etc.

[0027] In one embodiment, the local web server is an HTTPS server. Advantageously, providing a domain name to the local web server makes it easy to obtain public certificates that are accepted or natively recognized by web browsers or media players on user terminals. Furthermore, implementing the invention does not require any specific configuration of the user's terminal.

[0028] In one embodiment, the broadcasting equipment broadcasts a control manifest file defining a priority order between the converted unicast stream referenced on the domain name and one or more identical contents referenced, in the content descriptive manifest files, under a different path.

[0029] By "identical content", we mean content defined in the manifest files with the same characteristics or attributes (resolution, quality, encoded, frequency, audio, subtitles, etc.).

[0030] Such a driver manifest file, separate from the content-descriptive manifest files, advantageously allows the media player to smoothly switch (without image interruption) to native unicast content from the CDN when the user terminal changes networks and leaves the local network managed by the gateway agent. Indeed, the media player switches to identical content and does not need to determine a different resolution / quality (for example, a different DASH representation), which would cause image interruption. It also allows a user session (known as "channel surfing") to be initiated quickly, even before the gateway agent is ready to expose the multicast content as unicast, and then to switch smoothly back to the gateway agent once it is ready to expose the converted multicast resources.

[0031] The control manifest file allows access management to different identical contents without modification of the descriptive manifest files of the contents.

[0032] In a particular embodiment, the content-descriptive manifest files include prioritization attributes associated with different paths including the The domain name and the control manifest file provide an ordered list of prioritization attributes. In this configuration, the control manifest file can remain concise (only an ordered list), simplifying its management and transmission.

[0033] In a specific embodiment, the broadcasting equipment is configured to declare, in the driver manifest file, alternative (e.g., identical) content to the converted unicast stream as having priority over the converted unicast stream, and upon detection of a local web server startup event, to modify the driver manifest file so as to declare the converted unicast stream as having priority.

[0034] This arrangement ensures an optimal user experience and efficient network usage, through immediate access to content (efficient channel surfing) and a smooth switchover (without image interruption) to multicast content. It is understood that, in this case, the driver manifest file can be specific to the user terminals / players on a given local network.

[0035] According to a specific feature, the broadcasting equipment is configured to receive, from the user video player, a request to obtain the driver manifest file, the request including an indication to start the local web server, and the local web server start event includes one of: - receiving the start indication, and - sending, in response to the request and to a gateway agent manager, an instruction to start the local web server.

[0036] In a particular embodiment, the steering manifest file conforms to the Steering Manifest defined in the specification "HLS Content Steering Specification, vl.2bl".

[0037] In one embodiment, referencing the converted unicast stream on the domain name in the content manifest files includes an indication of a replacement server in the public unicast content delivery network capable of serving content identical to the converted unicast stream. This provision allows for a rapid switchover to the correct replacement server in the event of a local web server malfunction. By providing the manifest files on demand to user video players, it is also possible to customize the replacement server, for example, to load balance across multiple servers in the CDN(s), or to select the highest-performing CDN for that particular user, for example, in the event of a multicast stream malfunction.

[0038] In an embodiment using the driver manifest file, the system further includes a multicast content delivery device configured to switch the content of a broadcast multicast stream from a first channel to a second channel, system in which the descriptive manifest files for content include, for both channels, the same referencing of the converted unicast stream, on the domain name, and The manifest file distribution equipment is configured to modify a driver manifest file associated with the first channel before said switchover so as to remove any priority to the converted unicast stream, and to modify a driver manifest file associated with the second channel after said switchover so as to declare a priority (preferably the highest priority) to the converted unicast stream.

[0039] The term "channels" should be understood as any separately referenced channels or services between which a user can switch (channel surfing) to view different content.

[0040] This configuration is particularly advantageous for optimizing the use of the public network by reducing calls and unicast streams, while maintaining a satisfactory user experience (without image interruptions). Content switching can, for example, occur at the end of a high-audience event (on the first channel), typically a live event, or upon detection of a new audience distribution between channels (the second channel attracting more viewers after the switchover).

[0041] Indeed, through the prioritization of the driver manifest files, a user video player viewing content from the multicast stream of the first channel is switched to a native unicast stream (from the public CDN) by removing the priority on the converted unicast stream. Simultaneously (immediately after the switchover), another user video player viewing native unicast content from the second channel (from the public CDN) is switched to the converted unicast stream by adding the priority for this converted unicast stream in the driver manifest file of the second channel.

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

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

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

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

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

[0047] 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: Fig. 1

[0048] [Fig.1] schematically represents a hybrid adaptive video streaming system according to one or more embodiments of the invention; Fig. 2a

[0049] [Fig.2a] illustrates an example of a descriptive file or root “manifest” associated with a multimedia service, according to one or more embodiments of the invention; Fig. 2b

[0050] [Fig.2b] illustrates an example of a descriptive file or "manifest" track corresponding to a track of a multimedia service, according to one or more embodiments of the invention; Fig. 2c

[0051] [Fig.2c] illustrates an example of a Content Steering file; Fig. 2d

[0052] [Fig.2d] illustrates an example of a descriptive file or "manifest" track corresponding to a unicast stream converted from a multimedia stream and served by a local web server exposed with a domain name, according to one or more embodiments of the invention Fig. 3

[0053] [Fig.3] schematically illustrates a domestic gateway equipped with an agent gateway, according to one or more embodiments of the invention; Fig. 4

[0054] [Fig.4] schematically illustrates general streaming steps at the level of a user video player, according to one or more embodiments of the invention; Fig. 5

[0055] [Fig.5] schematically illustrates general operating steps of an agent gateway for managing multicast streams, according to one or more embodiments of the invention; Fig. 6a

[0056] [Fig.6a] illustrates a variant of the manifest file corresponding to the unicast stream converted, according to one or more embodiments of the invention; and Fig. 6b

[0057] [Fig.6b] illustrates another variant of the manifest file track corresponding to the stream Unicast converted, according to one or more embodiments of the invention. Detailed description

[0058] Hybrid adaptive broadcasting, or "MABR," is an eco-friendly streaming solution in that it attempts to promote the use of multicast for one or more pieces of content, preferably those with high audience reach. Indeed, multicast allows, with a single stream over the public network, the replacement of multiple individual unicast streams for several subscribers watching that content. By using multicast over the public network (the Internet) for some content, congestion on the public network is reduced, as is its associated energy consumption.

[0059] Hereafter, the term "native unicast stream" refers to these individual unicast streams obtained, in a conventional way, from public content delivery networks, otherwise known as CDNs for ("Content Delivery Networks").

[0060] Hybrid adaptive video streaming nevertheless requires the conversion of each multicast stream into a unicast stream for delivery to the end user (generally a user video player). This unicast stream resulting from the conversion of a prior multicast stream is hereafter referred to as the "converted unicast stream." This delivery to the end user is generally local, either at the user's home or in a restricted area (airport, airplane, train station, etc.), via a web server on a local network at the home / restricted area.

[0061] The instantiation of the local web server is managed by an agent, hereinafter referred to as the "gateway agent," which can be installed on a physical home gateway in the home / limited space. This is typically the case with an internet box in a private home.

[0062] One or more embodiments of the invention provide for the assignment of a dedicated domain name to the local web server. Since this domain name is not publicly exposed but only on the local network, it can be used identically on several local networks, each equipped with a gateway agent according to the invention. These could be the local networks of multiple subscribers, all equipped with an internet box from the same internet service provider offering a video streaming service.

[0063] The manifest files describing the content of the video streaming service can then reference, in the usual way, the native unicast streams accessible from public CDNs, but also reference, using the dedicated domain name, the converted unicast stream(s) accessible from each subscriber's local web server. This makes it possible to generate these manifest files for multiple subscribers, at the level of a dedicated piece of equipment on the public network, without manipulation by the gateway agent.

[0064] Figure 1 illustrates a hybrid adaptive video streaming system for an implementation of the invention. Only the equipment and functions relevant to a description of the invention are shown, for the sake of simplicity. Nevertheless, those skilled in the art will recognize the additional equipment or functions that are typically used in the operation of such a system.

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

[0066] The system 100 includes a streaming preparation center or "back-end" 110, one or more public unicast content delivery networks or "CDN" 120, an Internet-type communication network 130, an alternative communication network, for example a mobile telephone network 140, a multitude of subscriber environments 150 (and associated local networks), and optionally (according to the embodiments described later) equipment managing home subscriber gateways 160.

[0067] The streaming preparation center 110 includes, in a known manner, content 111, a unicast packager 112, a multicast converter / packager 113 and a descriptive file server 114.

[0068] Multimedia content 111 is stored locally in encoded and preferably encrypted form. Therefore, there exists beforehand (not illustrated) one or more sources of initial content, and multimedia encoders capable of encoding initial content at different resolutions or qualities. For example, initial content could be a film, a documentary, a series episode, a live event (sporting or otherwise), etc.

[0069] The Figure illustrates three resolutions of the same initial content, namely an FHD (very high resolution) version, an HD (high resolution) version, and an SD (low resolution) version. Hereafter, the term "content" refers to any file of any of these different resolutions or qualities. In other words, the initial content (film, documentary, sporting event, etc.) can give rise to N (integer) content accessible in the streaming system 100.

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

[0071] Generally, part of the content 111 is stored permanently in a database, while another part of the content is generated (encoded) on the fly, typically during live events.

[0072] The remainder of the description focuses primarily on a single initial content encoded according to the three resolutions above. Of course, similar considerations apply to all content available in the 100 system (derived from multiple initial content), regardless of the criteria (resolution, quality, etc.) for content variation (creating the 1 to N alternatives of the same initial content).

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

[0074] As is known, the content 111 feeds the unicast packager 112, which packages the encoded content into unicast media segments. The packager fragments the encoded content and generates, for each alternative content (in the sense of different resolutions or qualities, etc.), data packets, or "media segments," that satisfy a unicast streaming format. Typically, the media segments of the same media content have the same filename, supplemented, for example, by an incrementing counter.

[0075] These media segments are stored, under these names, in the memory of servers of a public unicast content delivery network, also known as a "CDN". The Figure illustrates three CDNs for unicasting the media segments corresponding to the content accessible in the streaming system shown. Of course, a different number of one or more CDNs is possible. Since these CDNs play similar roles, they will be referred to collectively as "the CDN" in the remainder of this document.

[0076] For live streaming, the created media segments can be stored for a limited time, allowing the user to "rewind". This rewind mechanism is also known as "startover".

[0077] In the MABR streaming context, the streaming preparation center 110 includes the multicast converter / packager 113, which manages the multimedia delivery of one or more of the content items 111. In the illustrated example, the alternative FHD resolution content is retrieved via internal unicast streaming from the unicast packer 112. A simplified file describing the tracks available for multicast can be provided upstream by the unicast packer 112 to allow the multicast converter / packager 113 to retrieve them. Alternatively, the content can be retrieved directly from storage 111.

[0078] The multicast converter / packager 113 is a transcaster in that it converts the content 111 into multicast datagrams and ensures their transmission to users who have subscribed to the corresponding multicast stream. The multicast converter / packager 113 can also handle user subscription requests to the various multicast streams it broadcasts. Alternatively, this subscription management can be performed by another module, or even by another server device.

[0079] Although only a single multicast content or stream is illustrated for clarity, the multicast converter / packager 113 can handle the multicast distribution of a large number of streams. Furthermore, although the multicast converter / packager 113 is shown within the back-end center 110, it can be implemented in a multicast server belonging to a third party other than the one managing the back-end center 110, typically in a multicast server of the access provider serving the illustrated subscribers.

[0080] The manifest file server 114 stores the description files 115 of the various contents stored on the CDNs 120 and accessible to users. These files are generated, for example, by the unicast packager 112. Typically, the manifest file server 114 is accessible on the CDN itself (one of the CDNs shown), allowing users to retrieve the manifest files upon request.

[0081] As is known, a root description file is generated for each multimedia service (e.g., a TV channel). This description file is called a "manifest" or MPD in the MPEG DASH protocol ("Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP" - trade name) and a "master playlist" in the HLS protocol (for "HTTP Live Streaming"). The root description file is generated only once for static content (e.g., a video-on-demand service) or is generated dynamically for variable content (e.g., a live-streamed event).

[0082] An example of a root 200 description file is shown in [Fig. 2a] in HLS format. This file has been 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 starting with the # tag) some of which define a plurality of tracks that correspond to content available on CDN 120. Each track consists of a line of metadata specifying attributes of said track and a second line indicating the URL of an associated file.

[0083] In this example, track 220 defines French audio content, details of which are provided in the file "audiol_FR_cdnl.m3u8". Similarly, track 221 defines original language audio content, details of which are provided in the file "audiol_QAA_cdnl.m3u8".

[0084] Track 230 defines low-resolution video content (640x360), the details of which are provided in the file "chainel_SD_cdn2.m3u8". Similarly, track 231 defines high-resolution video content (1280x720), the details of which are provided in the file "chainel_HD_cdnl.m3u8". Track 232 defines very high-resolution video content (1920x1080), the details of which are provided in the file "chainel_FHD_cdnl.m3u8". Track 233 defines the same very high-resolution video content (1920x1080), the details of which are provided in the file "chainel_FHD_cdn2.m3u8". The two tracks 232 and 233 therefore correspond to the same content (same resolution), however accessible on two different 120 CDNs (which would be visible through the URLs indicated in the corresponding m3u8 files).

[0085] Each alternative track in the descriptive file 200 therefore corresponds to a second content descriptive file "m3u8", or "track descriptive file", which indicates the web URL addresses where the different media segments constituting the content / track can be obtained by unicast request.

[0086] Figure 2b illustrates an example of a simplified "m3u8" descriptive file 250. It comprises a large number of descriptive elements 260 corresponding to respective media segments, each descriptive element specifying the relative URL where the corresponding media segment is stored. In other words, this file is basically a playlist of URLs.

[0087] The last descriptive element 260 corresponds to the last "available" media segment of the stream. The preceding descriptive elements correspond to the "previous" media segments. Their presence in the descriptive file 250 allows the user's video player to rewind ("startover"). The depth of "startover" (i.e., the number of descriptive elements indicated) is adjustable.

[0088] The description files 200, 250 are obtained by a user video player by requesting them from server 114. In a known manner, the user video player requests the root description file 200 of a multimedia channel or service that it accesses, selects one of the desired qualities / resolutions (according to various criteria) and requests the descriptive file 250 of the corresponding content. It is then that it can query the CDN 120 (unicast requests) to obtain the successive segments.

[0089] The descriptive file server 114 also stores Content Steering descriptive files 116. The Content Steering mechanism is described for example in the file https: / / developer.apple.com / streaming / HLSContentSteeringSpecification.pdf. It allows, among other things, prioritizing access to one CDN 120 over another.

[0090] The Content Steering 116 file operates in conjunction with an attribute called "PATHWAY-ID" specified at the track level of the root 200 descriptor file in order to prioritize one track over another identical track in terms of resolution / quality / etc., and indirectly to prioritize one 120 CDN (mentioned in the track's m3u8 file) over another 120 CDN (mentioned in the m3u8 file of the other equivalent track). In other words, the "PATHWAY-ID" attribute is simply a track prioritization attribute, and therefore indirectly prioritizes the paths to the 120 CDNs.

[0091] The name of the Content Steering 116 file to be retrieved for a given multimedia service (therefore for a root manifest file 200) and the URL where to retrieve it are specified in the descriptive element 210 at the head of the root manifest file 200 ([Fig.2a]).

[0092] Figure 2c illustrates an example of a Content Steering file, in which list 270 declares the attribute "CDN1" as having higher priority than the identifier "CDN2".

[0093] Also, when, as illustrated in [Fig. 2a], two very high-resolution FHD content files (tracks 232 and 233) are declared with different PATHWAY-ID attributes 242 and 243, one equal to "CDN1" and the other to "CDN2", the user video player using this root description file 200 must prioritize content 232 ("CDN1") over content 233 ("CDN2"), by retrieving the associated description file 250 "chainel_FHD_cdnl.m3u8". Of course, names other than "CDN1" and "CDN2" can be used since these are simply identifiers taken from list 270 to define an order.

[0094] Note that in the absence of a Content Steering file 116, an attribute is defined by default as the priority within the descriptive element 210. In the example, "CDN1" 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.

[0095] The Content Steering 116 file is advantageously updated over time, for example, to direct certain user video players to one CDN 120 rather than another, and thus balance the load between CDNs. Since the Content Steering 116 file is obtained by the user video player on request, it can easily be customized. to a particular player or group of players, to prioritize or not the converted unicast stream over native unicast streams. Typically, a user video player reloads the Content Steering 116 file at regular intervals, as indicated in the TTL element (300 seconds or 5 minutes in the example in the Figure).

[0096] The same Content Steering 116 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 115. 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.

[0097] Returning to [Fig. 1], CDNs 120 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 to user video players upon request.

[0098] 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 user video player is fitted to a user terminal of the telephone type connected to the network 140.

[0099] Figure 1 illustrates three subscribers for clarity, although there may be a different number. For example, an internet service provider may manage a customer base of several million subscribers.

[0100] A subscriber environment 150 constitutes a local network connected to the Internet 130 via a physical gateway 151, typically an Internet box. The local network can then accommodate a multitude of user terminals 152, each equipped with a video player. For the purposes of this document, "subscriber environment" and "local network" are used interchangeably under the same reference 150.

[0101] A user terminal 152 can take the form of a smartphone, tablet, laptop or desktop computer, or a connected device (television, watch, camera, etc.). A user terminal 152 is connected to the local network via a wired connection (Ethernet cable) or wirelessly (Wi-Fi). A user terminal 152, typically a phone or tablet, can also be connected to the mobile network 140. Such a terminal therefore has the ability to switch from one network (local) to the other (mobile).

[0102] Access to the streaming service by user video players can be achieved using a dedicated playback application running on the user terminal 152 or through a web browser on the user terminal 152 which runs said video player. For example, a phone 152 connected to the mobile phone network 140 accesses the streaming service in the usual way by unicast requests to the CDN (to retrieve the manifest files 115, 116 and then the media segments).

[0103] Since the video players are unicast only, the multicast streams broadcast by packager 113 are converted locally into unicast streams and made available on the local network via a local unicast web server. For this purpose, a gateway agent is implemented on the local network.

[0104] This gateway agent is a software component running on any local network equipment (downstream of the physical gateway 151), typically in a fixed device (Wi-Fi access point, TV box) or in one of the user terminals 152. It has access to the Internet 130 and the local network 150. For the sake of simplicity in the following explanations, this gateway agent is considered to be implemented in the physical gateway 151. Also, in the following, the term "gateway" is used as an equivalent of the gateway agent according to the invention.

[0105] As explained above, the invention relates to easy management, by the gateway agent, of multicast streams in order to allow their access on the local network 150 by user terminals 152, while ensuring a smooth video transition (without video interruption) when the user terminal leaves the local network 150 to connect to the mobile network 140.

[0106] To achieve this, the local web server is exposed on the local network with a dedicated domain name, which will not be publicly exposed. This allows the converted unicast streams to be referenced in the manifest 115 files, on this domain name.

[0107] Figure 3 illustrates the functions of a domestic gateway 151 equipped with the agent gateway 300. The gateway agent described here can, alternatively, equip another device on the subscriber's local network.

[0108] Typically, the home gateway 151 includes, in addition to the gateway agent 300, a communication interface C0M1 for communicating on the Internet network 130 and a communication interface COM2 interfaced with the local network. The COM2 interface may physically consist of several interfaces (multiple Ethernet ports, a Wi-Fi access point, etc.). Thus, the home gateway 151 performs IP packet routing between the Internet network 130 and the local network.

[0109] The gateway agent 300 includes a multicast client 310, a multicast-to-unicast converter 320, a web server 330, a local DNS server 340, an SSL agent 350, a unicast agent 360 and a manifest agent 370. These different modules can advantageously be implemented in software (software blocks).

[0110] The multicast client 310 subscribes (using conventional techniques) to one or more multicast streams broadcast by module 113. In continuous operation, it retrieves the Datagrams are successively transmitted for each multicast stream to which it subscribes. Such a client is already known and is therefore not described in further detail. In particular, classic mechanisms for subscribing to a multicast stream are advantageously implemented.

[0111] The resulting datagrams are fed into converter 320, which converts them into media segments conforming to a (local) unicast streaming. Again, this conversion is already known and is therefore not described in further detail.

[0112] The media segments are then stored within the web server 330, which makes them available on the local network. The web server 330 is set up by the gateway agent 300 with a dedicated domain name and can be a simple standard DASH or HLS server intended for local use only.

[0113] The dedicated domain name, the fully qualified domain name (FQDN) "www.canal-plus-multicast.com" in the example, allows the local IP address of gateway 151 to be separated from the addressing of the local web server 330. Also, this same domain name can be used for the local web server 330 of each of the subscriber local networks 150.

[0114] Exposing 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 gateway 151) in the local DNS server 340, instantiated by the local agent. The table below illustrates an example of a DNS record for the local web server 330, available locally at the IP address 192.168.1.1 of the home gateway 151. FQDN TTL Type Class RData www.canal-plus-multicast.com 3600 A Internet 192.168.1.1

[0115] Optionally, the dedicated domain name is also registered in one (or more) other local DNS server instantiated in the subscriber's local network 150. Thus, any request issued by a user terminal 152 to this domain name will be rerouted, within the local network, to the web server 330.

[0116] Correspondingly, since the use of the web server 330 is only local, the dedicated domain name is not publicly exposed, i.e. on the Internet network 130. This is possible by reserving the domain name without registering it in the DNS servers of the network 130.

[0117] While the local web server can be a simple HTTP server (for example, if implemented directly in a mobile streaming application – in a user terminal 152), it is preferably set up as an HTTPS server, i.e., secure, ideally HTTPS / 2 or HTTPS / 3 with TLS 1.3 or later. To achieve this, gateway 151 can be provided with a 331 certificate, typically SSL (for Secure Sockets Layer) or TLS (for Transport Layer Security), issued by an authority a public certificate for the domain name used. This same 331 certificate will equip all gateways of the 150 subscribers using the same domain name. This is why it is not publicly exposed.

[0118] The public certificate authority used preferably has a root authority included in the certificate store of web browsers and operating systems on the market. This is the case, for example, with Let's Encrypt (trade name) for generating SSL or TLS certificates. In this way, a user does not have to validate the public certificate associated with the domain name used when accessing the local web server 330 via their dedicated domain name.

[0119] The management of the public certificate that user terminals 152 must retrieve on the local network 150 is carried out by the SSL agent 350. In particular, the SSL agent 350 is also in charge of the certificate renewal protocol, for example the ACME (for Automatic Certificate Management Environment) protocol in the case of Let's Encrypt, so that the certificates are automatically and regularly renewed within the local network 150.

[0120] The optional unicast agent 360 is configured to retrieve, via unicast from CDN 120, content that the multicast client 310 could not retrieve, typically during the startup of gateway agent 300 and therefore multicast client 310. Indeed, unicast broadcasting allows a user session to be initiated (known as "zapping") more quickly than retrieving datagrams from the multicast stream, and allows the retrieval of resources that would have already been broadcast via multicast, or containing too many transport errors.

[0121] The optional manifest agent 370 allows the manifest files to be retrieved so that the unicast agent 360 can request the CDN 120 appropriately to retrieve the desired content, i.e. it must find the native unicast content track of the same quality / resolution / etc as that of the multicast stream to be supplemented.

[0122] Agent manifest 370 can be omitted when unicast agent 360 is able to know the retrieval URL of a missing media segment. For example, the retrieval URL can be based on that of a unicast request received by gateway agent 300 from user video player 152, in which the base path to the local web server 330 is replaced by a default (predefined) path or by the path to a replacement or retrieval server specified in the unicast request received from the user video player.

[0123] The dedicated domain name is used by the streaming preparation center 110 to prepare the content description files 115. In particular, these files 115 reference the converted unicast stream on this domain name. In other words, the manifest files referencing the "multicast" media segments of the converted unicast stream are accessible on the public unicast CDN, although referencing a The server is only accessible locally. This configuration differs from traditional techniques.

[0124] Thus, user video players obtaining these content description files 115 and wishing to access the track of the converted unicast stream (from multicast) will send their unicast requests to this domain name, and consequently to the web server 330.

[0125] The same and unique referencing is therefore used for several subscribers 150, without the gateway agent 300 having to adapt the content description files 115 to the local web server 330.

[0126] Returning to [Fig. 2a], track 234 also declares very high-resolution video content (1920x1080), therefore of the same resolution / quality as that of tracks 232 and 233, details of whose media segments are provided in the file "chainel_FHD_multicast.m3u8". Thus, the root manifest file 200 declares the track available for multicast twice (or more), on the native unicast domain (via tracks 232 / 233) and on the local converted unicast domain (via track 234).

[0127] Track 234 of the "multicast" media segments is also assigned the attribute 244 PATHWAY-ID "MULTICAST" (of course, other names are possible). This attribute allows the streaming system 100, via the Content Steering files 116, to direct one or more user video players to track 234 from the multicast stream or to one of the native unicast tracks 232, 233. The example in [Fig. 2c] prioritizes the multicast stream / track 234 over the unicast streams / tracks 232, 233.

[0128] It should be noted that the Content Steering file is compatible with a 100-streaming system in which the 150 LANs (or subnets) use a different dedicated domain name. In this case, the 200 root manifest file declares an equivalent track for each different domain name (thus indicating different "m3u8" files), and each track can have a different PATHWAY-ID attribute, for example, "MULTICAST1", "MULTICAST2", etc. Simply declaring these multiple attribute values ​​in list 270 of the Content Steering file is sufficient. For example, the list [MULTICAST 1,MULTICAST2,...,MULTICASTN,CDN1,CDN2] allows prioritizing the converted unicast stream in each LAN. Indeed, tracks labeled "MULTICASTx" that do not correspond to the LAN (i.e., with the appropriate domain name) will be ignored until the track corresponding to the video player's LAN is selected.

[0129] It should also be noted that the telephone 152, connected to the mobile network 140 and not to the local network 150, is unable to connect to the local web server 330. Therefore, if the root description file 200 instructs it to use the multicast track 234 as a priority, since this track is not accessible to it, It uses the next priority track, namely track 232 corresponding to the PATHWAY-ID label "CDN1".

[0130] The video player of a user terminal 152 connected to the local network 150 can, however, access the multicast track 234. It then retrieves, from the manifest server 114, the file “chainel_FHD_multicast.m3u8” corresponding to this track.

[0131] [Fig.2d] illustrates an example of the descriptive file “chainel_FHD_multicast.m3u8” associated with multicast track 234, in a simplified version, on the same scheme as the file in [Fig.2b].

[0132] As can be seen from descriptive elements 280, the URL for accessing each media segment of the converted unicast stream (from the multicast stream) is indicated on the domain name "www.canal-plus-multicast.com" assigned to the local web server 330. The media segments of this track 234 from the multicast stream will therefore be retrieved on this local web server.

[0133] Figure 4 schematically illustrates general streaming steps at the level of a user video player installed on a user terminal 152, according to one or more embodiments. These operations are applicable whether the user terminal 152 is connected to the local network 151 (and therefore has access to the local web server 330) or not. The described process begins when the video player switches to a new multimedia service (e.g., a new channel).

[0134] At step 400, the video player sends a request to the manifest server 114 to retrieve the root manifest file 200 of the media service. Also at step 400, it obtains this file 200.

[0135] After reading descriptive element 210, at step 405, the video player sends a request to the manifest server 114 to retrieve the Content Steering file 116 from the media service. Also at step 405, it obtains this file 116.

[0136] The received request allows the manifest server 114 to know the user's public IP address (therefore the home gateway 151) and the desired multimedia service.

[0137] In one embodiment, upon receiving the request, the manifest server 114 can send an instruction to the gateway manager 160 to start the appropriate multicast client 310 for the user. This could be a request to start the multicast client 310 corresponding to the multimedia service, from the gateway agent 300 located at the obtained public IP address. This request to the manager 160 therefore contains this information (public IP address and desired multimedia service), for example, passed as parameters in the URL. In response to this request, the manager 160 sends an instruction to the gateway agent 300 to start the multicast client 310 handling the multicast stream(s) of the desired multimedia service.

[0138] This embodiment allows the manifest server 114 (knowing when the multicast client 310 will be launched) to prioritize native unicast streams over converted unicast streams before the local web server 330 is fully operational (i.e., the multicast client 310 is launched). To do this, the Content Steering file 116 of the multimedia service can be specific to the public IP address (i.e., the local network 150 in question) and declare a native unicast stream (e.g., track 232) identical to the converted unicast stream as having priority over the converted unicast stream (track 234). This is typically the case if list 270 indicates the following order: [CDN1, CDN2, MULTICAST]. Then, in response to the multicast client 310 activation request, the back-end center 110 modifies the Content Steering file 116 to declare the converted unicast stream as having priority. This is typically the case with list 270 of [Fig.2c].

[0139] The video player then performs, at step 410, the selection of a track, taking into account the associated attributes (quality, resolution, etc.), the prioritization of tracks in the Content Steering 116 file (via the PATHWAY-ID attributes) and various other criteria (network status, screen size, etc.). The selection of such a track remains standard practice for someone skilled in the art.

[0140] This selection may lead the reader to choose track 234 of the converted unicast stream, served by local web server 330.

[0141] At step 415, the video player sends a request to the manifest server 114 to retrieve the manifest file track 250 corresponding to the selected track, for example the file "chainel_FHD_multicast.m3u8" for track 234. Still at step 415, it obtains this file 250.

[0142] In the optional step 420 according to one embodiment of the invention, the video player determines whether the target server for this track is the local web server 330 and whether the gateway agent 300 has not yet launched the multicast client 310 handling the multicast stream corresponding to this track. The determination of the local web server can be based on the URLs specified in the file 250. The determination of the launch of the multicast client 310 can be based on a request history or on a status message broadcast by the gateway agent 300 on the local network. In the assertion, the video player can send (step 425) a request to the gateway agent 300 to start the multicast client 310 handling the multicast stream corresponding to this track. The request can specify said track.

[0143] Alternatively, the determination can be based on the PATHWAY-ID attribute of the selected track, as specified in the root manifest file 200. If it is equal to "MULTICASAST" for the selected track, then step 425 is executed. In this variant, steps 420 and 425 can be performed before step 415 so as to launch the multicast client 310 as early as possible.

[0144] In one embodiment, if the multicast client 310 is launched by the video player, the next request to obtain the Content Steering file 116 from the manifest server 114 may include an indication of the multicast client 310's launch. This indication advantageously allows the manifest server 114 to favor native unicast streams over converted unicast streams before the local web server 330 is fully operational (i.e., the multicast client 310 is launched). In particular, the media service's Content Steering file 116 may be specific to the public IP address (i.e., the relevant local network 150) of the video player and declare a native unicast stream (e.g., track 232) identical to the converted unicast stream as having priority over the converted unicast stream (track 234).This is typically the case if list 270 indicates the following order [CDN 1, CDN2, MULTICAST]. Then, upon detection of the indication in the request to obtain the Content Steering file, the back-end center 110 modifies the Content Steering file 116 to declare the converted unicast stream as having priority. This is typically the case with list 270 in [Fig. 2c].

[0145] If the negative of step 420, the process continues to step 430.

[0146] At step 430, the video player sends a unicast request to the URL of the desired media segment, specified in the retrieved manifest file track 250. This request can therefore be directed to the local web server 330 for a media segment from the converted unicast stream or to the CDN 120 for a media segment from a native unicast stream. Also at step 430, it obtains this media segment, which it can then display to the user.

[0147] Continuously, the video player reloads (415) the manifest file track 250 from the manifest server 114 to determine the next media segment, which it requests via unicast (430) from the corresponding server before receiving and displaying it. This continues until an end event (test 435) occurs. Such an event could, for example, be a change in streaming conditions forcing the player to change tracks (returning to step 410 in this case) or a change in the media service (returning to step 400 in this case).

[0148] It should also be noted that since the Content Steering 116 file is retrieved regularly, the reader can loop back to step 405 on this occasion, in order to evaluate whether a different track (than the current one) should be selected.

[0149] Thus, with the mechanisms of the invention, a user video player retrieves a standard root manifest file 200, which references several unicast content delivery networks, one of which is the local web server 330. Depending on the content of the retrieved Content Steering file 116, the user video player plays video segments originating either from a conventional CDN (native unicast stream) or from the local web server (converted unicast stream). In other words, the invention allows the use of conventional video players.

[0150] Fig. 5 schematically illustrates general operating steps of the gateway agent 300 for managing the multicast flow, according to one or more embodiments.

[0151] Streaming native unicast streams from CDN 120 to user terminals 152 does not involve gateway agent 300. Also, these steps begin when the gateway agent receives (step 500) a unicast request from a video player for the converted unicast stream, served by the local web server 330.

[0152] In one embodiment (corresponding, for example, to the case of step 425 above or to the gateway manager user 160), the gateway agent 300 may have received (optional step 499) a request to start the multicast client 310, which handles the multicast stream of a desired converted unicast track. In this case, the gateway agent starts (still in step 499) the multicast client 310. Otherwise, it is started in step 510 in response to the unicast streaming request received in step 500, if it is not already running (test 505).

[0153] When the multicast client 310 is launched, it listens to the multicast IP address of the stream to which it is subscribed, demultiplexes and corrects errors in the datagrams (via error correction code). The conversion of these received datagrams into media segments is performed in parallel. The media segments are then stored in the local web server 300 for a limited time (depending, for example, on the proposed "startover" depth).

[0154] At step 515, the gateway agent 300 determines whether the local web server 330 is ready to deliver the converted unicast stream. The gateway agent 300 therefore determines whether the requested converted media segment is available in the cache of the local web server 330. This may not be the case, particularly when the multicast client 310 is launched, because retrieving the correct multicast datagrams by this client 310, converting them into media segments by the converter 320, and preparing them in the local web server 330 takes time.

[0155] If so (typically if gateway agent 300 has been receiving and converting the multicast stream for a while), local web server 330 returns the media segment requested at step 520.

[0156] If not, the local web server 330 should ideally honor the video player's request. To do this, the gateway agent implements a procedure to retrieve the media segment requested by native unicast streaming from the CDN 120, in a manner similar to what a video player does in a conventional way ([Fig.4]).

[0157] Thus, in step 400 already described above, gateway agent 300 retrieves the root manifest file 200 of the multimedia service, and then in step 405, the corresponding Content Steering file 116. These steps are carried out by manifest agent 370. These two files allow it to select (410) the alternative priority track (same resolution / quality / etc.) for the requested converted unicast stream. In the example of the In Figures 2a and 2c, gateway agent 300 selects track 232 labeled "CDN1". In step 415, it (via manifest agent 370) retrieves the manifest file for track 250, "chainel_FHD_cdnl.m3u8" in the example, allowing it to identify the media segment corresponding to the one targeted by the request in step 500. It can then obtain (step 430), via a unicast request to the URL indicated in the manifest file for track 250, the requested media segment. Step 430 is handled by unicast agent 360.

[0158] Other variations of steps 400-435 can be implemented. For example, gateway agent 300 can be preconfigured to retrieve media segments from a dedicated CDN server. In another variant, the gateway agent 300 can retrieve, from a management server, the unicast URLs where to request the missing media segments.

[0159] In one embodiment, the gateway agent 300 retrieves, in unicast from the CDN 120, a plurality of media segments (over a defined depth) preceding the requested media segment in order to offer the "startover" mechanism to the video player.

[0160] Following the retrieval 430 of the requested media segment, it is sent, at step 520, to the video player as a response to its initial request.

[0161] Figure 6a illustrates a variant of the manifest file track 250 corresponding to the converted unicast stream, according to one or more embodiments. In this variant, the media "startover" segments of the converted unicast stream are indicated as missing in order to force the video player to perform the "startover" as a native unicast stream. This configuration notably allows for a substantial reduction in the storage resources required at the local web server level, particularly when the gateway agent handles several multicast streams simultaneously, and for optimized performance, using a "direct" route to the CDNs.

[0162] Compared to the file in [Fig. 2d], certain descriptive elements (preferably the oldest ones—therefore the first ones listed in the file) are marked with the tag #EXT-X-GAP 600 described in the HLS standard. In the illustrated example, only the six most recent segments are accessible on the converted unicast stream served by the local web server 330. The others (i.e., to go further back in the streamed program) are accessible only via a native unicast stream. The video player must then switch to the next priority CDN 120, as defined in the root manifest file 200, to obtain these other "startover" segments via unicast.

[0163] Figure 6b illustrates another variant of a track 250 manifest file corresponding to the converted unicast stream, according to one or more embodiments. In this variant, which may or may not be combined with the embodiment of Figure 6a, the referencing, in the track 250 manifest files, of the converted unicast stream on the domain name includes an indication of a server. replacement, in the public unicast content distribution network, capable of serving content identical to the converted unicast stream.

[0164] As illustrated, this information can be included in the URL of media segments. It can therefore vary from one media segment to another or designate different CDNs from one media segment to another. The 630 "7CDN2" designation in Figure 1 is based on the PATHWAY-ID attribute and allows the CDN2 of [Fig. 1] to be designated, for example. Of course, more precise designations, such as a URL, can be used. Other solutions could be considered for indicating the repair CDN to be used.

[0165] Alternatively, the indication can be provided in place of the #EXT-X-GAP 600 tag for "startover" media segments declared as missing, by declaring the media segments on the CDN for native unicast delivery.

[0166] Also, in the event of a missing media segment or no response to a unicast request to the local web server 330, the user video player can switch to CDN2, i.e. retrieve the manifest file track 250 corresponding to the track (equivalent to the converted unicast stream) stamped "CDN2" and request, via unicast, the media segments from CDN2.

[0167] This indication therefore allows bypassing the priorities defined in the applicable Content Steering file 116. Since this file can be customized for each local network 150, the back-end center 110 can dynamically adjust the load on the different CDNs 120.

[0168] Exposing the local web server 330 on the local network with a dedicated domain name and referencing the converted unicast stream directly in the original manifest 115 files under this domain name allows, in conjunction with the prioritization under the Content Steering file, a smooth video switchover from the converted unicast stream to an equivalent native unicast stream, or vice versa. A stream switchover is sometimes necessary, for example, when a user viewing content (a converted unicast stream) on their phone at home leaves the house, as their phone switches to the mobile network 140, which no longer provides access to the local web server 330.

[0169] The management of Content Steering files 116 from several multimedia services (e.g., channels) by the back-end center 110 also enables optimized content switching within the same multicast stream. Such optimized switching helps reduce network congestion and associated power consumption, especially since the goal is to multicast the most-watched content at any given time.

[0170] For example, a live sporting event on channel 1 may be watched by a majority of users. At the end of this live event, users stop watching channel 1 and / or switch to another channel. The content broadcast on channel 2 may then be the one with the largest audience. As the resources of Multicast broadcasts (e.g., multicast IP addresses) are rare, so it is particularly interesting to be able to switch content from channel 1 to channel 2 in the multicast stream, without video impact for users, while forcing users of the multicast channel onto their locally converted unicast stream.

[0171] Of course, other failover criteria besides the end of a live event can be implemented. For example, live audience measurement (statistics) of channels or associated connections can be used to dynamically adapt the multicast stream content to the majority of users. Typically, the most requested native unicast stream content at a given time (e.g., in the last few minutes) in the CDN 120 is switched over as a multicast stream.

[0172] To this end, one or more embodiments of the invention provide that the root manifest files 200 associated with the two channels 1 and 2 both declare a converted unicast stream (multicast) track 234, in addition to a native unicast stream track 232 / 233. In other words, these two root manifest files include the same referencing of the converted unicast stream, on the domain name, even though they concern two channels (and therefore, a priori, two different contents). Also, at any given time, the Content Steering files 116 should only indicate the converted unicast stream (attribute PATHWAY-ID="MULTICAST") in list 270 for the single channel whose content is broadcast in the multicast stream.

[0173] Furthermore, as the switchover point approaches, the back-end center 110 modifies the Content Steering file associated with channel 1 to remove all priority from the converted unicast stream. The PATHWAY-ID="MULTICAST" is removed from the list 270. Until this point, video players requesting FHD content from channel 1, when they are on one of the local networks 150, retrieve the media segments via unicast from their local web server 330. When they retrieve the modified Content Steering file, they switch to a native (equivalent) unicast stream from the CDN 120, because the PATHWAY-ID=''MULTICAST'' no longer has priority.

[0174] At that time, no Content Steering 116 file references the PATHWAY-ID="MULTICAST". Therefore, no video player can access its local web server 330.

[0175] It is then possible to change the content of the multicast stream by feeding converter / packer 113 with the new FHD content from channel 2.

[0176] Then, the back-end center 110 modifies the Content Steering file associated with channel 2 to declare a priority (preferably the highest priority) for the converted unicast stream. The PATHWAY-ID="MULTICAST" is added to list 270. Until this point, video players requesting the FHD content from channel 2 only access it via native unicast from the CDN 120. When they retrieve the modified Content Steering file and are on one of the local networks 150, they switch to the stream (equivalent) converted unicast served by local web server 330, because PATHWAY-ID="MULTICAST" has become the priority.

[0177] As can be seen from the above, the invention therefore makes it possible to manage a MABR streaming, at one or more subscribers of one or more Internet access providers, without video interruption when a user terminal changes networks, compatible with conventional video players.

[0178] 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.< / baseurl>

Claims

Demands

1. Hybrid adaptive video streaming system (100) comprising: external broadcasting equipment (114) to a local subscriber network (150), configured to broadcast manifest files (115) describing content (111) accessible from a public unicast content broadcasting network (120), and at least one gateway agent (300) on the local subscriber network (150) to which a user video player (152) has access, the gateway agent comprising a multicast-to-unicast stream converter (320) and a local web server (330) making the converted unicast stream available to the user video player, characterized in that the local web server (330) is exposed on the local subscriber network (150) with a dedicated domain name, and the manifest files (115) broadcast by the external broadcasting equipment (114) reference the converted unicast stream, on that domain name.

2. System (100) according to claim 1, comprising a plurality of gateway agents (300) associated with a plurality of respective subscriber local networks (150) to which user video players are accessed, and the local web server (330) of each gateway agent is exposed with the same domain name.

3. System (100) according to claim 1 or 2, wherein the local web server is an HTTPS server.

4. System (100) according to any one of the preceding claims, wherein the external broadcasting equipment (114) broadcasts a driver manifest file (116) defining a priority order between the converted unicast stream referenced on the domain name and one or more identical contents referenced, in the content-descriptive manifest files (115), under a different path.

5. System (100) according to claim 4, wherein the content-descriptive manifest files (115) include prioritization attributes (242, 243, 244) associated with different paths including the domain name, and the driver manifest file (116) provides an ordered list (270) of prioritization attributes.

6. System (100) according to claim 4 or 5, wherein the broadcasting equipment (114) is configured to declare, in the driver manifest file (116), alternative content to the stream unicast converted as having priority over the converted unicast stream, and upon detection of a local web server startup event, to modify the driver manifest file so as to declare the converted unicast stream as having priority.

7. System (100) according to claim 6, wherein the external broadcasting equipment (114) is configured to receive, from the user video player (152), a request to obtain the driver manifest file (116), the request including a local web server start indication, and the local web server start event includes one of: - receiving the start indication, and - sending, in response to the request and to a gateway agent manager (160), a local web server start instruction.

8. System (100) according to any one of claims 4 to 7, wherein the steering manifest file (116) conforms to the Steering Manifest defined in the specification "HLS Content Steering Specification, vl.2bl".

9. System (100) according to any one of the preceding claims, wherein the referencing, in the content-descriptive manifest files (115), of the converted unicast stream on the domain name includes an indication (630) of a replacement server, in the public content unicast network (120), capable of serving content identical to the converted unicast stream.

10. A system (100) according to any one of the preceding claims, further comprising a content multicast delivery device (113) configured to switch the content of a broadcast multicast stream from a first channel to a second channel, a system in which the content-descriptive manifest files (115) include, for both channels, the same referencing of the converted unicast stream, on the domain name, and the external delivery device (114) of manifest files is configured to modify a driver manifest file (116) associated with the first channel before said switch so as to remove any priority to the converted unicast stream, and to modify a driver manifest file associated with the second channel after said switch so as to declare a priority to the converted unicast stream.

11. Device (151, 152) comprising a gateway agent (300) capable of being connected to a subscriber local network (150) which a user video player (152) accesses, the device comprising: a multicast agent (310) capable of receiving a multicast stream from a public network external to the subscriber local network (150), which external public network broadcasts manifest files (115) describing content (111) accessible from a public unicast content broadcasting network (120), a converter (320) of the multicast stream into a unicast stream, and a local web server (330) making the converted unicast stream available to the user video player, characterized in that the gateway agent is configured to expose the local web server (330) on the subscriber local network (150) with a dedicated domain name referencing, in the manifest files broadcast by the external public network, the converted unicast stream.

12. A hybrid adaptive video streaming method in a video streaming system (100) comprising a broadcasting device (114) external to a subscriber local network (150) and configured to broadcast manifest files (115) describing content (111) accessible from a public unicast content broadcasting network (120), and comprising at least one gateway agent (300) on the subscriber local network (150) accessed by a user video player (152), the method comprising the following steps: converting, by the gateway agent, a multicast stream into a unicast stream, and making the converted unicast stream available to the user video player via a local web server (330) in the gateway agent, the method being characterized in that it comprises: configuring the gateway agent (300) to expose the local web server (330) on the subscriber local network (150) with a dedicated domain name,and the configuration of the external broadcasting equipment to broadcast manifest files (115) that reference the converted unicast stream, on that domain name.

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

Images