WO2021209706A1 - Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau - Google Patents

Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau Download PDF

Info

Publication number
WO2021209706A1
WO2021209706A1 PCT/FR2021/050638 FR2021050638W WO2021209706A1 WO 2021209706 A1 WO2021209706 A1 WO 2021209706A1 FR 2021050638 W FR2021050638 W FR 2021050638W WO 2021209706 A1 WO2021209706 A1 WO 2021209706A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
encoding
network
digital content
load
Prior art date
Application number
PCT/FR2021/050638
Other languages
English (en)
Inventor
Olivier GASTE
Hervé Marchand
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2021209706A1 publication Critical patent/WO2021209706A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • TITLE Management of access to digital content accessible by adaptive progressive download and encoded using a variable bit rate encoding method, depending on a network load
  • the field of the invention is that of digital multimedia content, namely digital audio and / or video content. More specifically, the invention relates to the preparation of digital content accessible according to a technique known as adaptive progressive downloading, and encoded according to a variable rate encoding method, depending on a network load.
  • the terminal generally sends a request to a server, indicating the content chosen, and in return it receives a stream of digital data relating to this content.
  • the terminal is suitable for receiving this digital content in the form of multimedia data and for rendering it back.
  • This restitution consists in providing the digital content at the level of the terminal in a form accessible to the user.
  • data received corresponding to a video is generally decoded, then restored at the level of the terminal in the form of a display of the corresponding video with its associated soundtrack.
  • the digital content will be assimilated to a video and the reproduction by the terminal, or consumption by the user of the terminal, to a display on the screen of the terminal.
  • the distribution of digital content is often based on client-server protocols of the HTTP family (standing for “Hyper Text Transport Protocol”).
  • the progressive downloading of digital content makes it possible to transport and consume the data in real time, that is to say that the digital data is transmitted over the network and returned by the terminal as it goes. and as they arrive.
  • the terminal receives and stores part of the digital data in a buffer memory before returning them.
  • This distribution mode is particularly useful when the bit rate available to the user is not guaranteed for the real-time transfer of the video, depending for example on the fluctuation of the available bandwidth.
  • Adaptive progressive downloading in English HTTP Adaptive Streaming, abbreviated HAS, furthermore makes it possible to broadcast and receive data in different qualities corresponding for example to different bit rates. These different qualities are described in a parameter file available for download on a data server, for example a content server.
  • this description file makes it possible to select the right format for the content to be consumed according to the available bandwidth or the storage and decoding capacities of the client terminal. This type of technique makes it possible in particular to take account of the variations in bandwidth on the link between the client terminal and the content server.
  • the MPEG-DASH standard (for English “Dynamic Adaptive Streaming over HTTP", in French “dynamic adaptive streaming over HTTP") is an audiovisual broadcast format standard on the Internet. It is based on the preparation of the content in different presentations of varying quality and speed, cut into short segments (of the order of a few seconds), also called “chunks”. Each of these segments is made available individually by means of an exchange protocol. The primarily targeted protocol is HTTP, but other protocols (eg FTP) can also be used. The organization of the segments and the associated parameters are published in a manifesto in XML format.
  • the principle underlying this standard is that the MPEG-DASH client makes an estimate of the bandwidth available for the reception of segments, and, depending on the filling of its reception buffer, chooses, for the next segment to be loaded, a representation whose bit rate: ensures the best possible quality, and allows a reception delay compatible with the uninterrupted rendering of the content.
  • HAS adaptive progressive download
  • VOD video on demand
  • Replay delayed broadcasting of television programs
  • Network PVR type offers for “Network Personal Video Recorder”, ie a digital content recording service, carried out by the content provider itself rather than at the end user's home.
  • Such devices are conventionally connected to the HDMI port of a television set and communicate, for example by Wi-Fi ® connection , with another device of the home communication network connected to an extended communication network (for example a smart phone of the type smartphone, connected to a 4G mobile network), in order to reproduce, on the television, the multimedia content received by a compatible software application.
  • Wi-Fi ® connection for example a Wi-Fi ® connection
  • an extended communication network for example a smart phone of the type smartphone, connected to a 4G mobile network
  • CBR Constant Bit Rate
  • VBR Very Bit Rate
  • MBR maximum bit rate
  • ABR Average Bit Rate
  • MBR unlike the “chunks” of very little animated scenes (for example black images with very little movement), which will be encoded according to a lower encoding rate, for example lower than the average ABR rate.
  • a lower encoding rate for example lower than the average ABR rate.
  • This VBR variable rate encoding technique is advantageous in that it makes it possible to reduce the average size in kilobytes of the video segments, while maintaining the same level of quality perceived by the user: a reduction is thus observed on average. 50% of network bandwidth usage, compared to CBR encoding, for the same video quality. It is easily understood that, for a content encoded according to a CBR technique, the apparent encoding rate exposed in the content description file, or manifest, is the constant encoding rate which applies for all the content, depending on the level of quality offered.
  • the multimedia reproduction terminal then chooses to download the segments at one of these three quality levels: for the same quality level, all the downloaded segments are of the same size in kilobytes.
  • a first option consists in exposing in the manifest file, for each content quality level, the maximum MBR encoding rate of the video segments: this first option is advantageous in terms of reducing the consumption of bandwidth in the network. distribution of HAS content. Indeed, the display of the maximum MBR bit rate in the manifest file leads the multimedia stream reader terminal to overestimate the size of the segments to be downloaded, compared to their effective size. It is this MBR value which is used by the multimedia stream reader terminal to calculate the chunk recovery time, and thus determine the level of quality proposed in the manifest file to which it can claim. This therefore leads the terminal multimedia stream player to be selected at a level of quality that is probably lower than that to which it could actually claim in practice, and therefore, ultimately, for the operator, a reduction in the consumption of the bandwidth and a reduction in the load of the distribution network.
  • a second option consists in exposing in the manifest file, not the maximum MBR rate, but, for each content quality level, the associated average ABR encoding rate. This second option advantageously makes it possible to improve the quality perceived by the user.
  • the invention responds to this need by proposing a method for managing access to digital content accessible by adaptive progressive download (HAS) by a multimedia stream reader terminal connected to a distribution network for said content.
  • Digital content is associated to a digital content description file, comprising a list of time segments (Cli @ Nj) of the content each associated with several quality levels of the content.
  • the temporal segments of the digital content are encoded according to a limited variable rate (VBR) encoding method, for a given quality level, by a maximum encoding rate (MBR) of said segments for said level.
  • VBR limited variable rate
  • MLR maximum encoding rate
  • such a method comprises a determination of at least one load criterion (ChNet) of the distribution network, and an adaptation, as a function of said at least one determined load criterion, of the apparent encoding rates exposed in the description file.
  • the adaptation of an apparent encoding rate, for a given quality level assigns to said apparent encoding rate a value between the maximum encoding rate for said given quality level and a corresponding average encoding rate to an average of the encoding rates of the segments of said content for said given quality level.
  • the invention is based on a completely new and inventive approach to the management of access to digital content made available to user client terminals for adaptive progressive downloading of the HAS type, when these contents are encoded according to a technique.
  • VBR variable rate encoding is based on a completely new and inventive approach to the management of access to digital content made available to user client terminals for adaptive progressive downloading of the HAS type, when these contents are encoded according to a technique.
  • the technique of the invention proposes, on the contrary to changing over time the apparent bit rate exposed in this description file, as a function of one or more load criteria of the content distribution network.
  • This apparent bit rate can advantageously take a value between the average bit rate ABR, to improve the quality perceived by the user, and the maximum bit rate MBR, to reduce the consumption of resources in the network.
  • Network load is understood here to mean all of the load generated on the content servers and also on the consumption of bandwidth in the operator's network.
  • the apparent encoding rate takes a value equal to (MBR-ABR) / 100 * ChNet + ABR, where MBR designates the maximum encoding rate of the segments of the content for said given quality level, ABR designates the average encoding rate of the content segments for said given quality level and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion.
  • MBR designates the maximum encoding rate of the segments of the content for said given quality level
  • ABR designates the average encoding rate of the content segments for said given quality level
  • ChNet designates a value, between 0 and 100, assigned to said at least one load criterion.
  • the ChNet load criterion takes the value 0
  • the load is zero; when it takes the value 100, the load is maximum.
  • the technique according to the invention makes it possible to favor the improvement of the video quality restored to the client, without however optimizing the reduction in the load on the network.
  • the technique according to the invention makes it possible to gradually
  • the operator constructs the manifest files by indicating as the bit rate of each quality level the value of the average bit rate ABR.
  • the improvement in video quality provided to the customer is maximized, without limiting the use of bandwidth.
  • the operator's network being little used, it is not necessary to optimize the flows.
  • the operator exposes in the manifest files an apparent rate value which increases to approach the maximum MBR rate when the value of the ChNet load criterion approaches 100.
  • such a method of managing access to content comprises a measurement of a load of the distribution network and the value assigned to said at least one load criterion of the network is a function of the measurement.
  • the operator constantly monitors and monitors the network load linked to the distribution of HAS content, and adapts its construction strategy for manifest files, depending on the load measured. This ensures optimum adaptability of the content proposal made to customers as a function of the actual load of the network, and the best possible compromise between the video quality perceived by the user and the consumption of resources for the operator.
  • LIVE content is open content for which the client terminal must download the description file very regularly, generally every minute.
  • the real-time adaptation of the apparent bit rates exposed in the manifest file therefore has a direct impact on the choice, by the multimedia stream reader terminal, of the quality to which it can claim for downloading the video content segments.
  • said at least one network load criterion also takes account of at least one parameter belonging to the group comprising: a network load prediction; electricity consumption from the network; a period of the year; a schedule for updating network equipment.
  • the invention also relates to a computer program product comprising program code instructions for implementing a method as described above, when it is executed by a processor.
  • the invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the method for preparing a digital content according to the invention, as described above.
  • Such a recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium can be a transmissible medium such as a signal.
  • electrical or optical which can be routed via an electrical or optical cable, by radio or by other means, so that the computer program it contains can be executed remotely.
  • the program according to the invention can in particular be downloaded over a network, for example the Internet network.
  • the recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned display control method.
  • the invention also relates to a platform for managing access to digital content accessible by adaptive progressive download (HAS) by a multimedia stream reader terminal connected to a content distribution network.
  • the digital content is associated with a description file of the digital content, comprising a list of time segments (Cli @ Nj) of the content each associated with several quality levels of the content.
  • the time segments of the digital content are encoded according to a variable rate (VBR) encoding method limited, for a given quality level, by a maximum encoding rate (MBR) of the segments for the given level.
  • VBR variable rate
  • MRR maximum encoding rate
  • such a platform comprises a computer capable of adapting the apparent encoding rates exposed in the description file, as a function of at least one load criterion (ChNet) of the distribution network.
  • the computer is able to assign to an apparent encoding bit rate, for a given quality level, a value between the maximum encoding bit rate for the given quality level and an average encoding bit rate corresponding to an average of the bit rates. encoding segments of the content for the given quality level.
  • this platform can be dissociated from the platform for making the content available, the structure and operation of which are not affected by the technique of the invention.
  • the value assigned by the computer to the apparent encoding rate for a given quality level is equal to (MBR-ABR) / 100 * ChNet + ABR, where MBR designates the maximum encoding rate of the segments of the content for the given quality level, ABR designates the average encoding rate of the content segments for the given quality level and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion.
  • such a platform for managing access to digital content comprises a module for measuring a load of the distribution network and the computer assigns to said at least one load criterion of the network a value which is function of the measured load.
  • a network load criterion also takes account of at least one parameter belonging to the group comprising: a network load prediction; electricity consumption from the network; a period of the year; a schedule for updating network equipment.
  • FIG 1 presents a progressive download architecture on a mobile network based on the use of adaptive streaming according to the invention
  • FIG 2 illustrates in the form of a schematic flowchart the different steps of the process for preparing a content according to one embodiment of the invention
  • FIG. 3 illustrates the principle of evolution of the encoding bit rate of a content encoded according to a variable bit rate technique of the VBR type
  • FIG 4 shows the hardware structure of a platform for preparing digital content implementing the method of Fig 2.
  • the general principle of the invention is based on the adaptation of the description files of the digital contents accessible by HAS progressive download and encoded according to a VBR variable rate encoding technique, in order to change the apparent rate exposed in these description files. , according to one or more load criteria of the distribution network.
  • FIG. 1 A progressive download architecture based on the use of adaptive streaming according to the invention is now presented in relation with FIG. 1.
  • the terminal 3, for example an intelligent telephone of the “smartphone” type and the terminal 4, for example a tablet, are, in this example, connected to an extended communication network 1, forming a digital content distribution network. They communicate with a terminal 8, for example an HDMI key connected to a television 5.
  • a digital content server 2 is located according to this example in the wide area network (WAN, 1) and receives for example digital television content channels from a broadcast television network, not shown, and / or videos to demand, and makes them available to client terminals.
  • WAN wide area network
  • Client terminals 3 and 4 can enter into communication with content server 2 to receive one or more content (films, documentaries, advertising sequences, etc.).
  • content server 2 can receive one or more content (films, documentaries, advertising sequences, etc.).
  • the terminals 3, 4 have their own characteristics in terms of decoding capacity, display, etc. In a progressive adaptive download context, they can adapt their requests to receive and decode the content requested by the user at the quality that best suits them. In our example, if the contents are available at apparent speeds 512 kb / s (kilobits per second) (Resolution 1, or level 1, noted NI), 1024 kb / s (N2), 2048 kb / s (N3) and that the client terminal has a bandwidth of 3000 kb / s, it can request the content at any rate below this limit, for example 2048 kb / s.
  • the content number i is denoted “Ci @ Nj” with the quality j (for example the j-th quality level Nj described in the description file).
  • the client terminals 3, 4 receive the data coming from the extended network 1 and ensure their decoding, and possibly their reproduction on their screen, or their transmission to the HDMI key 8 for reproduction on the television screen 5.
  • the Decoders can be found elsewhere in the network, in particular at the level of an element of STB type (standing for Set-Top-Box) (not shown) associated with a television set.
  • the terminal 3, 4 or 8 firstly retrieves an address from the description document 7 of the desired content (for example, C1).
  • this file is a manifest type file according to the MPEG-DASH standard (denoted “C.mpd”) and we will refer indifferently, depending on the context, to the expression “description file” or “ manifest ”.
  • This file can be retrieved directly from an Internet server of the extended network 1, or be already on the terminal at the time of the request.
  • MPD MPEG-DASH
  • NI 512 kb / s
  • N2 1024 kb / s
  • N3 2048 kb / s
  • This simplified manifest file describes digital content in XML syntax (from the English “eXtended Markup Language”), comprising a list of content in the form of fragments conventionally described between an opening tag ( ⁇ SegmentList> ) and a closing tag ( ⁇ /SegmentList>). Cutting into fragments makes it possible in particular to adapt finely to fluctuations in the bandwidth.
  • Each fragment corresponds to a certain duration (“duration” field) with several quality levels and allows to generate their addresses (URL - Uniform Resource Locator). This generation is done in this example using the elements “BaseURL” (“HTTP://server.com”) which indicates the address of the content server and “SegmentURL” which lists the complementary parts of the addresses of the different fragments. :
  • the terminal proceeds to obtain the fragments via a download at these addresses.
  • this download takes place here, traditionally, through an HTTP URL, but could also take place through a universal address (URI) describing another protocol (dvb: // my content segment for example).
  • URI universal address
  • the HDMI key 8 is connected to the television 5 by connection to the HDMI port of the latter, and is used to restore, on the screen of the television 5, a content C1, described in a manifest file 7.
  • the content C1 can be a television program broadcast live or delayed, or a video on demand, or any other multimedia content.
  • the HDMI key 8 can be connected via WiFi ® directly to the tablet 4 or to the smart phone 3, through which it can access the extended communication network 1, for example via a 4G connection.
  • the HDMI 8 key can also be controlled by the user by means of the smart phone 3, on which a software application for controlling the HDMI 8 key is installed.
  • the content fragments obtained by the 3 smartphone or tablet 4 are for example transmitted to the HDMI ® wireless key 8, which controls display on the TV screen 5 to return to the user.
  • FIG 2 illustrates in the form of a simplified flowchart the different steps implemented according to one embodiment of the invention to prepare the manifest file 7, when a content C1 is intended to be encoded using a variable bit rate encoding technique, VBR.
  • VBR variable bit rate encoding technique
  • the multimedia stream reader terminal retrieves the manifest file 7 at very regular time intervals, for example every minute or so, according to a known technique.
  • the adaptation of the apparent bit rate of the content exposed in this manifest file 7, as a function of a load criterion, is therefore particularly efficient and directly followed by effect, for the choice of bit rate and quality level made by the reader terminal.
  • multimedia streams for example the HDMI 8 key.
  • the content C1 is encoded according to a VBR variable rate encoding technique.
  • the content C1 is split into segments, or chunks, of constant duration, for example 2s.
  • Each segment of the content C1 is then encoded according to an encoding rate which can fluctuate, depending on the nature of the content over the duration of the segment.
  • This encoding rate is however limited by the maximum encoding rate MBR (for a given quality level or resolution).
  • the average encoding rate of the content C1 is called ABR (for a given quality level or resolution). This is illustrated by FIG. 3, which represents in simplified form a possible fluctuation of the encoding rate of the content C1 as a function of time, according to the VBR encoding technique.
  • the two horizontal lines in dotted lines represent respectively (for a given level of quality or resolution) the maximum encoding bit rate MBR which is reached for this content C1, and the average encoding bit rate ABR, corresponding to the average of the bit rates. encoding of each segment.
  • the network operator determines one or more ChNet load criteria.
  • load criteria include in particular an estimate of the load of the content distribution network, as it can be measured by the operator, according to known techniques which are not the subject of the present invention.
  • network load we mean here all the load generated on the content servers, and in particular on the content distribution platforms, and also the consumption of bandwidth in the operator's network.
  • load criteria can also take into account other load parameters, such as: a period of the year: thus, in winter, in the event of a very cold warning, it may be useful to consider reducing the load. consumption by the operator's network; a political decision by the operator, who may wish to favor the quality perceived by its customers or, conversely, reduce the load on its network; a particular situation of updating by the operator of certain equipment or certain network platforms; a CSR (Corporate Social Responsibility) policy for the operator, who can, in a sustainable development approach, choose to reduce the electricity consumption of its network; a load prediction, based on past observation of consumption peaks in the network, depending on the time of day, day of the week, or time of year.
  • CSR Corporate Social Responsibility
  • ChNet ChNet
  • this ChNet load metric takes, in step 21, a value between 0 and 100, where the value 0 corresponds to zero network load, and where the value 100 corresponds at maximum network load.
  • Any other scale of value or weighting of the ChNet criterion can of course be envisaged in the context of the present invention, with a corresponding adaptation of the calculation formula which will be described below in relation to the step referenced 22.
  • this step 22 we therefore calculate the apparent encoding rate which will be exposed in association with each level of quality of the content, in the manifest file 7. With reference to the example in appendix 1, this step 22 therefore makes it possible to calculate the value of the apparent encoding bit rates of the quality levels NI, N2, N3, etc. which will be displayed in the manifest file 7 for the content Cl.
  • the ChNet load criterion takes the value 0
  • Nj ABRj
  • the improvement of the video quality supplied to the client is promoted, without limiting the use of the bandwidth. Indeed, this case corresponds to that where the operator's network is not used much (off-peak hours for example), and it is therefore not necessary to optimize flows.
  • the value of the ChNet load criterion increases progressively between 0 and 100; the value of the apparent encoding rate Nj therefore also increases to approach the maximum value MBRj of the encoding rate for this level of resolution.
  • optimization of the consumption of network resources is favored, to the detriment of the video quality perceived by the customer.
  • a HAS content server 2 exposes a video C1 in the form of “chunks” Cli @ Nj encoded at different quality levels j associated with encoding rates Nj, where the index i designates a temporal identifier of the “chunk” Cli @ Nj.
  • a HAS client module is responsible for coming to retrieve its “chunks” from the HAS content server 2 by choosing the video quality Nj as a function of the available network resource.
  • Nj the video quality of the available network resource.
  • the HAS client module chooses the encoding rate of the next video fragment to download: there are indeed many algorithms allowing this choice to be made, the strategies of which are more or less secure. or aggressive. It is recalled, however, that, most often, the general principle of such algorithms is based on the downloading of a first fragment at the lowest encoding rate proposed in the manifesto, and on the evaluation of the recovery time of this first fragment. .
  • the HAS client module evaluates whether, depending on the size of the fragment and the time taken to retrieve it, the network conditions allow the next fragment to be downloaded at a higher encoding rate.
  • the HAS download module of the multimedia stream reader terminal retrieves the manifest file 7 at regular time intervals, for example every minute, in order to discover the available fragments of the video content C1, and the various associated apparent video qualities Nj.
  • the HAS download module of the terminal performs the download, for example, of successive fragments Cli @ Nl (i.e. the first temporal fragment at a first quality level 1 associated with an encoding rate of 540kb / s), then Cl 2 @ N3 (i.e.
  • This choice made by the HAS download module is therefore based on the apparent encoding bit rate value Nj exposed in the manifest file 7, and not on the effective size in kilobytes of the video segments that it receives. This size is in fact only used to calculate the chunk recovery time, and thus to determine what level of quality j it can claim.
  • the various fragments downloaded by the HAS download module are then returned to the user on the screen of the reproduction terminal.
  • the apparent encoding rates exposed in manifest file 7 will also be modified, or adapted, in the next version of manifest 7, downloaded by the terminal media stream player, for example 60 s later.
  • the ChNet load criterion goes from a value 80 to a value 40
  • the apparent encoding rates exposed in the following version of the manifest file 7 become: [Table 2] replaced by the values of the apparent encoding rates Nj of Table 2.
  • the load having decreased we can expose lower apparent encoding rates in the manifest file 7, and thus promote the improvement of the video quality provided to the user.
  • a feedback loop is thus ensured, according to which, the lower the network load, the more it is allowed to consume a large part of the resources of the operator's network, and thus to ensure that the VBR encoding (in comparison with the CBR encoding) contributes to the improvement of the video quality returned to the end customer.
  • the technique of the invention can also find application for content of the VOD type (for “Video On Demand”, or video on demand), or “replay” content (in French, catch-up television), based on the predictive nature of the evolution of the network load.
  • the manifest file 7 is downloaded once and for all, when the customer begins to view the content.
  • the duration of the content, and a prediction of the evolution of the network load over this duration it is possible to assign a value to the criterion load ChNet, and thus determine the optimum apparent encoding rates to be exposed in the manifest, according to the principle of Fig 2.
  • ChNet does not result only from a measurement of the network load, but a detailed knowledge of the daily, weekly or seasonal recurring peaks of load. Indeed, HAS download volumes fluctuate greatly over the course of a day, with strong peaks in consumption in the evening. Thus, for the same content, and the same network load measured at the start of its download, different apparent encoding rates will be able to be exposed in the manifest file, depending on the time at which this content is requested by the user. .
  • the platform 40 communicates with the extended Internet network 1 via an I / O module for communication with other servers and network equipment, for example the content server 2, to which it supplies the manifest file 7.
  • the platform 40 furthermore comprises a MONIT_ChNet module for measuring the load of the network 1, capable of assigning a value to the ChNet load criterion. This value can be recorded for example in the memories M of the platform 40.
  • the platform 40 also comprises an ENCOD module (Ci) for encoding the video segments of a content Ci, according to a VBR variable rate encoding technique.
  • ENCOD module Ci
  • PREP_MANIFEST module for preparing the manifest file 7, for the content Ci, which exposes in this file the apparent encoding rates calculated by the computer CPU, as a function of the ChNet load criterion delivered by the MONIT_ChNet module and of the values maximum MBR encoding rate and average ABR encoding rate supplied by the ENCOD encoding module (Ci) for a given quality level of the content Ci.
  • module can correspond just as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware set (or hardware) capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • such a platform 40 comprises a random access memory (for example a RAM memory), a processing unit equipped for example with a processor CPU, and controlled by a computer program, stored in a read only memory (for example a ROM or hard drive).
  • a random access memory for example a RAM memory
  • a processing unit equipped for example with a processor CPU
  • a computer program stored in a read only memory (for example a ROM or hard drive).
  • the code instructions of the computer program are, for example, loaded into RAM before being executed by the processor CPU of the processing unit.
  • the random access memory contains in particular the value of the load criterion ChNet.
  • the processor of the processing unit controls the determination of the apparent encoding rates to be exposed in the manifest file 7, according to the algorithm of FIG. 2.
  • Fig 4 illustrates only one particular way, among several possible, of achieving a content preparation platform so that it performs the steps of the method detailed above, in relation to Fig 2 (in any one of the different embodiments , or in a combination of these embodiments). Indeed, these steps can be performed either on a reprogrammable computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or ASIC, or any other hardware module).
  • a reprogrammable computing machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated computing machine for example a set of logic gates such as an FPGA or ASIC, or any other hardware module.
  • APPENDIX 1 example of manifest file

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Databases & Information Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau L'invention concerne un procédé de gestion de l'accès à un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau de distribution dudit contenu; le contenu numérique (C1) est associé à un fichier de description du contenu numérique, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d'encodage apparents du contenu; les segments temporels du contenu numérique sont encodés (20) selon une méthode d'encodage à débit variable (VBR) associé à un débit d'encodage moyen (ABR) et à un débit d'encodage maximum (MBR). Selon l'invention, un tel procédé comprend une détermination (21) des débits d'encodage apparents (Nj) exposés dans le fichier de description en association avec les segments temporels du contenu, en fonction d'au moins un critère de charge (ChNet) du réseau de distribution, un débit d'encodage apparent (Nj) pouvant prendre une valeur comprise entre le débit d'encodage moyen (ABRj) et le débit d'encodage maximum (MBRj).

Description

DESCRIPTION
TITRE : Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau
Domaine technique
Le domaine de l’invention est celui des contenus multimédias numériques, à savoir les contenus audio et/ou vidéo numériques. Plus précisément, l’invention concerne la préparation de contenus numériques accessibles selon une technique dite de téléchargement progressif adaptatif, et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau.
Art antérieur
L'accès à un contenu multimédia, tel que la télévision ou la vidéo à la demande, est possible aujourd'hui, pour la plupart des terminaux de restitution.
Le terminal émet généralement une requête à destination d'un serveur, en indiquant le contenu choisi et il reçoit en retour un flux de données numériques relatives à ce contenu.
Le terminal est adapté pour recevoir ces contenus numériques sous forme de données multimédia et pour en faire une restitution. Cette restitution consiste à fournir au niveau du terminal le contenu numérique sous une forme accessible à l'utilisateur. Par exemple, des données reçues correspondant à une vidéo sont généralement décodées, puis restituées au niveau du terminal sous la forme d'un affichage de la vidéo correspondante avec sa bande-son associée. Dans la suite, par souci de simplification, on assimilera le contenu numérique à une vidéo et la restitution par le terminal, ou consommation par l'utilisateur du terminal, à une visualisation sur l'écran du terminal. La diffusion de contenus numériques est souvent basée sur des protocoles client-serveur de la famille HTTP (de l'anglais « Hyper Text Transport Protocol »). En particulier, le téléchargement en mode progressif des contenus numériques, aussi appelé streaming, permet de transporter et consommer les données en temps réel, c'est-à-dire que les données numériques sont transmises sur le réseau et restituées par le terminal au fur et à mesure de leur arrivée. Le terminal reçoit et stocke une partie des données numériques dans une mémoire tampon avant de les restituer. Ce mode de distribution est particulièrement utile quand le débit dont dispose l'utilisateur n'est pas garanti pour le transfert en temps réel de la vidéo, en fonction par exemple de la fluctuation de la bande passante disponible.
Le téléchargement progressif adaptatif, en anglais HTTP Adaptative Streaming, d'abréviation HAS, permet de surcroît de diffuser et recevoir des données suivant différentes qualités correspondant par exemple à différents débits. Ces différentes qualités sont décrites dans un fichier de paramètres disponible en téléchargement sur un serveur de données, par exemple un serveur de contenus. Quand le terminal client souhaite accéder à un contenu, ce fichier de description permet de sélectionner le bon format pour le contenu à consommer en fonction de la bande passante disponible ou des capacités de stockage et de décodage du terminal client. Ce type de technique permet notamment de tenir compte des variations de bande passante sur la liaison entre le terminal client et le serveur de contenus.
Il existe plusieurs solutions techniques pour faciliter la distribution d'un tel contenu en streaming, comme par exemple les solutions propriétaires Microsoft® Smooth Streaming, Apple® HLS, Adobe® HTTP Dynamic Streaming ou encore la norme MPEG-DASH de l'organisme ISO/IEC qui sera décrite ci-après. Ces méthodes proposent d'adresser au client un ou plusieurs fichiers de description intermédiaires, appelés aussi documents ou manifestes, contenant les adresses des différents segments aux différentes qualités du contenu multimédia.
Ainsi, la norme MPEG-DASH (pour l'anglais "Dynamic Adaptive Streaming over HTTP", en français « diffusion en flux adaptatif dynamique sur HTTP ») est un standard de format de diffusion audiovisuelle sur Internet. Il se base sur la préparation du contenu en différentes présentations de qualité et débit variables, découpées en segments de courte durée (de l'ordre de quelques secondes), également appelés « chunks ». Chacun de ces segments est rendu disponible individuellement au moyen d’un protocole d’échange. Le protocole principalement ciblé est le protocole HTTP, mais d’autres protocoles (par exemple FTP) peuvent également être utilisés. L’organisation des segments et les paramètres associés sont publiés dans un manifeste au format XML.
Le principe sous-jacent à cette norme est que le client MPEG-DASH effectue une estimation de la bande passante disponible pour la réception des segments, et, en fonction du remplissage de son tampon de réception, choisit, pour le prochain segment à charger, une représentation dont le débit : assure la meilleure qualité possible, et permet un délai de réception compatible avec le rendu ininterrompu du contenu.
Ainsi, pour s'adapter à la variation des conditions réseau, notamment en termes de bande passante, les solutions existantes de téléchargement adaptatif permettent au terminal client de passer d'une version du contenu encodée à un certain débit, à une autre encodée à un autre débit, au cours du téléchargement. En effet, chaque version du contenu est divisée en segments de même durée. Pour permettre une restitution en continu du contenu sur le terminal, chaque segment doit atteindre le terminal avant son instant programmé de restitution. La qualité perçue associée à un segment augmente avec la taille du segment, exprimée en bits, mais dans le même temps, des segments plus gros requièrent un temps de transmission plus important, et donc présentent un risque accru de ne pas être reçus à temps pour une restitution en continu du contenu. Le terminal de restitution doit donc trouver un compromis entre la qualité globale du contenu, et sa restitution ininterrompue, en sélectionnant avec soin le prochain segment à télécharger, parmi les différents débits d'encodage proposés. Il existe pour ce faire différents algorithmes de sélection de la qualité du contenu en fonction de la bande passante disponible, qui peuvent présenter des stratégies plus ou moins agressives, ou plus ou moins sécuritaires.
La consommation de contenus numériques en téléchargement progressif adaptatif (HAS) tend à se démocratiser. Elle est notamment utilisée par de nombreux services de streaming (en français, diffusion en mode continu, ou lecture en continu), mais également par certains décodeurs TV, ou set-top-box, qui l'utilisent pour accéder à des contenus délinéarisés, tels que la vidéo à la demande (VOD), la diffusion en différé de programmes télévisuels (Replay), ou encore les offres de type Network PVR (pour « Network Personal Video Recorder », i.e. un service d'enregistrement des contenus numériques, effectué par le fournisseur de contenus lui-même plutôt qu'au domicile de l'utilisateur final).
En outre, d'autres dispositifs tels que des appareils lecteurs de flux multimédia en temps réel accèdent également aux contenus numériques en mode de téléchargement adaptatif progressif pour des contenus télévisuels en temps réel (ou Live). C'est le cas par exemple de l'appareil Chromecast® développé par Google®, ou de la CléTV® d'Orange®. De tels appareils, plus génériquement désignés sous le nom de Clef HDMI, peuvent également être utilisés pour accéder à des contenus de type vidéo à la demande.
De tels appareils se branchent classiquement sur le port HDMI d'un téléviseur et communiquent, par exemple par connexion Wi-Fi®, avec un autre appareil du réseau de communication domestique connecté à un réseau de communication étendu (par exemple un téléphone intelligent de type smartphone, connecté à un réseau mobile 4G), afin de restituer, sur le téléviseur, le contenu multimédia reçu par une application logicielle compatible. On désignera par la suite ces appareils sous la désignation générique de Clef HDMI.
Il existe par ailleurs plusieurs techniques d'encodage des contenus numériques qui sont ainsi accessibles en téléchargement progressif adaptatif HAS.
Une première technique connue, appelée CBR (pour l'anglais « Constant Bit Rate », que l'on peut traduire par « taux d'échantillonnage fixe »), consiste à encoder le contenu à un débit constant : ainsi, tous les segments vidéo, ou « chunks », d'un même niveau de qualité, présentent une taille identique, exprimée en kilo octets. Ainsi, quelle que soit la nature des images encodées, la taille des segments est toujours la même, ce qui permet de prévoir la consommation de données dans le réseau de distribution des contenus numériques.
Une autre technique d'encodage connue, appelée VBR (pour l'anglais « Variable Bit Rate », que l'on peut traduire par « taux d'échantillonnage variable »), permet d'encoder le contenu à un débit variable, borné par un débit maximum appelé MBR (pour « Max Bit Rate »). Le débit moyen d'encodage obtenu pour le contenu est appelé ABR (pour « Average Bit Rate »). Selon cette technique, la taille des segments vidéo d'un même niveau de qualité évolue en fonction du contenu numérique encodé et de la nature des images : ainsi, les segments vidéo correspondant à une scène très animée seront encodés à un débit proche du débit maximum MBR, contrairement aux « chunks » de scènes très peu animées (par exemple des images noires avec très peu de mouvement), qui seront encodés selon un débit d'encodage plus faible, par exemple inférieur au débit moyen ABR. Une telle technique d'encodage à débit variable VBR d'un contenu est notamment décrite dans le document de brevet US 2016/0205162.
En considérant des segments vidéo de même durée (par exemple 2s) et de même niveau de qualité, on observera donc une très forte disparité de leur taille (en kilo octets), en fonction de la portion de contenu à laquelle ils correspondent (scène calme ou scène animée).
Cette technique d'encodage à débit variable VBR est avantageuse en ce qu'elle permet de diminuer la taille moyenne en kilo octets des segments vidéo, tout en conservant un même niveau de qualité perçue par l'utilisateur : on observe ainsi en moyenne une diminution de 50% de l'utilisation de la bande passante sur le réseau, par rapport à un encodage en CBR, pour une même qualité vidéo. On comprend aisément que, pour un contenu encodé selon une technique CBR, le débit d'encodage apparent exposé dans le fichier de description du contenu, ou manifeste, est le débit d'encodage constant qui s'applique pour l'ensemble du contenu, en fonction du niveau de qualité proposé. Ainsi, un fichier manifest (MPD) conforme à la norme MPEG-DASH peut comporter la description d'un contenu disponible dans trois qualités différentes (NI = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s), où NI, N2 et N3 désignent les débits d'encodage constants utilisés pour l'encodage de l'ensemble des segments vidéo du contenu. Le terminal de restitution multimédia choisit alors de télécharger les segments à l'un de ces trois niveaux de qualité : pour un même niveau de qualité, tous les segments téléchargés sont de même taille en kilo octets.
En revanche, pour un contenu encodé selon une technique VBR, se pose la question de savoir quel est le débit d'encodage apparent qu'il convient d'exposer dans le fichier manifest.
Une première option consiste à exposer dans le fichier manifest, pour chaque niveau de qualité du contenu, le débit d'encodage maximum MBR des segments vidéo : cette première option est avantageuse en termes de diminution de la consommation de la bande passante dans le réseau de diffusion des contenus HAS. En effet, l'affichage du débit maximum MBR dans le fichier manifest conduit le terminal lecteur de flux multimédia à surestimer la taille des segments à télécharger, par rapport à leur taille effective. C'est cette valeur de MBR qui est utilisée par le terminal lecteur de flux multimédia pour calculer le temps de récupération des chunks, et ainsi déterminer le niveau de qualité proposé dans le fichier manifest auquel il peut prétendre. Ceci conduit donc le terminal lecteur de flux multimédia à sélectionner un niveau de qualité probablement inférieur à celui auquel il pourrait effectivement prétendre en pratique, et donc, in fine, pour l'opérateur, à une diminution de la consommation de la bande passante et à une réduction de la charge du réseau de distribution.
Une deuxième option consiste à exposer dans le fichier manifest, non pas le débit maximum MBR, mais, pour chaque niveau de qualité du contenu, le débit d'encodage moyen ABR associé. Cette deuxième option permet avantageusement d'améliorer la qualité perçue par l'utilisateur.
Ces deux options présentent donc chacune leurs intérêts, selon les attentes respectives de l'opérateur d'une part, et du client d'autre part. Elles présentent cependant l'inconvénient d'être figées : le choix, une fois pour toutes, d'exposer dans le fichier manifest, soit le débit maximum MBR, soit le débit moyen ABR, ne permet en effet pas de s'adapter au contexte.
La problématique de la gestion de la charge et de la congestion du réseau de l'opérateur, dans le cadre du téléchargement de contenus multimédias, est notamment discutée dans le document de brevet WO 2017/167958 au nom de la Demanderesse, pour le contexte particulier d'un réseau de type cellulaire. Ce document ne mentionne cependant pas la problématique particulière de l'encodage des contenus selon une technique à débit variable de type VBR. Il propose, pour résorber la congestion d'une cellule du réseau, de modifier à la volée le fichier manifest associé à un contenu, en supprimant de ce fichier certains débits jugés trop élevés par rapport à un critère de charge du réseau.
Il existe donc un besoin d'une technique de préparation de contenus numériques accessibles en téléchargement HAS et encodés selon une technique d'encodage VBR à débit variable qui ne présente pas ces différents inconvénients de l'art antérieur. Notamment, il existe un besoin d'une telle technique qui permette de s'adapter finement au contexte, tout particulièrement, mais non exclusivement, au contexte particulier de charge du réseau de diffusion de contenus et des serveurs associés.
Il existe également un besoin d'une telle technique qui permette de profiter de façon combinée des avantages des techniques connues d'affichage du MBR et d'affichage de l'ABR dans le fichier manifest.
Il existe encore un besoin d'une telle technique qui soit simple à mettre en oeuvre et puisse répondre conjointement aux attentes de l'opérateur du réseau d'une part, et des clients utilisateurs d'autre part.
Exposé de l'invention
L'invention répond à ce besoin en proposant un procédé de gestion de l'accès à un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau de distribution dudit contenu. Le contenu numérique est associé à un fichier de description du contenu numérique, comprenant une liste de segments temporels (Cli@Nj) du contenu associés chacun à plusieurs niveaux de qualité du contenu.
Les segments temporels du contenu numérique sont encodés selon une méthode d'encodage à débit variable (VBR) borné, pour un niveau de qualité donné, par un débit d'encodage maximum (MBR) desdits segments pour ledit niveau.
Selon l'invention, un tel procédé comprend une détermination d'au moins un critère de charge (ChNet) du réseau de distribution, et une adaptation, en fonction dudit au moins un critère de charge déterminé, des débits d'encodage apparents exposés dans le fichier de description. L'adaptation d'un débit d'encodage apparent, pour un niveau de qualité donné, affecte audit débit d'encodage apparent une valeur comprise entre le débit d'encodage maximum pour ledit niveau de qualité donné et un débit d'encodage moyen correspondant à une moyenne des débits d'encodage des segments dudit contenu pour ledit niveau de qualité donné.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion de l'accès à des contenus numériques mis à disposition des terminaux clients utilisateurs pour un téléchargement progressif adaptatif de type HAS, lorsque ces contenus sont encodés selon une technique d'encodage à débit variable VBR.
En effet, contrairement aux techniques de l'art antérieur, selon lesquelles on décide une fois pour toutes d'exposer dans le fichier manifest, soit le débit maximum MBR, soit le débit moyen ABR, la technique de l'invention propose au contraire de faire évoluer dans le temps le débit apparent exposé dans ce fichier de description, en fonction d'un ou plusieurs critères de charge du réseau de distribution de contenus. Ce débit apparent peut avantageusement prendre une valeur comprise entre le débit moyen ABR, pour améliorer la qualité perçue par l'utilisateur, et le débit maximum MBR, pour diminuer la consommation de ressources dans le réseau.
En d'autres termes, la solution proposée vise à adapter le contenu du manifest en fonction de l'utilisation en temps réel de la charge réseau de l'opérateur. On entend ici, par charge réseau, l'ensemble de la charge générée sur les serveurs de contenus et également sur la consommation de bande passante dans le réseau de l'opérateur.
Selon un premier mode de réalisation, pour un niveau de qualité donné, le débit d'encodage apparent prend une valeur égale à (MBR-ABR)/100*ChNet+ABR, où MBR désigne le débit d'encodage maximum des segments du contenu pour ledit niveau de qualité donné, ABR désigne le débit d'encodage moyen des segments du contenu pour ledit niveau de qualité donné et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge. Lorsque le critère de charge ChNet prend la valeur 0, la charge est nulle ; lorsqu'il prend la valeur 100, la charge est maximale. Ainsi, si la charge est faible, la technique selon l'invention permet de privilégier l'amélioration de la qualité vidéo restituée au client, sans pour autant optimiser la diminution de la charge du réseau. En revanche, lorsque la charge augmente, la technique selon l'invention permet d'optimiser progressivement la diminution de la charge réseau au détriment de l'amélioration de la qualité de l'image.
En effet, si le critère de charge ChNetprend la valeur 0, l'opérateur construit les fichiers manifest en indiquant comme débit de chaque niveau de qualité la valeur du débit moyen ABR. Dans ce cas, on favorise au maximum l'amélioration de qualité vidéo fournie au client, sans limiter l'utilisation de bande passante. En effet, dans ce cas, le réseau de l'opérateur étant peu utilisé, il n'est pas nécessaire d'optimiser les flux.
Si la charge réseau augmente, l'opérateur expose dans les fichiers manifest une valeur de débit apparent qui augmente pour se rapprocher du débit maximum MBR lorsque la valeur du critère de charge ChNet se rapproche de 100.
Une telle approche de détermination du débit apparent à exposer dans le fichier manifest assure une boucle retour d'asservissement avantageuse.
Selon un aspect, un tel procédé de gestion de l'accès à un contenu comprend une mesure d'une charge du réseau de distribution et la valeur affectée audit au moins un critère de charge du réseau est fonction de la mesure.
Ainsi, l'opérateur surveille et monitore en permanence la charge réseau liée à la diffusion de contenus en HAS, et adapte sa stratégie de construction des fichiers manifest, en fonction de la charge mesurée. On assure ainsi une adaptabilité optimale de la proposition de contenu faite aux clients en fonction de la charge réelle du réseau, et le meilleur compromis possible entre la qualité vidéo perçue par l'utilisateur et la consommation de ressources pour l'opérateur.
Ceci est tout particulièrement avantageux lorsque le contenu numérique est diffusé sur le réseau en temps réel. En effet, les contenus dits LIVE sont des contenus ouverts pour lequel le terminal client doit télécharger très régulièrement le fichier de description, en général toutes les minutes. L'adaptation en temps réel des débits apparents exposés dans le fichier manifest a donc un impact direct sur le choix, par le terminal lecteur de flux multimédia, de la qualité à laquelle il peut prétendre pour le téléchargement des segments vidéo de contenu.
Selon un autre aspect, ledit au moins un critère de charge du réseau tient également compte d'au moins un paramètre appartenant au groupe comprenant : une prédiction de charge du réseau ; une consommation électrique du réseau ; une période de l'année ; une programmation de mise à jour d'équipements du réseau. En effet, ce principe d'adaptation du débit apparent exposé dans le fichier manifest peut être étendu à la prise en compte d'autres critères de charge que la simple charge effective mesurée du réseau, et notamment prendre une dimension prédictive.
Ainsi, il est possible de tenir compte d'une période de l'année, par exemple la période hivernale au cours de laquelle la consommation électrique globale est plus élevée : dans ce cas, on tend à faire évoluer le débit apparent vers le MBR, pour réduire la consommation de ressources, et donc réduire également la consommation électrique au cours des pics enregistrés de consommation, par exemple en période d'alerte grand froid.
Il est également possible de tenir compte de prédictions de charge du réseau, obtenues par observation des charges au cours de périodes passées écoulées. Ainsi, si l'on constate une augmentation de la charge du réseau en début de mois, par rapport à la fin de mois, on peut en tenir compte pour pondérer la valeur du débit apparent exposé dans le fichier manifest.
Il est encore possible de tenir compte de périodes de congés, ou des conditions météorologiques pour prédire la charge du réseau : en effet, lorsque la météo est mauvaise, on constate que la consommation vidéo est plus importante.
On peut encore modifier volontairement le débit apparent exposé dans le fichier manifest, par exemple en cas d'opérations de maintenance ou de mise à jour de certains équipements ou de certaines plateformes du réseau de diffusion des contenus, pour alléger la charge sur les autres équipements.
On peut encore agir sur ce débit apparent pour tenir compte de situations inédites et imprévues, par exemple afin de réduire la consommation en ressources du réseau lors d'une période de confinement de la population, pour privilégier l'accès aux ressources pour des besoins plus prioritaires, tels que le télétravail.
L'invention concerne également un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de préparation d'un contenu numérique selon l'invention, tel que décrit ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur.
D’autre part, un tel support d’enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé de contrôle d'affichage précité.
L'invention concerne également une plate-forme de gestion de l'accès à un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau de distribution du contenu. Le contenu numérique est associé à un fichier de description du contenu numérique, comprenant une liste de segments temporels (Cli@Nj) du contenu associés chacun à plusieurs niveaux de qualité du contenu. Les segments temporels du contenu numérique sont encodés selon une méthode d'encodage à débit variable (VBR) borné, pour un niveau de qualité donné, par un débit d'encodage maximum (MBR) des segments pour le niveau donné.
Selon l'invention, une telle plate-forme comprend un calculateur apte à adapter les débits d'encodage apparents exposés dans le fichier de description, en fonction d'au moins un critère de charge (ChNet) du réseau de distribution. Le calculateur est apte à affecter à un débit d'encodage apparent, pour un niveau de qualité donné, une valeur comprise entre le débit d'encodage maximum pour le niveau de qualité donné et un débit d'encodage moyen correspondant à une moyenne des débits d'encodage des segments du contenu pour le niveau de qualité donné.
On notera que cette plate-forme peut être dissociée de la plate-forme de mise à disposition du contenu, dont la structure et le fonctionnement ne sont pas impactés par la technique de l'invention.
Avantageusement, la valeur affectée par le calculateur au débit d'encodage apparent pour un niveau de qualité donné est égale à (MBR-ABR)/100*ChNet+ABR, où MBR désigne le débit d'encodage maximum des segments du contenu pour le niveau de qualité donné, ABR désigne le débit d'encodage moyen des segments du contenu pour le niveau de qualité donné et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge.
Selon un autre aspect, une telle plate-forme de gestion de l'accès à un contenu numérique comprend un module de mesure d'une charge du réseau de distribution et le calculateur affecte audit au moins un critère de charge du réseau une valeur qui est fonction de la charge mesurée. Selon un autre aspect, un tel critère de charge du réseau tient également compte d'au moins un paramètre appartenant au groupe comprenant : une prédiction de charge du réseau ; une consommation électrique du réseau ; une période de l'année ; une programmation de mise à jour d'équipements du réseau.
Présentation des figures
D’autres buts, caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[Fig 1] présente une architecture de téléchargement progressif sur réseau mobile basée sur l'utilisation du streaming adaptatif selon l'invention ;
[Fig 2] illustre sous forme d'organigramme schématique les différentes étapes du procédé de préparation d'un contenu selon un mode de réalisation de l'invention ;
[Fig 3] illustre le principe d'évolution du débit d'encodage d'un contenu encodé selon une technique à débit variable de type VBR ;
[Fig 4] présente la structure matérielle d'une plateforme de préparation d'un contenu numérique mettant en oeuvre le procédé de Fig 2.
Description détaillée de modes de réalisation de l’invention
Le principe général de l’invention repose sur l'adaptation des fichiers de description des contenus numériques accessibles en téléchargement progressif HAS et encodés selon une technique d'encodage à débit variable VBR, afin de faire évoluer le débit apparent exposé dans ces fichiers de description, en fonction d'un ou plusieurs critères de charge du réseau de distribution.
On présente désormais, en relation avec Fig 1, une architecture de téléchargement progressif basée sur l'utilisation du streaming adaptatif selon l'invention.
Le terminal 3, par exemple un téléphone intelligent de type « smartphone » et le terminal 4, par exemple une tablette, sont, dans cet exemple, connectés à un réseau de communication étendu 1, formant réseau de distribution de contenus numériques. Ils communiquent avec un terminal 8, par exemple une clef HDMI connectée à un téléviseur 5.
Un serveur de contenus numériques 2 se trouve selon cet exemple dans le réseau étendu (WAN, 1) et reçoit par exemple des chaînes de contenus de télévision numérique en provenance d'un réseau de télévision diffusée, non représenté, et/ou des vidéos à la demande, et les met à disposition des terminaux clients.
Les terminaux client 3 et 4 peuvent entrer en communication avec le serveur de contenus 2 pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.).
Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre les terminaux client 3, 4 et le serveur 2, à une technique de téléchargement progressif adaptatif, en anglais « adaptive streaming », abrégé en HAS basée sur le protocole HTTP. Ce type de technique permet notamment d'offrir une bonne qualité de contenus à l'utilisateur en tenant compte des variations de bande passante qui peuvent se produire sur la liaison entre le terminal client 3, 4 et le serveur de contenus 2.
Classiquement, différentes qualités peuvent être encodées pour le même contenu d'une chaîne, correspondant par exemple à différents débits. Plus généralement, on parlera de qualité pour se référer à une certaine résolution du contenu numérique (résolution spatiale, temporelle, niveau de qualité associée à la compression vidéo et/ou audio). Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (ou « fragments » de contenu, en anglais « chunks », ces trois mots étant utilisés indifféremment dans l'ensemble de ce document). La description de ces différentes qualités et de la segmentation temporelle associée, ainsi que les fragments de contenu, sont décrits pour le terminal client et mis à sa disposition via leurs adresses Internet (URI : Universal Ressource Identifier). L'ensemble de ces paramètres (qualités, adresses des fragments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description. On notera que ce fichier de paramètres peut être un fichier informatique ou un ensemble d'informations descriptives du contenu, accessible à une certaine adresse.
Les terminaux 3, 4 possèdent leurs propres caractéristiques en termes de capacité de décodage, d'affichage, etc. Dans un contexte de téléchargement adaptatif progressif, ils peuvent adapter leurs requêtes pour recevoir et décoder le contenu demandé par l'utilisateur à la qualité qui leur correspond au mieux. Dans notre exemple, si les contenus sont disponibles aux débits apparents 512 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté NI), 1024 kb/s (N2), 2048 kb/s (N3) et que le terminal client dispose d'une bande passante de 3000 kb/s, il peut demander le contenu à n'importe quel débit inférieur à cette limite, par exemple 2048 kb/s. De manière générale, on note « Ci@Nj » le contenu numéro i avec la qualité j (par exemple le j-ième niveau Nj de qualité décrit dans le fichier de description).
Les terminaux clients 3, 4 reçoivent les données en provenance du réseau étendu 1 et assurent leur décodage, et éventuellement leur restitution sur leur écran, ou leur transmission à la clef HDMI 8 pour restitution sur l'écran du téléviseur 5. En variante, les décodeurs peuvent se trouver ailleurs dans le réseau, notamment au niveau d'un élément de type STB (de l'anglais Set-Top-Box) (non représenté) associé à un téléviseur.
Dans cet exemple, pour visualiser un contenu, le terminal 3, 4 ou 8 récupère tout d'abord une adresse du document de description 7 du contenu (par exemple, Cl) souhaité. Dans la suite, on supposera que ce fichier est un fichier de type manifest selon la norme MPEG-DASH (noté « C.mpd ») et on se référera indifféremment, selon le contexte, à l'expression « fichier de description » ou « manifest ». Ce fichier peut être récupéré directement auprès d'un serveur Internet du réseau étendu 1, ou se trouver déjà sur le terminal au moment de la requête. Un exemple de fichier manifest (MPD) conforme à la norme MPEG-DASH et comportant la description de contenus disponibles dans trois qualités différentes (NI = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s) des contenus fragmentés est présenté en annexe 1. Ce fichier manifest simplifié décrit des contenus numériques dans une syntaxe XML (de l'Anglais « eXtended Markup Language»), comprenant une liste de contenus sous forme de fragments classiquement décrits entre une balise ouvrante (<SegmentList>) et une balise fermante (</SegmentList>). La découpe en fragments permet notamment de s'adapter finement aux fluctuations de la bande passante. Chaque fragment correspond à une certaine durée (champ « duration ») avec plusieurs niveaux de qualité et permet de générer leurs adresses (URL - Uniform Resource Locator). Cette génération est faite dans cet exemple à l'aide des éléments « BaseURL » (« HTTP://server.com ») qui indique l'adresse du serveur de contenus et « SegmentURL » qui liste les parties complémentaires des adresses des différents fragments :
- « Cl_512kb_l.mp4 » pour le premier fragment du contenu « Cl » à un débit apparent de 512 kilobits par seconde (« kb ») au format MPEG-4 (« mp4 »),
- « Cl_512kb_2.mp4 » pour le second fragment,
- etc.
Une fois qu'il dispose des adresses de fragments correspondant au contenu souhaité, le terminal procède à l'obtention des fragments via un téléchargement à ces adresses. On notera que ce téléchargement s'opère ici, traditionnellement, au travers d'une URL HTTP, mais pourrait également s'opérer au travers d'une adresse universelle (URI) décrivant un autre protocole (dvb://monsegmentdecontenu par exemple).
On suppose ici que la clef HDMI 8 est connectée au téléviseur 5 par branchement sur le port HDMI de ce dernier, et est utilisée pour restituer, sur l'écran du téléviseur 5, un contenu Cl, décrit dans un fichier manifeste 7. On notera que le contenu Cl peut être un programme télévisuel diffusé en direct ou en différé, ou une vidéo à la demande, ou tout autre contenu multimédia.
La clef HDMI 8 peut être connectée en WiFi® directement à la tablette 4 ou au téléphone intelligent 3, par l'intermédiaire duquel elle peut accéder au réseau de communication étendu 1, par exemple via une connexion 4G.
La clef HDMI 8 peut également être pilotée par l'utilisateur au moyen du téléphone intelligent 3, sur lequel est installé une application logicielle de commande de la clef HDMI 8.
Les fragments de contenu obtenus par le smartphone 3 ou la tablette 4 sont par exemple transmis en WiFi® à la clef HDMI 8, qui pilote leur affichage sur l'écran du téléviseur 5, pour restitution à l'utilisateur.
Fig 2 illustre sous forme d'organigramme simplifié les différentes étapes mises en oeuvre selon un mode de réalisation de l'invention pour préparer le fichier manifeste 7, lorsqu'un contenu Cl est destiné à être encodé selon une technique d'encodage à débit variable, VBR. On considère dans cet exemple un contenu Cl diffusé en temps réel, également appelé LIVE. En effet, pour de tels contenus LIVE, le terminal lecteur de flux multimédia récupère à intervalles de temps très réguliers le fichier manifest 7, par exemple toutes les minutes environ, selon une technique connue. L'adaptation du débit apparent du contenu exposé dans ce fichier manifest 7, en fonction d'un critère de charge, est donc particulièrement efficace et directement suivie d'effet, pour le choix de débit et de niveau de qualité effectué par le terminal lecteur de flux multimédia, par exemple la clef HDMI 8.
Au cours d'une première étape référencée 20, le contenu Cl est encodé selon une technique d'encodage à débit variable VBR. En d'autres termes, le contenu Cl est fractionné en segments, ou chunks, de durée constante, par exemple de 2s. Chaque segment du contenu Cl est alors encodé selon un débit d'encodage qui peut fluctuer, en fonction de la nature du contenu sur la durée du segment. Ce débit d'encodage est cependant borné par le débit d'encodage maximum MBR (pour un niveau de qualité ou une résolution donnés). Le débit d'encodage moyen du contenu Cl est appelé ABR (pour un niveau de qualité ou une résolution donnés). Ceci est illustré par Fig 3, qui représente sous forme simplifiée une fluctuation possible du débit d'encodage du contenu Cl en fonction du temps, selon la technique d'encodage VBR. Les deux droites horizontales en traits pointillés représentent respectivement (pour un niveau de qualité ou une résolution donnés) le débit d'encodage maximum MBR qui est atteint pour ce contenu Cl, et le débit d'encodage moyen ABR, correspondant à la moyenne des débits d'encodage de chacun des segments.
Au cours d'une étape référencée 21, l'opérateur du réseau détermine un ou plusieurs critères de charge ChNet. Ces critères de charge comprennent notamment une estimation de la charge du réseau de distribution du contenu, telle qu'elle peut être mesurée par l'opérateur, selon des techniques connues qui ne font pas l'objet de la présente invention. Par charge réseau, on entend ici l'ensemble de la charge générée sur les serveurs de contenus, et notamment sur les plateformes de diffusion des contenus, et également la consommation de bande passante dans le réseau de l'opérateur.
Ces critères de charge peuvent également tenir compte d'autres paramètres de charge, tels que : une période de l'année : ainsi, en période hivernale, en cas d'alerte grand froid, il peut être utile d'envisager une réduction de la consommation par le réseau de l'opérateur ; une décision politique de l'opérateur, qui peut souhaiter privilégier la qualité perçue par ses clients ou, à l'inverse, réduire la charge sur son réseau ; une situation particulière de mise à jour par l'opérateur de certains équipements ou de certaines plateformes du réseau ; une politique de RSE (Responsabilité Sociétale des Entreprises) de l'opérateur, qui peut, dans une démarche de développement durable, choisir de réduire la consommation électrique de son réseau ; une prédiction de charge, en fonction de l'observation passée des pics de consommation dans le réseau, en fonction de l'heure du jour, du jour de la semaine, ou de la période de l'année.
Cette liste n'est bien sûr pas exhaustive, et tout autre paramètre influant directement ou indirectement sur l'évaluation d'une charge du réseau peut être pris en compte pour la détermination, au cours de l'étape 21, de la métrique de charge ChNet.
Dans la suite, par souci de simplification, on considère que cette métrique de charge ChNet prend, à l'étape 21, une valeur comprise entre 0 et 100, où la valeur 0 correspond à une charge réseau nulle, et où la valeur 100 correspond à la charge maximale du réseau. Toute autre échelle de valeur ou pondération du critère ChNet peut bien sûr être envisagée dans le cadre de la présente invention, moyennant adaptation correspondante de la formule de calcul qui sera décrite ci-après en relation avec l'étape référencée 22.
Au cours de cette étape 22, on calcule donc le débit apparent d'encodage qui va être exposé en association avec chaque niveau de qualité du contenu, dans le fichier manifest 7. En référence à l'exemple de l'annexe 1, cette étape 22 permet donc de calculer la valeur des débits d'encodage apparents des niveaux de qualité NI, N2, N3, etc. qui vont être affichés dans le fichier manifest 7 pour le contenu Cl.
Ainsi, pour un niveau de qualité ou une résolution j donnés, le calculateur de la plateforme de préparation de contenu calcule le débit apparent Nj selon la formule : Nj=(MBRj-ABRj)/100*ChNet+ABRj
Ainsi, si la charge réseau est nulle, et que le critère de charge ChNet prend la valeur 0, le débit d'encodage apparent Nj qui sera exposé dans le fichier manifest 7 pour le niveau de résolution j sera Nj=ABRj, soit le débit d'encodage moyen au niveau de qualité j pour les segments vidéo du contenu Cl. Ainsi, on favorise l'amélioration de la qualité vidéo fournie au client, sans limiter l'utilisation de la bande passante. En effet, ce cas correspond à celui où le réseau de l'opérateur est peu utilisé (heures creuses par exemple), et il n'est donc pas nécessaire d'optimiser les flux. Lorsque la charge réseau augmente, la valeur du critère de charge ChNet augmente progressivement entre 0 et 100 ; la valeur du débit d'encodage apparent Nj augmente donc également pour se rapprocher de la valeur maximale MBRj du débit d'encodage pour ce niveau de résolution. Ainsi, on favorise l'optimisation de la consommation de ressource réseau, au détriment de la qualité vidéo perçue par le client.
Le tableau ci-dessous illustre un exemple de valeurs de débits apparents exposés dans le fichier manifest 7 pour différents niveaux de résolution d'une portion du contenu Cl. On suppose dans cet exemple que, pour cette portion du contenu Cl, le critère de charge ChNet prend une valeur ChNet=80.
[Table 1]
Figure imgf000017_0001
Lors du téléchargement du fichier manifest 7, le terminal lecteur de flux multimédia pourra donc choisir de demander à la plateforme de distribution de contenu un téléchargement des prochains segments vidéo à un débit d'encodage Nl=540kb/s, N2=1080kb/s, N3=l,89Mb/s, N4=2,7MB/s ou N5=4,5MB/s.
Ainsi, un serveur de contenu HAS 2 expose une vidéo Cl sous forme de « chunks » Cli@Nj encodés à différents niveaux de qualité j associés à des débits d'encodage Nj, où l'indice i désigne un identifiant temporel du « chunk » Cli@Nj.
Selon l'art antérieur, un module client HAS est chargé de venir récupérer ses « chunks » auprès du serveur de contenu HAS 2 en choisissant la qualité vidéo Nj en fonction de la ressource réseau disponible. On ne décrit pas ici plus en détail la façon dont le module client HAS choisit le débit d'encodage du prochain fragment vidéo à télécharger : il existe en effet de nombreux algorithmes permettant d'opérer ce choix, dont les stratégies sont plus ou moins sécuritaires ou agressives. On rappelle cependant que, le plus souvent, le principe général de tels algorithmes repose sur le téléchargement d'un premier fragment au débit d'encodage le plus faible proposé dans le manifeste, et sur l'évaluation du temps de récupération de ce premier fragment. Sur cette base, le module client HAS évalue si, en fonction de la taille du fragment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le fragment suivant à un débit d'encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des fragments de contenu téléchargés ; d'autres proposent des approches plus risquées, avec des sauts dans les niveaux des débits d'encodage des fragments successifs.
Dans le cas classique, si un « chunk » vidéo dure 3 secondes, la récupération du « chunk » par le module client HAS ne doit pas excéder 3 secondes, afin de permettre une restitution sans interruption du contenu par le terminal. Il convient donc pour le module client HAS d'opérer le meilleur compromis entre une qualité de restitution, et donc un débit d'encodage, aussi élevés que possible, et le temps de téléchargement du fragment, qui doit être suffisamment faible pour permettre une restitution en continu sur le terminal de restitution. Pour un contenu Cl de type LIVE (i.e. diffusé en temps réel), le module de téléchargement HAS du terminal lecteur de flux multimédia récupère le fichier manifest 7 à intervalles de temps réguliers, par exemple toutes les minutes, afin de découvrir les fragments disponibles du contenu vidéo Cl, et les différentes qualités vidéo apparentes Nj associées.
Ainsi, dans l'exemple de Table 1, le contenu Cl est par exemple proposé sous forme de fragments de durée 3s, avec un premier débit d'encodage apparent Nl=540kb/s, un deuxième débit d'encodage apparent N2=1080kb/s, un troisième débit d'encodage apparent N3=l,89Mb/s, etc. Sur la base des débits d'encodage Nj exposés dans le fichier manifeste 7, le module de téléchargement HAS du terminal opère le téléchargement par exemple, des fragments successifs Cli@Nl (soit le premier fragment temporel à un premier niveau de qualité 1 associé à un débit d'encodage de 540kb/s), puis Cl2@N3 (soit le deuxième fragment temporel à un niveau de qualité 3 associé à un débit d'encodage de 1,89Mb /s), puis Cl3@N3 (soit le troisième fragment temporel au niveau de qualité 3 associé au débit d'encodage de 1,89Mb /s), ...
Ce choix opéré par le module de téléchargement HAS se fonde donc sur la valeur de débit apparent d'encodage Nj exposé dans le fichier manifest 7, et non sur la taille effective en kilo-octets des segments vidéo qu'il reçoit. Cette taille n'est en effet utilisée que pour calculer le temps de récupération des chunks, et déterminer ainsi à quel niveau de qualité j il peut prétendre.
Ainsi, s'il choisit pour le deuxième fragment temporel un téléchargement à un débit d'encodage de 1,89Mb /s (soit Cl2@N3), il est possible, comme illustré par Fig 3, que le débit d'encodage réel de ce fragment soit bien inférieur, par exemple de 800kb/s seulement. Le gain résultant de cette différence entre débits d'encodage apparent et effectif permet d'optimiser la consommation des ressources réseau de l'opérateur.
Les différents fragments téléchargés par le module de téléchargement HAS sont ensuite restitués à l'utilisateur sur l'écran du terminal de restitution.
Si la charge du réseau fluctue, et que la valeur du critère de charge ChNet évolue, les débits d'encodage apparents exposés dans le fichier manifest 7 vont également être modifiés, ou adaptés, dans la version suivante du manifest 7, téléchargée par le terminal lecteur de flux multimédia, par exemple 60 s plus tard. Ainsi, si le critère de charge ChNet passe d'une valeur 80 à une valeur 40, les débits d'encodage apparent exposés dans la version suivante du fichier manifest 7 deviennent : [Table 2]
Figure imgf000018_0001
Figure imgf000019_0001
remplacées par les valeurs des débits d'encodage apparents Nj de Table 2.
La charge ayant diminué, on peut exposer des débits d'encodage apparents plus faibles dans le fichier manifest 7, et ainsi favoriser l'amélioration de la qualité vidéo fournie à l'utilisateur.
On assure ainsi une boucle retour d'asservissement, selon laquelle, plus la charge réseau est faible, et plus on autorise à consommer une part importante des ressources du réseau de l'opérateur, et ainsi à faire en sorte que l'encodage en VBR (en comparaison avec l'encodage CBR) participe à l'amélioration de la qualité vidéo rendue au client final.
Le mode de réalisation ci-dessus a été décrit dans le contexte d'un contenu vidéo Cl diffusé en temps réel, ou LIVE, pour lequel le fichier manifest est téléchargé à intervalles de temps réguliers par le terminal lecteur de flux multimédia, ce qui permet d'assurer un asservissement.
On notera que la technique de l'invention peut également trouver application pour des contenus de type VOD (pour « Video On Demand », ou vidéo à la demande), ou des contenus en « replay » (en français, télévision de rattrapage), en se fondant sur le caractère prédictif de l'évolution de la charge réseau. En effet, pour de tels contenus, le fichier manifest 7 est téléchargé une fois pour toutes, lorsque le client commence à visionner le contenu. Cependant, en fonction de l'heure de téléchargement de ce fichier manifest 7, de la durée du contenu, et d'une prédiction de l'évolution de la charge du réseau sur cette durée, il est possible d'affecter une valeur au critère de charge ChNet, et ainsi de déterminer les débits apparents d'encodage optimums à exposer dans le manifest, selon le principe de Fig 2. Dans ce cas, la valeur de ChNet ne résulte pas uniquement d'une mesure de la charge du réseau, mais d'une connaissance fine des pics de charge récurrents quotidiens, hebdomadaires ou saisonniers. En effet, les volumes de téléchargement HAS fluctuent fortement au cours d'une journée, avec de forts pics de consommation en soirée. Ainsi, pour un même contenu, et une même charge de réseau mesurée au début de son téléchargement, des débits d'encodage apparents différents vont pouvoir être exposés dans le fichier manifest, selon l'heure à laquelle ce contenu est demandé par l'utilisateur.
On présente désormais, en relation avec Fig 4, la structure matérielle d'une plateforme 40 de gestion de l'accès à un contenu numérique accessible en téléchargement progressif adaptatif (HAS), connectée au réseau de distribution 1 d'un opérateur.
Elle comprend, classiquement, des mémoires M associées à un processeur CPU. Les mémoires peuvent être de type ROM (de l'anglais « Read Only Memory ») ou RAM (de l'anglais « Random Access Memory ») ou encore Flash. La plateforme 40 communique avec le réseau Internet étendu 1 via un module E/S pour une communication avec d'autres serveurs et équipements du réseau, par exemple le serveur de contenus 2, auquel elle fournit le fichier manifest 7. La plateforme 40 comprend en outre un module MONIT_ChNet de mesure de la charge du réseau 1, apte à affecter une valeur au critère de charge ChNet. Cette valeur peut être enregistrée par exemple dans les mémoires M de la plateforme 40.
La plateforme 40 comprend également un module ENCOD(Ci) d'encodage des segments vidéo d'un contenu Ci, selon une technique d'encodage à débit variable VBR.
Elle comprend également un module PREP_MANIFEST de préparation du fichier manifest 7, pour le contenu Ci, qui expose dans ce fichier les débits d'encodage apparents calculés par le calculateur CPU, en fonction du critère de charge ChNet délivré par le module MONIT_ChNet et des valeurs de débit maximum d'encodage MBR et de débit moyen d'encodage ABR fournis par le module d'encodage ENCOD(Ci) pour un niveau de qualité donné du contenu Ci.
On notera que le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
Plus généralement, une telle plateforme 40 comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d’un processeur CPU, et pilotée par un programme d’ordinateur, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive avant d’être exécutées par le processeur CPU de l’unité de traitement. La mémoire vive contient notamment la valeur du critère de charge ChNet. Le processeur de l'unité de traitement pilote la détermination des débits d'encodage apparent à exposer dans le fichier manifest 7, selon l'algorithme de Fig 2.
Fig 4 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser une plateforme de préparation de contenu afin qu'elle effectue les étapes du procédé détaillé ci-avant, en relation avec Fig 2 (dans l'un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). ANNEXE 1 : exemple de fichier manifest
Figure imgf000021_0001

