EP4035408A1 - Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données - Google Patents

Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données

Info

Publication number
EP4035408A1
EP4035408A1 EP20792466.3A EP20792466A EP4035408A1 EP 4035408 A1 EP4035408 A1 EP 4035408A1 EP 20792466 A EP20792466 A EP 20792466A EP 4035408 A1 EP4035408 A1 EP 4035408A1
Authority
EP
European Patent Office
Prior art keywords
content
data
terminal
multimedia stream
consumed
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP20792466.3A
Other languages
German (de)
English (en)
Inventor
Mathieu Rivoalen
Hervé Marchand
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of EP4035408A1 publication Critical patent/EP4035408A1/fr
Pending legal-status Critical Current

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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44245—Monitoring the upstream path of the transmission network, e.g. its availability, bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/215—Flow control; Congestion control using token-bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/38—Flow control; Congestion control by adapting coding or compression rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering

Definitions

  • TITLE Management of adaptive progressive downloading of digital content on a mobile network with selection of a maximum authorized encoding rate according to a bucket of data
  • 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 management of the data consumption of a user wishing to access digital content according to a technique known as adaptive progressive downloading, through a mobile communication network.
  • Access to multimedia content is possible today for most playback terminals, even when they are on the move, through a mobile communication network.
  • 4G type for example.
  • the terminal generally sends a request to a server, indicating the chosen content, 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 speed available to the user is not guaranteed for the transfer in real time of the video, which is particularly the case when the terminal is connected to a mobile communication network, for example. example a 4G type network, known for its variability in bandwidth.
  • Adaptive progressive download in English HTTP Adaptive Streaming, abbreviated HAS, furthermore makes it possible to broadcast and receive data according to 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 variable 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 primary target protocol is HTTP, but other protocols (eg FTP) can also be used.
  • FTP FTP
  • 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.
  • the rendering terminal must therefore find a compromise between the overall quality of the content, and its uninterrupted reproduction, by carefully selecting the next segment to download, among the various encoding rates offered. To do this, there are different algorithms for selecting the quality of the content as a function of the available bandwidth, which may have more or less aggressive, or more or less secure, strategies.
  • 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.
  • real-time media stream player devices also access digital content in progressive adaptive download mode for real-time (or Live) television content. This is the case, for example, with the Chromecast ® device developed by Google ® , or the CléTV ® from Orange ® . Such devices, more generically referred to as the HDMI Key, can also be used to access video-on-demand content.
  • 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
  • data consumption limit authorized for the client terminal.
  • This limit may correspond to a volume of data associated with a prepaid card purchased by the user, or to a monthly package that he has taken out with the operator of the extended communication network, for example the mobile network.
  • This maximum amount of consumable data is more commonly referred to as the data bucket, or "data bucket”.
  • data bucket the data bucket
  • data represents data downloaded to a telephone or a mobile terminal via the Internet.
  • a mobile data plan therefore allows users to browse the Internet with a mobile phone, according to specific volumes allocated by the network operator. Strictly speaking, unlimited plans in this area do not exist. Data plans include a maximum authorized data volume, generally expressed in Megabytes or Gigabytes.
  • the HAS client on board his multimedia stream reader terminal has, in principle, for objective, to achieve the best possible reproduction quality for the user, as a function of resource and bandwidth constraints, and therefore to aim for the maximum encoding rate available for the content to be downloaded.
  • the downloading of content can consume a very large proportion, if not all, of the data bucket allocated to the user, without the latter having any means of action to prevent it.
  • the only option available to the user is, quite radically, to give up accessing the stream, and therefore to give up watching the chosen multimedia content.
  • the invention responds to this need by providing a method for managing the adaptive progressive download (HAS) of digital content within a multimedia stream reader terminal connected to a mobile communication network.
  • the digital content is associated with a description file, comprising a list of time segments of the content each associated with several encoding rates of the content.
  • a maximum volume of data to be consumed within the mobile communication network, called a data bucket, is allocated to the multimedia stream reader terminal.
  • such a management method implements: a determination of a volume of data which would be consumed by the multimedia stream reader terminal by downloading the time segments of the content at at least some of the encoding rates, a selection of a maximum encoding rate of the content authorized for the download, depending on the amount of data consumed associated with it, and the data bucket.
  • the invention is based on a completely new and inventive approach to the adaptive progressive downloading of content, in the case where the multimedia stream reader terminal has a maximum volume of consumable data within its access network to the network.
  • content Such a limit value for data consumption, also called a “data bucket”, can correspond to a volume of data authorized within the framework of a monthly package taken out with a network operator, or associated with a prepaid card purchased from this operator.
  • the method according to one embodiment of the invention proposes to take this "data bucket" into account in the choice of the encoding rate at which the HAS client on board the multimedia stream reader terminal downloads the time segments of the content.
  • the data consumption resulting from the downloading of the content at different encoding rates is evaluated; taking into account this consumption assessment on the one hand, and the user's data bucket on the other hand, a maximum encoding rate is selected making it possible to restrict the progressive adaptive HAS downloading of the content, in order to better control the share of the data bucket devoted to this download.
  • such a management method also comprises a display, on a reproduction terminal associated with the multimedia stream reader terminal, of the volumes of data consumed determined for at least some of the encoding rates.
  • the user can thus easily know the volume of data that will be consumed by his terminal if he starts downloading the content he has chosen, at one or other of the available encoding rates: all he needs is to do this, consult the screen of his return terminal, on which these volumes are presented to him. This is particularly advantageous when the user is in a mobility solution, and he does not necessarily understand the impact that the launch of the download of content will have on his data consumption, and therefore on his data bucket.
  • a consultation of the screen of his rendering terminal indicates to him directly, for example in the form of a comparative table, the volumes of data, for example expressed in Gigabits or in Megabits, associated with the different speeds of encoding of the content.
  • the assumption is made that all the time segments of the content will be downloaded at the same encoding rate, or at the same resolution, without taking into account any fluctuations associated with changes in the constraints of network resources or from the content server.
  • the playback terminal can be the multimedia stream reader terminal itself (for example an intelligent mobile telephone of the smartphone type), or be distinct from it (for example a television connected to an HDMI key).
  • the volumes of data consumed, determined for at least some of the encoding rates are displayed in the form of a proportion of the data bucket.
  • the user can thus directly understand what percentage of his data bucket will be consumed in the event of launching the download of the content at a particular encoding rate. Such a presentation is more meaningful and understandable for the user. It of course requires that this data bucket be known to the multimedia stream reader terminal.
  • such a management method also comprises a display, on the reproduction terminal, of a volume of data remaining to be consumed by the multimedia stream reader terminal, after the downloading of the time segments of the content at at least some of the encoding rates.
  • the user knows not only what volume of data will be consumed by downloading the content, but also how much data he will still have at the end of this download, taking into account his data bucket, and possibly the part he has already consumed.
  • This display of remaining volume can be done in Gigabits / Megabits, or as a percentage of the data bucket.
  • the user can thus easily choose the maximum encoding rate to which he wishes to limit himself, so as not to consume too much of his data bucket, and to keep enough data credit, for example until the end of the month.
  • the displayed data volumes correspond only to the encoding rates for which the downloading of the time segments of the content does not induce the data bucket to be exceeded.
  • such a management method also comprises an entry, on a reproduction terminal associated with the multimedia stream reader terminal, of the data bucket.
  • the user pre-informs his data bucket, so that this information is accessible to the multimedia stream reader terminal.
  • This entry can be made during an installation or configuration phase of the adaptive progressive download service. It can also be requested from the user by displaying a “pop in” type window, which informs him of an innovation in the service, and asks him about this new useful information which is his bucket. data.
  • the mobile network operator controls the adaptive progressive download service from end to end, it can extract the user's data bucket information from their profile or billing, so that it is accessible to the user. multimedia stream player terminal.
  • the selection of the maximum encoding rate of the content authorized for downloading is performed by a user via an interface of a playback terminal associated with the multimedia stream reader terminal.
  • the user himself chooses the maximum encoding rate to be set, via the interface of his rendering terminal, for example by selecting a highlighted menu or by entering in a pop-in window.
  • This selection may be valid only for a given content, or may be taken into account for all content accessible via the adaptive download service HAS, or even for all content downloaded during a given period (for example during the current month). .
  • 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 of managing the adaptive progressive download (HAS) of a. digital content according to the invention, as described above.
  • HAS adaptive progressive download
  • 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 an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer 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 device for managing the adaptive progressive download (HAS) of digital content within a multimedia stream reader terminal connected to a mobile communication network.
  • Such digital content is associated with a description file, comprising a list of time segments of the content each associated with several encoding rates of the content; a maximum volume of data to be consumed within the mobile communication network, called a data bucket, is allocated to the multimedia stream reader terminal.
  • a device comprises:
  • such a device for managing the adaptive progressive download (HAS) of digital content also comprises a module for transmitting a command, to a reproduction terminal associated with the multimedia stream reader terminal, display consumed data volumes determined for at least some of the encoding rates.
  • HAS adaptive progressive download
  • Such a command can be a command internal to the device when the latter is integrated into the playback terminal itself.
  • the invention also relates to a multimedia stream reader terminal which comprises a device for managing the adaptive progressive download (HAS) of digital content as described above.
  • HAS adaptive progressive download
  • the adaptive progressive download management device, the playback multimedia stream reader terminal and the computer program according to embodiments of the invention have in combination all or part of the characteristics set out throughout this document. In particular, they have at least the same advantages as those conferred by the method for managing the adaptive progressive downloading of content according to one embodiment of the present invention.
  • FIG 1 presents a progressive download architecture on a mobile network based on the use of adaptive streaming according to the invention
  • FIG 2 schematically illustrates the hardware structure of a multimedia stream reader terminal incorporating an adaptive progressive download management device according to one embodiment of the invention
  • FIG 3 describes an example of limiting the maximum quality of a multimedia stream obtained in adaptive progressive download mode by a multimedia stream reader terminal of [Fig 1] or [Fig 2].
  • the general principle of the invention is based on the possibility, within the framework of the adaptive progressive downloading of a content, of selecting the maximum encoding rate of the content authorized for the download, so as not to consume too large a portion of the bucket. user data, especially when on the move.
  • 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 mobile communication network 1, for example a 4G type 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.).
  • URI Universal Resource Identifier
  • All of these parameters are generally grouped together in a parameter file, called a description file. It will be noted that this parameter file can be a computer file or a set of descriptive information about the content, accessible at a certain address.
  • 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 the bit rates 512 kb / s (kilobits per second) (Resolution 1, or level 1, denoted NI), 1024 kb / s (N2), 2048 kb / s (N3) and 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. In general, we denote “Ci @ Nj” the content number i with the quality j (for example the j-th level Nj of quality described in the description file).
  • the client terminals 3, 4 receive the data coming from the extended mobile 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 TV 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 of fixed or determinable duration.
  • the HDMI key 8 is 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 smartphone 3 or the tablet 4 are, for example, transmitted via WiFi® to the HDMI key 8, which controls their display on the television screen 5, for restitution to the user.
  • FIG 2 represents an architecture of a multimedia stream reader terminal according to one embodiment of the invention, for example the HDMI key 8, or the smart phone 3, of [Fig 1]. following the example of the HDMI 8 key.
  • the HDMI 8 key communicates with the extended Internet network 1 via the WIFI module for local wireless communication with another communication terminal, for example the smart phone 3.
  • the HDMI 8 key also includes a HAS adaptive progressive download module capable of requesting a progressive download of one of the contents with one of the qualities proposed in a description file 7. This description file 7 can be recorded for example in the memories M of the HDMI key 8 or be outside.
  • the HDMI key 8 also includes a DET module for determining a volume of data which would be consumed by adaptive progressive downloading of content, with the different qualities proposed in the description file 7.
  • a DISP module for controlling the display of the data volumes determined by the module DET on a screen of a rendering terminal, for example the smart phone 3 or the television 5. More generally, such a DISP module is a module for managing the interface with the user's playback terminal, by which the HDMI key 8 obtains, for example, information on any interactions the user has with the playback terminal (action on the television remote control by for example by pressing the volume key or a channel change key, or selecting from a menu highlighted on the television screen of a maximum quality of content authorized, or selecting this maximum quality on the touch screen of the telephone intelligent 3 or tablet 4), and by which it can control the display on the screen of the display terminal for rendering pop-up windows, allowing it to deliver messages, information on data volumes consumed or remaining, or user alerts.
  • a DISP module for controlling the display of the data volumes determined by the module DET on a screen of a rendering terminal, for example the smart phone 3 or the television 5. More generally, such a DISP module is a module for managing the interface with
  • SEL module for selecting a maximum encoding rate or a maximum resolution authorized for downloading the content, which controls the adaptive progressive download module HAS, in order to force the latter to request a progressive download of the content.
  • the HDMI key 8 can also contain other modules such as a hard disk (not shown) for storing video fragments, a content access control module, a data processing module. commands received from a tablet or smartphone on which the application for controlling the HDMI key is installed, thanks to which the user can control its operation, etc.
  • a hard disk not shown
  • commands received from a tablet or smartphone on which the application for controlling the HDMI key is installed thanks to which the user can control its operation, etc.
  • such an HDMI 8 key does not generally contain no I / O interface module, and it is the I / O interface module of the user's smartphone 3 or tablet 4, or of the TV 5, which is used by the latter to choose by example its content.
  • 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. .).
  • HDMI 8 key 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, representative of the progressive download management module.
  • adaptive HAS stored in read only memory (eg ROM or hard disk).
  • 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 description file manifest 7.
  • the processor of the processing unit controls the determination of the volumes of data consumed by downloading the content at its various quality levels, the display of pop-up windows on the display of the display terminal, and restricting the quality of the downloaded content, through the choice of the time segments and the associated encoding rates to download, and the issuance of corresponding commands to the HAS client module.
  • the architecture proposed in [Fig 2] remains the same, except that the terminal communicates directly. with the extended communication network via a mobile communication module, for example of the 4G type, instead of the WIFI module.
  • the rendering terminal is then the multimedia stream reader terminal itself, so that the display control module DISP controls the display of the estimated data volumes directly on the screen of the smart phone 3, and the module SEL directly receives the value of the maximum quality of the authorized content selected by the user on the screen of the smartphone 3 itself.
  • FIG 2 illustrates only one particular way, among several possible, of producing a multimedia stream reader terminal, so that it performs the steps of the method detailed below, in relation to [Fig 3] (in any one 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.
  • the multimedia stream reader terminal 30 is connected to a TX playback terminal (for example the HDMI key 8 is connected to the television 5 via an HDMI link or to the smart phone 3 via a WIFI link. ). It comprises a DISP 300 interface module with the TX rendering terminal, a DET module 301 for determining the volume of data consumed by downloading a content at its various encoding rates, a SEL module 302 for selecting a maximum encoding rate allowed for the download, and a HAS 303 client module.
  • a HAS content server 2 exposes a video C1 in the form of “chunks” Cli @ Nj encoded at different 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 way in which 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.
  • 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 client module In the conventional case, if a video “chunk” lasts 3 seconds, the recovery of the “chunk” by the HAS client module must not exceed 3 seconds, in order to allow restitution of the content without interruption by the terminal 30. It is therefore appropriate for the HAS client module to operate the best compromise between a reproduction quality, and therefore an encoding rate, as high as possible, and the download time of the fragment, which must be low enough to allow continuous reproduction on the TX restitution terminal.
  • the HAS client module 303 may not order the download of the fragment at the optimum encoding rate, in order to limit the consumption of the user's data bucket, such as described in more detail below.
  • the HAS module 303 recovers the manifest file 7 in order to discover the available fragments of the video content C1, and the various associated video qualities Nj.
  • the multimedia stream transport technology is of the HAS type with five levels of encoding bit rate and resolution available, according to the example given in the table [Table 1]. below.
  • N2 1200 kb / s
  • a third encoding rate N3 2100 kb / s, etc.
  • the HAS 303 module downloads, for example, successive Cli @ Nl fragments (i.e. the first temporal fragment at an encoding rate of 600 kb / s), then Cl 2 @ N3 (ie the second time fragment at an encoding rate of 2100 kb / s), then Cl 3 @ N3 (ie the third time fragment at an encoding rate of 2100 kb / s), .. .
  • the various fragments downloaded by the HAS client module 303 are transmitted to the DISP 300 interface module for their return to the user on the screen of the TX reproduction terminal.
  • the algorithm implemented by the HAS 303 client module to determine which fragment at which encoding rate should be downloaded in normal operating mode (i.e. outside of the encoding rate restricting by the module SEL 302) can be one of the already existing algorithms of the prior art. This algorithm will therefore not be described in more detail here.
  • the DET module 301 determines the volume of data that would be consumed by downloading the content C1 at the different resolution levels of [Table 1] To do this, the DET module 301 uses for example a hypothesis simplifying, according to which the download takes place at the same level of resolution for the duration of the content, that is, in this example for two hours, or 7200 seconds. Although it does not correspond to the actual operation of HAS type downloading, this hypothesis allows a good estimate of the amount of data that could be consumed by downloading the content at each of the resolution levels proposed in the manifest file 7.
  • the result of all the calculations performed is summarized in the table below.
  • This data bucket corresponds for example to a volume of data associated with a prepaid card which it has acquired from the operator of the mobile network 1. It can also correspond to a monthly package that it has subscribed to with this operator, for example a 50GB / month package.
  • the user's data bucket is known to the operator, from the offer subscribed to by the operator. user, or their billing information. It is therefore the operator who transmits this information to terminal 30.
  • this data bucket can also be entered by the user himself. It can for example be entered via the interface of the TX rendering terminal (smart phone 3, or television 5 for example), during an installation phase of the HAS download service, or in response to a request from the service provider. this service, for example via a “pop in” window informing the user of new features or innovations in the service.
  • the DET module 301 can then easily determine, for each of the resolutions proposed in the manifest file 7, the part of the data bucket that will be consumed in the event of downloading the content at this resolution, and the portion of this bucket that will remain with the client afterwards. download, based on current monthly consumption.
  • the result of the calculations carried out by the DET 301 module can be displayed, for example in the form of the table [Table 3] below, on the screen of the TX restitution terminal.
  • the terminal 30 then offers the customer, on the strength of this knowledge of his level of data bucket consumed and remaining after downloading, to define a high limit of the encoding rate of the content to be downloaded: the different fragments of the content C1 will then not be able to be downloaded at an encoding rate greater than this high limit selected by the user.
  • the user decides for example that he wishes to view the content C1, but without exceeding 7% of consumption of his data bucket: he therefore chooses to restrict the downloading of the fragments of the content to a maximum resolution of 1280x720 pixels. .
  • the interface of the TX rendering terminal uses the interface of the TX rendering terminal. For example, on the television screen 5, he selects, by means of a remote control, one of the rows of the table [Table 3], which is displayed for example in highlight. In another example, he selects this maximum authorized encoding rate by clicking on the appropriate row of the table [Table3] displayed on the touch screen of the smartphone 3. Any other type of interface configuration could also be used, such as a banner, a pop-in window, etc.
  • the multimedia stream reader terminal 30 can make this selection itself, without the intervention of the user, for example by applying a principle of precaution with regard to the consumption of the data bucket. It can also encourage the user to select a low value for the maximum authorized encoding rate, for example by highlighting on the screen of the reproduction terminal a maximum recommended encoding rate value, depending on the share of the user. Bucket of data remaining after download. The user then only has to confirm or reject this pre-selection. The selected value feeds the selection module SEL 302, which communicates it to the HAS module 303, so as to restrict the downloading of the content fragments at the maximum encoding rate of 3Mb / s chosen by the user.
  • the HAS 303 client module will successively download (312) the fragments Cl 2 @ N3, Cl 3 @ N3, C1 4 @ N2, C1 5 @ N1 and Cl 6 @ N3, c ' that is, download the best possible quality fragment based on network constraints, but never exceeding the maximum encoding rate MAX 311, which has been selected by the user to be 2100kb / s.
  • the HAS 303 client module determines, depending on the network conditions, that the optimal rate of time fragment at which it can claim is 5000kb / s, it does not start the download of the next fragment at this optimal rate, but downloads the temporal fragment Cl 6 @ N3, at the maximum encoding rate allowed by the client.
  • the module DET 301 for determining the volume of data consumed can only determine the absolute value of the volume of data consumed by downloading the content C1 at the various resolution levels proposed in the manifest file 7, and not its relative value by compared to the data bucket.
  • the data in the table [Table 2] can be displayed, upon action of the display control module DISP 300, on the screen of the TX rendering terminal.
  • the level of consumption of the multimedia stream C1 is simply presented at its various encoding rates, and the user must make a selection of the maximum encoding rate that he authorizes as a function only of the number of GB consumed at each of the flow rates.
  • the user Since the user is most often aware of their data bucket, they can perform a quick head calculation to help them make a decision. Thus, if he wants to watch the VOD Cl, he can be ready to consume 2.7GB of his monthly data bucket, even if it means restricting his consumption during the rest of the month on other services or applications. In this case, it selects, in the table [Table2], the resolution of 1280x720 pixels, and the associated maximum encoding rate of 3Mb / s.
  • the configuration of the interface of the TX rendering terminal making this selection possible can take any appropriate form.
  • the display of the data restitution terminal is therefore displayed on the screen allowing the user to better understand the impact of downloading the content C1 on his data consumption, so that he has the necessary tools to adapt its content consumption, depending on its capabilities.
  • the selection of the maximum encoding rate MAX 311 is effective only for the content C1 being downloaded HAS.
  • this selection can be applied to all the multimedia streams accessible via the content server 2, or to all the multimedia streams that the user will download during a given period (for example the current month in the event of monthly flat rate), or during a given period during which the user is on the move.
  • the DISP 300 module does not display all the lines of the tables [Table 2] and [Table 3] on the screen of the TX restitution terminal, but only the lines corresponding to the encoding rates which do not result in the user data bucket being exceeded.
  • the customer is only offered the encoding speeds to which he can claim in order to be able to at least view the entire K1 content, if he does not have enough consumable data left to see it at the maximum available quality. .
  • content C1 of the video on demand (VOD) type was given above. It will be noted that the content C1 can also be a deferred television program (or “replay”), or a live television program (“Live”). In the latter case, the duration of the program necessary for the calculation by the DET module 301 of the volume of data consumed can be extracted from the electronic program guide EPG (“Electronic Program Guide”).
  • EPG Electronic Program Guide
  • the present invention can be implemented on set-top boxes, on the CléTV ® d'Orange ® and generally on all terminals consuming HAS videos while on the move. (on mobile network).

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique (C1) au sein d'un terminal lecteur de flux multimédia (30) connecté à un réseau de communication mobile. Le contenu numérique est associé à un fichier de description (7) du contenu numérique, comprenant une liste de segments temporels (C1i@Nj) du contenu, associés chacun à plusieurs débits d'encodage du contenu. Un volume maximum de données à consommer au sein du réseau de communication mobile, appelé godet de données, est alloué au terminal lecteur de flux multimédia. Selon l'invention, au lancement du téléchargement progressif adaptatif du contenu numérique, un tel procédé de gestion met en œuvre : - une détermination (DET 301) d'un volume de données qui serait consommé par le terminal lecteur de flux multimédia par téléchargement des segments temporels à au moins certains des débits d'encodage, - une sélection (SEL 302) d'un débit d'encodage maximum du contenu autorisé pour le téléchargement, en fonction du volume de données consommé qui lui est associé, et du godet de données.

Description

DESCRIPTION
TITRE : Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données
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 gestion de la consommation de données d'un utilisateur souhaitant accéder à des contenus numériques selon une technique dite de téléchargement progressif adaptatif, au travers d'un réseau de communication mobile.
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, même lorsqu'ils sont en situation de mobilité, à travers un réseau de communication mobile de type 4G par exemple.
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, ce qui est tout particulièrement le cas lorsque le terminal est connecté à un réseau de communication mobile, par exemple un réseau de type 4G, connu pour ses variabilités de bande passante.
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.
Dans ce cadre spécifique de diffusion de contenus sur un réseau de communication mobile, il est important de prendre en compte la limite de consommation de données autorisée pour le terminal client. Cette limite peut correspondre à un volume de données associé à une carte prépayée achetée par l'utilisateur, ou à un forfait mensuel qu'il a souscrit auprès de l'opérateur du réseau de communication étendu, par exemple le réseau mobile. Ce volume maximum de données consommable est plus communément désigné sous le terme de godet de données, ou « godet data ». En effet, le terme anglais « data » signifie « données ». En langage mobile, la data représente les données téléchargées sur un téléphone ou un terminal mobile grâce à Internet. Un forfait data mobile permet donc aux utilisateurs de naviguer sur Internet avec un téléphone mobile, selon des volumes spécifiques alloués par l'opérateur du réseau. Les forfaits illimités dans ce domaine n’existent pas à proprement parler. Les forfaits data comportent un volume de données maximum autorisé, généralement exprimé en Mégaoctets ou Gigaoctets.
Lorsque l'utilisateur consomme un contenu ou un flux de données selon une technique de téléchargement progressif adaptatif HAS sur un réseau de communication mobile, le client HAS embarqué sur son terminal lecteur de flux multimédia a, par principe, pour objectif, d'atteindre la meilleure qualité de restitution possible pour l'utilisateur, en fonction des contraintes de ressource et de bande passante, et donc de viser le débit d'encodage maximum disponible pour le contenu à télécharger. Il en résulte que le téléchargement de contenu peut consommer une très grosse proportion, voire l'intégralité, du godet de données alloué à l'utilisateur, sans que ce dernier ne dispose d'un quelconque moyen d'action pour l'empêcher. En effet, la seule option dont dispose l'utilisateur est, de façon assez radicale, de renoncer à accéder au flux, et donc de renoncer à regarder le contenu multimédia choisi.
Cette situation s'avère problématique dans la mesure où elle peut conduire l'utilisateur, en situation de mobilité, à dépasser son « godet data », ce qui peut s'avérer onéreux, ou à en consommer l'intégralité en tout début de mois, le privant de ressources pour la fin de la période.
Il existe donc un besoin d'une technique de gestion de téléchargement progressif adaptatif de contenu, notamment pour un utilisateur connecté à un réseau de communication mobile, permettant une meilleure maîtrise de sa consommation de données, par rapport aux solutions antérieures. Notamment, il existe un besoin d'une telle technique qui permette à un utilisateur de visualiser un contenu téléchargé en HAS via un réseau mobile, tout en lui assurant une maîtrise de la consommation de son godet de données.
Exposé de l’invention
L’invention répond à ce besoin en proposant un procédé de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique au sein d'un terminal lecteur de flux multimédia connecté à un réseau de communication mobile. Le contenu numérique est associé à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d'encodage du contenu. Un volume maximum de données à consommer au sein du réseau de communication mobile, appelé godet de données, est alloué au terminal lecteur de flux multimédia.
Selon l'invention, au lancement du téléchargement progressif adaptatif du contenu numérique, un tel procédé de gestion met en oeuvre : une détermination d'un volume de données qui serait consommé par le terminal lecteur de flux multimédia par téléchargement des segments temporels du contenu à au moins certains des débits d'encodage, une sélection d'un débit d'encodage maximum du contenu autorisé pour le téléchargement, en fonction du volume de données consommé qui lui est associé, et du godet de données.
Ainsi, l’invention repose sur une approche tout à fait nouvelle et inventive du téléchargement progressif adaptatif de contenu, dans le cas où le terminal lecteur de flux multimédia dispose d'un volume maximum de données consommables au sein de son réseau d'accès au contenu. Une telle valeur limite de consommation de données, également appelée « godet data », peut correspondre à un volume de données autorisé dans le cadre d'un forfait mensuel souscrit auprès d'un opérateur du réseau, ou associé à une carte prépayée achetée auprès de cet opérateur.
Le procédé selon un mode de réalisation de l’invention propose de tenir compte de ce « godet data » dans le choix du débit d'encodage auquel le client HAS embarqué sur le terminal lecteur de flux multimédia télécharge les segments temporels du contenu. Ainsi, au lieu de systématiquement télécharger les segments temporels du contenu au débit d'encodage maximum accessible, compte tenu des contraintes du réseau et du serveur de contenu, on évalue la consommation de données résultant du téléchargement du contenu à différents débits d'encodage ; en tenant compte, de cette évaluation de consommation d'une part, et du godet data de l'utilisateur d'autre part, on sélectionne un débit d'encodage maximum permettant de brider le téléchargement progressif adaptatif HAS du contenu, afin de mieux maîtriser la part du godet data consacrée à ce téléchargement.
Il est ainsi possible pour l'utilisateur de bénéficier des avantages du téléchargement progressif adaptatif HAS de contenu, sans que cela ne se fasse au détriment de son godet data, qui doit pouvoir être utilisé à d'autres fins ou pour d'autres applications : on offre ainsi à l'utilisateur des outils intéressants de maîtrise de sa consommation de données.
Selon une caractéristique avantageuse, un tel procédé de gestion comprend également un affichage, sur un terminal de restitution associé au terminal lecteur de flux multimédia, des volumes de données consommés déterminés pour au moins certains des débits d'encodage.
L'utilisateur peut ainsi aisément avoir connaissance du volume de données qui sera consommé par son terminal s'il lance le téléchargement du contenu qu'il a choisi, à l'un ou l'autre des débits d'encodage disponibles : il lui suffit pour ce faire de consulter l'écran de son terminal de restitution, sur lequel ces volumes lui sont présentés. Ceci est particulièrement avantageux lorsque l'utilisateur est en solution de mobilité, et qu'il n'appréhende pas nécessairement l'impact qu'aura le lancement du téléchargement de contenu sur sa consommation de données, et donc sur son godet data. Une consultation de l'écran de son terminal de restitution (par exemple son téléphone mobile) lui indique directement, par exemple sous forme d'un tableau comparatif, les volumes de données, par exemple exprimés en Gigabits ou en Mégabits, associés aux différents débits d'encodage du contenu.
Pour simplifier le calcul, on fait par exemple l'hypothèse que tous les segments temporels du contenu seront téléchargés au même débit d'encodage, ou à la même résolution, sans tenir compte des éventuelles fluctuations associées aux évolutions des contraintes de ressources du réseau ou du serveur de contenu.
On notera que le terminal de restitution peut être le terminal lecteur de flux multimédia lui-même (par exemple un téléphone mobile intelligent de type smartphone), ou être distinct de celui-ci (par exemple un téléviseur connecté à une Clef HDMI).
Selon une caractéristique optionnelle avantageuse, les volumes de données consommés, déterminés pour au moins certains des débits d'encodage, sont affichés sous forme d'une proportion du godet de données.
L'utilisateur peut ainsi directement appréhender quel pourcentage de son godet data sera consommé en cas de lancement du téléchargement du contenu à tel ou tel débit d'encodage. Une telle présentation est plus parlante et compréhensible pour l'utilisateur. Elle nécessite bien sûr que ce godet data soit connu du terminal lecteur de flux multimédia.
Selon une autre caractéristique optionnelle avantageuse, un tel procédé de gestion comprend également un affichage, sur le terminal de restitution, d'un volume de données restant à consommer par le terminal lecteur de flux multimédia, à l'issue du téléchargement des segments temporels du contenu à au moins certains des débits d'encodage.
Ainsi, l'utilisateur sait, non seulement, quel volume de données sera consommé par téléchargement du contenu, mais également de quel volume de données il disposera encore à l'issue de ce téléchargement, en tenant compte de son godet data, et éventuellement de la part qu'il en a déjà consommée. Cet affichage de volume restant peut se faire en Gigabits/Megabits, ou en pourcentage du godet data. L'utilisateur peut ainsi aisément choisir le débit d'encodage maximum auquel il souhaite se limiter, pour ne pas consommer une trop grosse partie de son godet data, et conserver suffisamment de crédit de données, par exemple jusqu'à la fin du mois.
Selon une autre caractéristique avantageuse, les volumes de données affichés correspondent aux seuls débits d'encodage pour lesquels le téléchargement des segments temporels du contenu n'induit pas de dépassement du godet de données.
Ainsi, si le godet data de l'utilisateur est connu, on peut lui indiquer uniquement les débits d'encodage auxquels il peut prétendre pour pouvoir, a minima, voir intégralement le contenu, s'il ne lui reste plus assez de données consommables pour le voir en qualité maximale. Selon une autre caractéristique, un tel procédé de gestion comprend également une saisie, sur un terminal de restitution associé au terminal lecteur de flux multimédia, du godet de données.
Ainsi, l'utilisateur pré-renseigne son godet data, pour que cette information soit accessible au terminal lecteur de flux multimédia. Cette saisie peut s'opérer dans une phase d'installation ou de configuration du service de téléchargement progressif adaptatif. Elle peut également être demandée à l'utilisateur par l'affichage d'une fenêtre de type « pop in », qui l'informe d'une nouveauté sur le service, et l'interroge sur cette nouvelle information utile qu'est son godet data. En variante, si l'opérateur du réseau mobile contrôle de bout en bout le service de téléchargement progressif adaptatif, il peut extraire l'information du godet data de l'utilisateur de son profil ou de sa facturation, pour qu'elle soit accessible au terminal lecteur de flux multimédia.
Selon un mode de réalisation de l'invention, la sélection du débit d'encodage maximum du contenu autorisé pour le téléchargement est effectuée par un utilisateur via une interface d'un terminal de restitution associé au terminal lecteur de flux multimédia.
Ainsi, l'utilisateur choisit lui-même le débit d'encodage maximum à fixer, via l'interface de son terminal de restitution, par exemple par sélection d'un menu en surbrillance ou par saisie dans une fenêtre pop in. Cette sélection peut être valable uniquement pour un contenu donné, ou peut être prise en compte pour tous les contenus accessibles via le service de téléchargement adaptatif HAS, ou encore pour tous les contenus téléchargés pendant une période donnée (par exemple au cours du mois courant).
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 gestion du téléchargement progressif adaptatif (HAS) 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 encore un dispositif de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique au sein d'un terminal lecteur de flux multimédia connecté à un réseau de communication mobile. Un tel contenu numérique est associé à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d'encodage du contenu ; un volume maximum de données à consommer au sein du réseau de communication mobile, appelé godet de données, est alloué au terminal lecteur de flux multimédia. Selon l'invention, un tel dispositif comprend :
- un module de détermination d'un volume de données qui serait consommé par le terminal lecteur de flux multimédia par téléchargement des segments temporels du contenu à au moins certains des débits d'encodage,
- un module de sélection d'un débit d'encodage maximum du contenu autorisé pour le téléchargement, en fonction du volume de données consommé qui lui est associé, et du godet de données.
Selon un mode de réalisation, un tel dispositif de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique comprend également un module de transmission d'une commande, vers un terminal de restitution associé au terminal lecteur de flux multimédia, d'affichage des volumes de données consommés déterminés pour au moins certains des débits d'encodage.
Une telle commande peut être une commande interne au dispositif lorsque ce dernier est intégré dans le terminal de restitution lui-même.
L'invention concerne encore un terminal lecteur de flux multimédia qui comprend un dispositif de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique tel que décrit précédemment.
Le dispositif de gestion du téléchargement progressif adaptatif, le terminal lecteur de flux multimédia de restitution et le programme d’ordinateur selon des modes de réalisation de l'invention présentent en combinaison tout ou partie des caractéristiques exposées dans l’ensemble de ce document. Notamment, ils présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion du téléchargement progressif adaptatif d'un contenu selon un mode de réalisation de la présente invention.
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 de façon schématique la structure matérielle d'un terminal lecteur de flux multimédia intégrant un dispositif de gestion de téléchargement progressif adaptatif selon un mode de réalisation de l'invention ;
[Fig 3] décrit un exemple de bridage de la qualité maximale d'un flux multimédia obtenu en mode téléchargement progressif adaptatif par un terminal lecteur de flux multimédia de [Fig 1] ou [Fig 2].
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur la possibilité, dans le cadre du téléchargement progressif adaptatif d'un contenu, de sélectionner le débit d'encodage maximum du contenu autorisé pour le téléchargement, afin de ne pas consommer une trop grosse part du godet de données de l'utilisateur, notamment lorsqu'il est en situation de mobilité.
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 mobile de communication étendu 1, par exemple un réseau de type 4G. 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) avec un certain débit. 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 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 mobile é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 » à 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 de durée déterminée ou déterminable.
Dans cet exemple, la clef HDMI 8 est 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] représente une architecture d'un terminal lecteur de flux multimédia selon un mode de réalisation de l'invention, par exemple la clef HDMI 8, ou le téléphone intelligent 3, de [Fig 1], On décrit plus spécifiquement dans la suite l'exemple de la clef HDMI 8.
Il 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 clef HDMI 8 communique avec le réseau Internet étendu 1 via le module WIFI pour une communication locale sans fils avec un autre terminal de communication, par exemple le téléphone intelligent 3. La clef HDMI 8 comprend en outre un module de téléchargement progressif adaptatif HAS apte à demander un téléchargement progressif de l'un des contenus à l'une des qualités proposées dans un fichier de description 7. Ce fichier de description 7 peut être enregistré par exemple dans les mémoires M de la clef HDMI 8 ou se trouver à l'extérieur.
La clef HDMI 8 comprend également un module DET de détermination d'un volume de données qui serait consommé par téléchargement progressif adaptatif d'un contenu, aux différentes qualités proposées dans le fichier de description 7.
Il comprend également un module DISP de commande de l'affichage des volumes de données déterminés par le module DET sur un écran d'un terminal de restitution, par exemple le téléphone intelligent 3 ou le téléviseur 5. Plus généralement, un tel module DISP est un module de gestion de l'interface avec le terminal de restitution de l'utilisateur, par lequel la clef HDMI 8 obtient par exemple des informations sur les éventuelles interactions de l'utilisateur avec le terminal de restitution (action sur la télécommande du téléviseur par exemple par appui sur la touche volume ou une touche de changement de canal, ou sélection dans un menu en surbrillance sur l'écran du téléviseur d'une qualité maximale de contenu autorisée, ou sélection de cette qualité maximale sur l'écran tactile du téléphone intelligent 3 ou de la tablette 4), et par lequel elle peut piloter l'affichage sur l'écran du terminal de restitution de fenêtres pop-up, lui permettant de délivrer des messages, des informations sur les volumes de données consommés ou restants, ou des alertes à l'utilisateur. Il comprend encore un module SEL de sélection d'un débit d'encodage maximal ou d'une résolution maximale autorisés pour le téléchargement du contenu, qui pilote le module de téléchargement progressif adaptatif HAS, afin de forcer ce dernier à demander un téléchargement progressif du contenu à une qualité, proposée dans le fichier de description 7, inférieure à la qualité optimale à laquelle il pourrait prétendre, dans le cas où cette qualité optimale est supérieure à la qualité maximale sélectionnée via le module SEL.
La clef HDMI 8 selon un mode de réalisation de l'invention peut aussi contenir d'autres modules comme un disque dur (non représenté) pour le stockage des fragments vidéo, un module de contrôle d'accès aux contenus, un module de traitement des commandes reçues d'une tablette ou d'un smartphone sur lesquels est installée l'application de pilotage de la clef HDMI, grâce à laquelle l'utilisateur peut en contrôler le fonctionnement, etc.ElEn effet, une telle clef HDMI 8 ne contient généralement pas de module d'interface E/S, et c'est le module d'interface E/S du téléphone intelligent 3 de l'utilisateur ou de sa tablette 4, ou du téléviseur 5, qui est utilisée par ce dernier pour choisir par exemple son contenu.
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 clef HDMI 8 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, représentatif du module de gestion du téléchargement progressif adaptatif HAS, 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 le fichier de description manifest 7. Le processeur de l'unité de traitement pilote la détermination des volumes de données consommés par téléchargement du contenu à ses différents niveaux de qualité, l'affichage de fenêtres pop-up sur l'écran du terminal de restitution, et le bridage de la qualité du contenu téléchargé, au travers du choix des segments temporels et des débits d'encodage associés à télécharger, et l'émission de commandes correspondantes vers le module client HAS.
Dans le cas où le terminal lecteur de flux multimédia considéré n'est pas la clef HDMI 8 mais, par exemple, le téléphone intelligent 3, l'architecture proposée sur [Fig 2] reste la même, à ceci près que le terminal communique directement avec le réseau de communication étendu via un module de communication mobile, par exemple de type 4G, en lieu et place du module WIFI. Le terminal de restitution est alors le terminal lecteur de flux multimédia lui-même, de sorte que le module DISP de commande de l'affichage pilote l'affichage des volumes de données estimés directement sur l'écran du téléphone intelligent 3, et le module SEL reçoit directement la valeur de la qualité maximale du contenu autorisée sélectionnée par l'utilisateur sur l'écran du téléphone intelligent 3 lui-même.
[Fig 2] illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser un terminal lecteur de flux multimédia, afin qu'il effectue les étapes du procédé détaillé ci-après, en relation avec [Fig 3] (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).
On présente désormais, en relation avec [Fig 3], un exemple de bridage de la qualité maximale d'un flux multimédia obtenu en mode téléchargement progressif adaptatif par un terminal lecteur de flux multimédia 30, par exemple la clef HDMI 8 ou le téléphone intelligent 3 de [Fig 1] et [Fig 2],
Le terminal lecteur de flux multimédia 30 est connecté à un terminal de restitution TX (par exemple la clef HDMI 8 est connectée au téléviseur 5 par l'intermédiaire d'une liaison HDMI ou au téléphone intelligent 3 par l'intermédiaire d'une liaison WIFI). Il comprend un module DISP 300 d'interface avec le terminal de restitution TX, un module DET 301 de détermination du volume de données consommé par téléchargement d'un contenu à ses différents débits d'encodage, un module SEL 302 de sélection d'un débit d'encodage maximum autorisé pour le téléchargement, et un module client HAS 303.
Un serveur de contenu HAS 2 expose une vidéo Cl sous forme de « chunks » Cli@Nj encodés à différents 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 30. 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 TX.
Dans le mode de réalisation illustré sur [Fig 3], en revanche, le module client HAS 303 peut ne pas commander le téléchargement du fragment au débit d'encodage optimal, afin de limiter la consommation du godet de données de l'utilisateur, comme décrit plus en détail par la suite. Au cours d'une étape référencée 310, le module HAS 303 récupère le fichier manifest 7 afin de découvrir les fragments disponibles du contenu vidéo Cl, et les différentes qualités vidéo Nj associées.
On considère par exemple le cas d'un client qui souhaite regarder une vidéo à la demande (VOD) d'une durée de deux heures, en utilisant sa CléTV® 8 et son smartphone 3 en mode modem (partage de connexion 4G).
On suppose que sur la Clef HDMI 8 qu'il veut utiliser, la technologie de transport du flux multimédia est de type HAS avec cinq niveaux de débit d'encodage et de résolution disponibles, selon l'exemple donné dans le tableau [Table 1] ci-dessous.
[Table 1] e proposé sous forme de fragments de durée 3s, avec un premier débit d'encodage NI = 600 kb/s, un deuxième débit d'encodage
N2 = 1200 kb/s, un troisième débit d'encodage N3 = 2100 kb/s, etc.
Dans un mode de fonctionnement normal, non illustré sur [Fig 3], le module HAS 303 opère le téléchargement par exemple, des fragments successifs Cli@Nl (soit le premier fragment temporel à un débit d'encodage de 600 kb/s), puis Cl2@N3 (soit le deuxième fragment temporel à un débit d'encodage de 2100 kb/s), puis Cl3@N3 (soit le troisième fragment temporel à un débit d'encodage de 2100 kb/s), ...
Les différents fragments téléchargés par le module client HAS 303 sont transmis au module d'interface DISP 300 pour leur restitution à l'utilisateur sur l'écran du terminal de restitution TX. L'algorithme mis en oeuvre par le module client HAS 303 pour déterminer quel fragment à quel débit d'encodage doit être téléchargé en mode de fonctionnement normal (c'est-à-dire en dehors du bridage du débit d'encodage par le module SEL 302) peut être l'un des algorithmes déjà existants de l'art antérieur. Cet algorithme ne sera donc pas décrit ici plus en détail.
En parallèle, conformément à [Fig 3], le module DET 301 détermine le volume de données qui serait consommé par téléchargement du contenu Cl aux différents niveaux de résolution de [Table 1] Pour ce faire, le module DET 301 utilise par exemple une hypothèse simplificatrice, selon laquelle le téléchargement s'opère au même niveau de résolution pendant toute la durée du contenu, soit, dans cet exemple pendant deux heures, ou 7200 secondes. Bien qu'elle ne corresponde pas à la réalité de fonctionnement du téléchargement de type HAS, cette hypothèse permet une bonne estimation de la quantité de données qui pourrait être consommée par téléchargement du contenu à chacun des niveaux de résolution proposé dans le fichier manifest 7.
Ainsi, par exemple, pour une résolution de 320x180 pixels , le module DET 301 estime une consommation de données de : 600kb/s * 7200s=4,32Gb, soit 540Mo. Le résultat de l'ensemble des calculs effectués est résumé dans le tableau ci-dessous.
[Table 2]
On considère tout d'abord un premier cas, dans lequel le terminal 30 connaît le godet de données du client utilisateur. Ce godet de données correspond par exemple à un volume de données associé à une carte prépayée dont il a fait l'acquisition auprès de l'opérateur du réseau mobile 1. Il peut aussi correspondre à un forfait mensuel qu'il a souscrit auprès de cet opérateur, par exemple un forfait de 50Go/mois.
Dans le cas où le service de téléchargement HAS est maîtrisé de bout en bout par l'opérateur du réseau mobile 1, le godet de données de l'utilisateur est connu de l'opérateur, à partir de l'offre qu'a souscrit l'utilisateur, ou de ses informations de facturation. C'est donc l'opérateur qui transmet cette information au terminal 30.
En variante, ce godet de données peut également être renseigné par l'utilisateur lui-même. Il peut par exemple être saisi via l'interface du terminal de restitution TX (téléphone intelligent 3, ou téléviseur 5 par exemple), lors d'une phase d'installation du service de téléchargement HAS, ou en réponse à une requête du fournisseur de ce service, par exemple via une fenêtre « pop in » informant l'utilisateur de nouvelles fonctionnalités ou de nouveautés du service.
On considère donc l'exemple d'un godet de données de 50Go/mois, dont le client aurait déjà consommé lOGo au cours du mois courant. A nouveau, la connaissance de la consommation courante du client peut être fournie par l'opérateur du réseau mobile 1, ou par le client lui-même. Le module DET 301 peut alors aisément déterminer, pour chacune des résolutions proposées dans le ficher manifest 7, la part du godet de données qui sera consommée en cas de téléchargement du contenu à cette résolution, et la part de ce godet qui restera au client après téléchargement, en fonction de sa consommation mensuelle courante. Le résultat des calculs effectués par le module DET 301 peut s'afficher, par exemple sous forme du tableau [Table 3] ci-dessous, sur l'écran du terminal de restitution TX.
[Table 3]
Ainsi, par simple consultation de l'écran du terminal de restitution TX, le client sait qu'en téléchargeant le contenu Cl à un débit d'encodage de 2,lMb/s, il consommera 7200*2, 1=15, 12Gb, soit 15, 12/8=1, 89Go. Dans la mesure où son godet de données est de 50Go, cela représente donc l,89Go*50Go/100=3,78% de son godet de données mensuel. Et comme il a déjà consommé lOGo de données depuis le début du mois, soit 20% de son godet de données, il lui restera, après téléchargement du contenu Cl à cette résolution de 1024x576 pixels, 100%-20%-3,78%=76,22% de son godet de données mensuel.
Le terminal 30 propose alors au client, fort de cette connaissance de son niveau de godet de données consommé et restant après téléchargement, de définir une limite haut du débit d'encodage du contenu à télécharger : les différents fragments du contenu Cl ne pourront alors pas être téléchargés à un débit d'encodage supérieur à cette limite haute sélectionnée par l'utilisateur.
Dans cet exemple, l'utilisateur décide par exemple qu'il souhaite visionner le contenu Cl, mais sans dépasser 7% de consommation de son godet de données : il choisit donc de brider le téléchargement des fragments du contenu à une résolution maximale de 1280x720 pixels.
Pour ce faire, il utilise l'interface du terminal de restitution TX. Par exemple, sur l'écran du téléviseur 5, il sélectionne, au moyen d'une télécommande, l'une des lignes du tableau [Table 3], qui s'affiche par exemple en surbrillance. Dans un autre exemple, il sélectionne ce débit d'encodage maximum autorisé en cliquant sur la ligne idoine du tableau [Table3] affichée sur l'écran tactile du téléphone intelligent 3. Tout autre type de configuration d'interface pourrait également être utilisé, telle qu'un bandeau (en anglais « banner »), une fenêtre « pop in », etc.
On notera que le terminal lecteur de flux multimédia 30 peut opérer lui-même cette sélection, sans intervention de l'utilisateur, par exemple en appliquant un principe de précaution quant à la consommation du godet de données. Il peut aussi inciter l'utilisateur à sélectionner une valeur basse de débit d'encodage maximum autorisé, par exemple en affichant en surbrillance sur l'écran du terminal de restitution une valeur maximale de débit d'encodage préconisée, en fonction de la part du godet de données restante après téléchargement. L'utilisateur n'a alors plus qu'à confirmer ou infirmer cette pré-sélection. La valeur sélectionnée alimente le module de sélection SEL 302, qui la communique au module HAS 303, de façon à brider le téléchargement des fragments de contenu au débit d'encodage maximum de 3Mb/s choisi par l'utilisateur.
Ainsi, comme illustré sur [Fig 3], le module client HAS 303 va télécharger successivement (312) les fragments Cl2@N3, Cl3@N3, C14@N2, C15@N1 et Cl6@N3, c'est-à-dire, télécharger le fragment de meilleure qualité possible en fonction des contraintes réseau, mais sans jamais dépasser la valeur maximale MAX 311 du débit d'encodage, qui a été sélectionnée par l'utilisateur comme étant égale à 2100kb/s.
Ainsi, si après avoir téléchargé les fragments Cl2@N3, Cl3@N3, C14@N2 et C15@N1, le module client HAS 303 détermine, en fonction des conditions réseau, que le débit optimal de fragment temporel auquel il peut prétendre est de 5000kb/s, il ne lance pas le téléchargement du prochain fragment à ce débit optimal, mais télécharge le fragment temporel Cl6@N3, au débit d'encodage maximum autorisé par le client.
On considère désormais un second cas, dans lequel le terminal lecteur de flux multimédia 30 n'a pas connaissance du godet de données de l'utilisateur. Dans ce cas, le module de détermination DET 301 du volume de données consommées ne peut déterminer que la valeur absolue du volume de données consommé par téléchargement du contenu Cl aux différents niveaux de résolution proposés dans le fichier manifest 7, et non sa valeur relative par rapport au godet de données. En d'autres termes, seules les données du tableau [Table 2] peuvent être affichées, sur action du module de commande d'affichage DISP 300, sur l'écran du terminal de restitution TX. Ainsi, on présente simplement le niveau de consommation du flux multimédia Cl à ses différents débits d'encodage, et l'utilisateur doit opérer une sélection du débit d'encodage maximum qu'il autorise en fonction seulement du nombre de Go consommés à chacun des débits.
L'utilisateur ayant le plus souvent connaissance de son godet de données, il peut effectuer un calcul rapide de tête pour l'aider à prendre une décision. Ainsi, s'il a envie de visionner la VOD Cl, il peut être prêt à consommer 2,7Go de son godet de données mensuel, quitte à restreindre sa consommation pendant le reste du mois sur d'autres services ou applications. Dans ce cas, il sélectionne, dans le tableau [Table2], la résolution de 1280x720 pixels, et le débit d'encodage maximum associé de 3Mb/s. A nouveau, la configuration de l'interface du terminal de restitution TX rendant possible cette sélection peut prendre toute forme appropriée.
Dans ce second cas, on affiche donc sur l'écran du terminal de restitution des données permettant à l'utilisateur de mieux appréhender l'impact du téléchargement du contenu Cl sur sa consommation de données, afin qu'il dispose des outils nécessaires pour adapter sa consommation de contenu, en fonction de ses capacités. On notera que, dans un mode de réalisation, la sélection du débit d'encodage maximum MAX 311 est effective pour le seul contenu Cl en cours de téléchargement HAS. En variante, cette sélection peut s'appliquer à tous les flux multimédias accessibles via le serveur de contenus 2, ou à tous les flux multimédias que l'utilisateur va télécharger au cours d'une période donnée (par exemple le mois courant en cas de forfait mensuel), ou pendant une période donnée au cours de laquelle l'utilisateur est en situation de mobilité.
Dans un autre mode de réalisation, le module DISP 300 n'affiche pas toutes les lignes des tableaux [Table 2] et [Table 3] sur l'écran du terminal de restitution TX, mais seulement les lignes correspondant aux débits d'encodage qui n'entraînent pas de dépassement du godet de données de l'utilisateur. En d'autres termes, on propose uniquement au client les débits d'encodage auxquels il peut prétendre pour pouvoir au minimum visionner le contenu Cl en intégralité, s'il ne lui reste plus assez de données consommables pour le voir à la qualité maximale disponible.
On a donné ci-avant l'exemple d'un contenu Cl de type vidéo à la demande (VOD). On notera que le contenu Cl peut également être un programme télévisuel en différé (ou « replay »), ou un programme télévisuel en direct (« Live »). Dans ce dernier cas, la durée du programme nécessaire au calcul par le module DET 301 du volume de données consommé peut être extraite du guide électronique des programmes EPG (« Electronic Program Guide »).
Dans ses différents modes de réalisation, la présente invention peut être mise en oeuvre sur les boîtiers décodeurs (en anglais « set top box »), sur la CléTV® d'Orange® et généralement sur tous les terminaux consommant des vidéos en HAS en mobilité (sur réseau mobile).
ANNEXE 1 : exemple de fichier manifest

Claims

REVENDICATIONS
1. Procédé de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique (Cl) au sein d'un terminal (3, 4, 8) lecteur de flux multimédia connecté à un réseau de communication mobile (1), 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 débits d'encodage dudit contenu, un volume maximum de données à consommer au sein dudit réseau de communication mobile, appelé godet de données, étant alloué audit terminal lecteur de flux multimédia, caractérisé en ce que, au lancement dudit téléchargement progressif adaptatif dudit contenu numérique, ledit procédé de gestion met en oeuvre :
- une détermination (DET 301) d'un volume de données qui serait consommé par ledit terminal lecteur de flux multimédia par téléchargement desdits segments temporels dudit contenu à au moins certains desdits débits d'encodage,
- une sélection (SEL 302) d'un débit d'encodage maximum (MAX 311) dudit contenu autorisé pour ledit téléchargement, en fonction dudit volume de données consommé qui lui est associé, et dudit godet de données.
2. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comprend également un affichage (DISP 300), sur un terminal de restitution (TX) associé audit terminal lecteur de flux multimédia, desdits volumes de données consommés déterminés pour au moins certains desdits débits d'encodage.
3. Procédé de gestion selon la revendication 2, caractérisé en ce que lesdits volumes de données consommés, déterminés pour au moins certains desdits débits d'encodage, sont affichés sous forme d'une proportion dudit godet de données.
4. Procédé de gestion selon l’une quelconque des revendications 2 et 3, caractérisé en ce qu'il comprend également un affichage, sur ledit terminal de restitution, d'un volume de données restant à consommer par ledit terminal lecteur de flux multimédia, à l'issue dudit téléchargement desdits segments temporels dudit contenu à au moins certains desdits débits d'encodage.
5. Procédé de gestion selon l’une quelconque des revendications 2 à 4, caractérisé en ce que lesdits volumes de données affichés correspondent aux seuls débits d'encodage pour lesquels ledit téléchargement desdits segments temporels dudit contenu n'induit pas de dépassement dudit godet de données.
6. Procédé de gestion selon l’une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend également une saisie, sur un terminal de restitution associé audit terminal lecteur de flux multimédia, dudit godet de données.
7. Procédé de gestion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite sélection dudit débit d'encodage maximum dudit contenu autorisé pour ledit téléchargement est effectuée par un utilisateur via une interface d'un terminal de restitution associé audit terminal lecteur de flux multimédia.
8. 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 à 7, lorsqu'il est exécuté par un processeur.
9. Dispositif de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique au sein d'un terminal lecteur de flux multimédia connecté à un réseau de communication mobile, ledit contenu numérique étant associé à un fichier de description (7) dudit contenu numérique, comprenant une liste de segments temporels dudit contenu associés chacun à plusieurs débits d'encodage dudit contenu, un volume maximum de données à consommer au sein dudit réseau de communication mobile, appelé godet de données, étant alloué audit terminal lecteur de flux multimédia, caractérisé en ce qu'il comprend:
- un module de détermination (DET) d'un volume de données qui serait consommé par ledit terminal lecteur de flux multimédia par téléchargement desdits segments temporels dudit contenu à au moins certains desdits débits d'encodage,
- un module de sélection (SEL) d'un débit d'encodage maximum dudit contenu autorisé pour ledit téléchargement, en fonction dudit volume de données consommé qui lui est associé, et dudit godet de données.
10. Dispositif de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique selon la revendication 9, caractérisé en ce qu'il comprend également un module (DISP) de transmission d'une commande, vers un terminal de restitution (3, 4, 5) associé audit terminal lecteur de flux multimédia (3, 4, 8), d'affichage desdits volumes de données consommés déterminés pour au moins certains desdits débits d'encodage.
11. Terminal lecteur de flux multimédia (3, 4, 8), caractérisé en ce qu'il comprend un dispositif de gestion du téléchargement progressif adaptatif (HAS) d'un contenu numérique selon la revendication 9 ou 10.
EP20792466.3A 2019-09-27 2020-09-23 Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données Pending EP4035408A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1910685A FR3101503A1 (fr) 2019-09-27 2019-09-27 Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec sélection d’un débit d’encodage maximum autorisé en fonction d’un godet de données
PCT/FR2020/051656 WO2021058910A1 (fr) 2019-09-27 2020-09-23 Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données

Publications (1)

Publication Number Publication Date
EP4035408A1 true EP4035408A1 (fr) 2022-08-03

Family

ID=69104702

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20792466.3A Pending EP4035408A1 (fr) 2019-09-27 2020-09-23 Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données

Country Status (4)

Country Link
US (1) US12034792B2 (fr)
EP (1) EP4035408A1 (fr)
FR (1) FR3101503A1 (fr)
WO (1) WO2021058910A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3134940A1 (fr) * 2022-04-25 2023-10-27 Orange Gestion de la restitution d’un contenu multimédia

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100354531B1 (ko) * 1998-05-06 2005-12-21 삼성전자 주식회사 실시간 복호화를 위한 무손실 부호화 및 복호화 시스템
DE60036789D1 (de) * 1999-02-04 2007-11-29 Quvis Inc Bildspeicherung und kommunikation mit priorität auf der qualität
US8788614B2 (en) * 2007-05-07 2014-07-22 At&T Intellectual Property I, L.P. Methods, devices, systems, and computer program products for managing and delivering media content
US9109928B2 (en) * 2007-08-16 2015-08-18 International Business Machines Corporation Methods and apparatus for efficient and adaptive transmission of data in data collection networks
US9113141B2 (en) * 2010-12-09 2015-08-18 Intel Corporation Wireless channel aware adaptive video bit rate encoding
US9344517B2 (en) * 2013-03-28 2016-05-17 Sonic Ip, Inc. Downloading and adaptive streaming of multimedia content to a device with cache assist
US9860294B2 (en) * 2014-12-24 2018-01-02 Intel Corporation Media content streaming
KR102343331B1 (ko) * 2015-07-07 2021-12-24 삼성전자주식회사 통신 시스템에서 비디오 서비스를 제공하는 방법 및 장치
US10200272B1 (en) * 2015-09-30 2019-02-05 Alarm.Com Incorporated Dynamic availability-based wireless data transmission
US10419581B2 (en) * 2016-12-21 2019-09-17 Cisco Technology, Inc. Data cap aware video streaming client

Also Published As

Publication number Publication date
US12034792B2 (en) 2024-07-09
WO2021058910A1 (fr) 2021-04-01
US20220345511A1 (en) 2022-10-27
FR3101503A1 (fr) 2021-04-02

Similar Documents

Publication Publication Date Title
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
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
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
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.
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
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
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
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
WO2023208688A1 (fr) Gestion de la restitution d&#39;un contenu multimédia
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
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.
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
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.
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.
WO2025114181A1 (fr) Procédé de gestion de la relecture d&#39;un contenu ayant été diffusé en temps réel
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
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
EP4543015A1 (fr) Procédé de gestion de l accès à des fichiers de description associés à un contenu diffusé en temps réel
EP4554231A1 (fr) Procédé de gestion de l&#39; accès à des fichiers de description associés à un contenu diffusé en temps réel
EP4734527A1 (fr) Procédé de gestion de l accès, par un dispositif de lecture, à des contenus segmentés
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
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
EP4297409A1 (fr) Procédé de gestion de la lecture d&#39;un contenu multimédia.
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

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220317

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20241105