Claims

REVENDICATIONS
1. Procédé de gestion de l'accès à un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau (1) de distribution dudit contenu, ledit contenu numérique étant associé à un fichier (7) de description dudit contenu numérique, comprenant une liste de segments temporels (Cli@Nj) dudit contenu associés chacun à plusieurs niveaux de qualité dudit contenu, lesdits segments temporels dudit contenu numérique étant encodés (20) selon une méthode d'encodage à débit variable (VBR) borné, pour un niveau de qualité donné, par un débit d'encodage maximum (MBR) desdits segments pour ledit niveau, un débit d'encodage, dit débit d'encodage apparent, étant exposé dans ledit fichier de description pour chaque niveau de qualité dudit contenu, caractérisé en ce qu'il comprend une détermination (21) d'au moins un critère de charge (ChNet) dudit réseau de distribution, et une adaptation (22), en fonction dudit au moins un critère de charge (ChNet) déterminé, desdits débits d'encodage apparents (Nj) exposés dans ledit fichier (7) de description, ladite adaptation d'un débit d'encodage apparent (Nj), pour un niveau de qualité donné, affectant audit débit d'encodage apparent (Nj) une valeur comprise entre ledit débit d'encodage maximum
(MBRj) pour ledit niveau de qualité donné et un débit d'encodage moyen (ABRj) correspondant à une moyenne des débits d'encodage des segments dudit contenu pour ledit niveau de qualité donné.
2. Procédé de gestion de l'accès à un contenu numérique selon la revendication 1, caractérisé en ce que, pour un niveau de qualité donné, ledit débit d'encodage apparent (Nj) prend une valeur égale à (MBR-ABR)/100*ChNet+ABR, où MBR désigne ledit débit d'encodage maximum des segments du contenu pour ledit niveau de qualité donné, ABR désigne ledit débit d'encodage moyen des segments du contenu pour ledit niveau de qualité donné et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge.
3. Procédé de gestion de l'accès à un contenu numérique selon la revendication 2, caractérisé en ce qu'il comprend une mesure d'une charge dudit réseau (1) de distribution et en ce que ladite valeur affectée audit au moins un critère de charge (ChNet) dudit réseau (1) est fonction de ladite mesure.
4. Procédé de gestion de l'accès à un contenu numérique selon l’une quelconque des revendications 1 à 3, caractérisé en ce que ledit au moins un critère de charge (ChNet) dudit réseau (1) tient également compte d'au moins un paramètre appartenant au groupe comprenant : une prédiction de charge dudit réseau ; une consommation électrique dudit réseau ; une période de l'année ; une programmation de mise à jour d'équipements dudit réseau.
5. Procédé de gestion de l'accès à un contenu numérique selon l’une quelconque des revendications 1 à 4, caractérisé en ce que ledit contenu numérique ( ) est diffusé sur ledit réseau (1) en temps réel.
6. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l’une quelconque des revendications 1 à 5, lorsqu'il est exécuté par un processeur.
7. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l’une quelconque des revendications 1 à 5.
8. Plate-forme (40) de gestion de l'accès à un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau (1) de distribution dudit contenu, ledit contenu numérique étant associé à un fichier (7) de description dudit contenu numérique, comprenant une liste de segments temporels (Cli@Nj) dudit contenu associés chacun à plusieurs niveaux de qualité dudit contenu, lesdits segments temporels dudit contenu numérique étant encodés selon une méthode d'encodage à débit variable (VBR) borné, pour un niveau de qualité donné, par un débit d'encodage maximum (MBR) desdits segments pour ledit niveau, un débit d'encodage, dit débit d'encodage apparent, étant exposé dans ledit fichier de description pour chaque niveau de qualité dudit contenu, caractérisée en ce qu'elle comprend un calculateur (CPU) apte à adapter lesdits débits d'encodage apparents (Nj) exposés dans ledit fichier (7) de description, en fonction d'au moins un critère de charge (ChNet) dudit réseau (1) de distribution, ledit calculateur étant apte à affecter à un débit d'encodage apparent (Nj) pour un niveau de qualité donné une valeur comprise entre ledit débit d'encodage maximum (MBRj) pour ledit niveau de qualité donné et un débit d'encodage moyen (ABRj) correspondant à une moyenne des débits d'encodage des segments dudit contenu pour ledit niveau de qualité donné.
9. Plate-forme (40) de gestion de l'accès à un contenu numérique selon la revendication 8, caractérisée en ce que ladite valeur affectée par ledit calculateur (CPU) audit débit d'encodage apparent (Nj) pour un niveau de qualité donné est égale à (MBR-ABR)/100*ChNet+ABR, où MBR désigne ledit débit d'encodage maximum des segments du contenu pour ledit niveau de qualité donné, ABR désigne ledit débit d'encodage moyen des segments du contenu pour ledit niveau de qualité donné et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge.
10. Plate-forme (40) de gestion de l'accès à un contenu numérique selon la revendication 8, caractérisée en ce qu'elle comprend un module (MONIT_ChNet) de mesure d'une charge dudit réseau (1) de distribution et en ce que ledit calculateur (CPU) affecte audit au moins un critère de charge (ChNet) dudit réseau une valeur qui est fonction de ladite charge mesurée.
PCT/FR2021/050638 2020-04-16 2021-04-12 Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau WO2021209706A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2003825 2020-04-16
FR2003825A FR3109489B1 (fr) 2020-04-16 2020-04-16 Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau

Publications (1)

Publication Number Publication Date
WO2021209706A1 true WO2021209706A1 (fr) 2021-10-21

Family

ID=72356059

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/050638 WO2021209706A1 (fr) 2020-04-16 2021-04-12 Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau

Country Status (2)

Country Link
FR (1) FR3109489B1 (fr)
WO (1) WO2021209706A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160182594A1 (en) * 2014-12-19 2016-06-23 Cable Television Laboratories, Inc. Adaptive streaming
US20160205162A1 (en) 2012-07-12 2016-07-14 Futurewei Technologies, Inc. Signaling and Processing Content with Variable Bitrates for Adaptive Streaming
WO2017167958A1 (fr) 2016-04-01 2017-10-05 Orange Procede d'optimisation du debit de contenus multimedia accessibles par au moins un terminal utilisateur, produit programme d'ordinateur et dispositif de gestion correspondants
FR3055762A1 (fr) * 2016-09-07 2018-03-09 Ericsson It Solutions & Services Sas Procede et dispositif d'encodage d'un contenu audiovisuel destine a etre diffuse par telechargements successifs de morceaux de donnees

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160205162A1 (en) 2012-07-12 2016-07-14 Futurewei Technologies, Inc. Signaling and Processing Content with Variable Bitrates for Adaptive Streaming
US20160182594A1 (en) * 2014-12-19 2016-06-23 Cable Television Laboratories, Inc. Adaptive streaming
WO2017167958A1 (fr) 2016-04-01 2017-10-05 Orange Procede d'optimisation du debit de contenus multimedia accessibles par au moins un terminal utilisateur, produit programme d'ordinateur et dispositif de gestion correspondants
FR3055762A1 (fr) * 2016-09-07 2018-03-09 Ericsson It Solutions & Services Sas Procede et dispositif d'encodage d'un contenu audiovisuel destine a etre diffuse par telechargements successifs de morceaux de donnees

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Technologies under Consideration for DASH", no. n18815, 3 February 2020 (2020-02-03), XP030225532, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/128_Geneva/wg11/w18815-v2-w18815.zip SC29WG11_N18815_DASH_TuC.docx> [retrieved on 20200203] *

Also Published As

Publication number Publication date
FR3109489B1 (fr) 2022-08-05
FR3109489A1 (fr) 2021-10-22

Similar Documents

Publication Publication Date Title
EP3949434A1 (fr) Procédé de diffusion de contenus en streaming dans un réseau pair à pair
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
WO2019220034A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique au sein d&#39;un terminal de restitution d&#39;un réseau de communication local
FR3081647A1 (fr) Gestion du telechargement progressif adaptatif (has) d&#39;un contenu numerique au sein d&#39;un terminal lecteur de flux multimedia en temps reel.
EP4055831A1 (fr) Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d&#39;ordinateur correspondants
EP3987820A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d&#39;un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
WO2021209706A1 (fr) Gestion de l&#39;accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d&#39;encodage à débit variable, en fonction d&#39;une charge réseau
EP4035408A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique sur réseau mobile avec sélection d&#39;un débit d&#39;encodage maximum autorisé en fonction d&#39;un godet de données
EP2819424A1 (fr) Procédé d&#39;amelioration du temps de changement entre programmes audiovisuels
WO2023208688A1 (fr) Gestion de la restitution d&#39;un contenu multimédia
EP3926929B1 (fr) Procédé de gestion de la lecture d&#39;un contenu numérique au sein d&#39;un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
FR3103668A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec détermination d’un débit d’encodage maximum autorisé sur une session en fonction d’un godet de données
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
FR3093605A1 (fr) Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants.
FR3093603A1 (fr) Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants.
EP3846489A1 (fr) Procédé de gestion d&#39;un téléchargement progressif et adaptatif d&#39;un contenu numérique par un terminal lecteur de flux multimédia connecté à un réseau de communication, dispositif de gestion, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
WO2021105585A1 (fr) Procédé de gestion d&#39;une liste de contenus accessibles au zapping, les contenus numériques étant téléchargeables en mode de téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d&#39;ordinateur correspondants
FR3114720A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu tenant compte de la qualité du signal échangé entre le terminal client et le point d’accès au réseau
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
FR3116684A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu acheté, tenant compte d’un historique de niveaux de qualité de lecture de contenu par un terminal lecteur de flux multimédia
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
WO2020234030A1 (fr) Restitution d&#39;un contenu en arrière-plan ou sous forme d&#39;incrustation dans le cadre d&#39;un téléchargement progressif adaptatif de type has
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
FR3124344A1 (fr) Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21726437

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21726437

Country of ref document: EP

Kind code of ref document: A1