EP3834421A2 - Méthode et dispositif de diffusion de vidéo à 360 degrés - Google Patents

Méthode et dispositif de diffusion de vidéo à 360 degrés

Info

Publication number
EP3834421A2
EP3834421A2 EP19835685.9A EP19835685A EP3834421A2 EP 3834421 A2 EP3834421 A2 EP 3834421A2 EP 19835685 A EP19835685 A EP 19835685A EP 3834421 A2 EP3834421 A2 EP 3834421A2
Authority
EP
European Patent Office
Prior art keywords
display
tiles
video
head
display window
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
EP19835685.9A
Other languages
German (de)
English (en)
Inventor
Mariem BEN YAHIA
Yannick Le Louedec
Gwendal Simon
Loutfi NUAYMI
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 EP3834421A2 publication Critical patent/EP3834421A2/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/154—Measured or subjectively estimated visual quality after decoding, e.g. measurement of distortion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/011—Arrangements for interaction with the human body, e.g. for user immersion in virtual reality
    • G06F3/012—Head tracking input arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/36—Scalability techniques involving formatting the layers as a function of picture distortion after decoding, e.g. signal-to-noise [SNR] scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/37—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability with arrangements for assigning different transmission priorities to video input data or to video coded data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H04N23/698—Control of cameras or camera modules for achieving an enlarged field of view, e.g. panoramic image capture

Definitions

  • the invention is in the field of virtual reality, and more particularly that of streaming systems ("streaming" in English) of 360 degrees video.
  • the user watches only part of the entire spherical video at any given time, called the video sphere.
  • This part called the display window, depends on the orientation of the user's head and the size of the screen in his terminal, called a head-mounted display, or HMD (Head Mounted Device). , in English).
  • HMD Head Mounted Device
  • the user's terminal must adapt the audiovisual content in the display window at any time. head movements of the user.
  • a first 360-degree video broadcasting technique consists in transmitting the entire content of the video sphere to the user's terminal.
  • the user's terminal then locally takes care of extracting from the video sphere the part to be inserted in the display window of the user's helmet.
  • This technique has the disadvantage of transporting a much greater amount of data than that which is actually used by the user's terminal. Indeed, the display window represents only about 15% of the entire video sphere.
  • This problem of consumption of network resources is major in the case of 360-degree video since the streaming throughput of a complete video sphere can be between several tens and several hundred megabits per second.
  • a second dissemination technique aims to overcome the disadvantage of the first, namely to reduce the amount of data transported. This second technique includes several operations.
  • the first operations take place in the preparation of the video, before it is transported through the telecommunications network.
  • the video sphere is first projected on a two-dimensional (2D) plane. Then it is spatially cut into several parts called tiles, for example forming a grid of the plane. Then each tile is encoded independently of the other tiles making up the video. Each tile can thus be decoded independently of the other tiles on the user's terminal. More precisely, each tile is encoded in several versions corresponding to different quality levels or to different resolutions, for example, at least one high quality version and at least one low quality version.
  • the video is cut temporally into segments (or "chunks" in English), by time interval.
  • the duration of the time intervals (and therefore the duration of the segments) is fixed for the entire video, and the order of magnitude of this duration is typically one or more seconds.
  • Each segment is itself composed of successive images, the number of which depends on the number of frames per second (or "frame rate" in English) of the video, for example 60.
  • tile therefore designates a spatial and temporal subdivision of the video sphere.
  • a tile represents a few moments (1 second for example) of the video on a partial surface of the sphere.
  • the following operations are performed at the user's terminal. These operations must be carried out for each of the segments of the video sphere, during the time interval preceding the display of the segment.
  • a first operation consists in predicting the orientation given by the head of the user to the head-mounted display, during the next time interval, that is to say predicting the correct display window for the segment.
  • the second operation consists in requesting and receiving video content for this segment and this display window.
  • the display window in the head-mounted display is generally larger than the size of a tile; the display of the display window therefore requires the assembly, at the user terminal, of a set of adjacent tiles.
  • the terminal must therefore request and receive in high quality the tiles which cover the predicted display window for the next time interval.
  • the terminal must also request and receive in low quality the other tiles (those which are outside the predicted display window but which are likely to be there if the prediction is not correct). These tiles in low quality make it possible to maintain the display, if necessary in low quality, of the video when the user performs very marked and unforeseen head movements (ie outside the predicted display window).
  • displaying a low quality in all or part of the display window certainly causes a degradation in the quality of experience for the user, but it is preferable to displaying a still image or a screen. black.
  • these tiles in low quality also allow this second technique to transport through the network a quantity of data less than the first technique described above.
  • the disadvantage of this second technique is a degradation of the quality of experience felt by the user when the prediction is not perfect, as is often the case, for example when he performs a very marked head movement and outside the predicted display window.
  • One of the aims of the invention is to remedy these drawbacks of the state of the art.
  • the invention improves the situation using a method of obtaining video segments from a video sphere for display in a head-mounted display connected to a video server, the video segments being spatially divided into a plurality of tiles encodable in at least two distinct levels of quality, including a high quality level and a low quality level, a part of the video sphere intended to be displayed at a display instant being called display window, the method comprising before the instant of display of at least two iterations of the sequence of steps following:
  • the method further comprising the following steps:
  • the proposed method makes this compromise unnecessary. Compared to the prior art where a single estimate is made as soon as possible for the next display instant, the proposed method improves the estimate using at least a second estimate, while guaranteeing the reception of all the necessary tiles. Indeed, if after the second estimate there is not enough time left to request all the necessary tiles again, the first burst of requests guarantees the reception of the missing tiles, even if they are not necessarily all level of quality corresponding to the second estimate.
  • the method allows a number of iterations of the estimation phase greater than two, within the limit constituted by the time remaining before the next display instant, and by other parameters such as the bandwidth of the connection between the head-mounted display and the link video server, the computing power of the head-mounted display, etc.
  • the duration between two display instants is that of a segment. It is understood that the expression "display instant" designates at the instant of the start of viewing of a segment.
  • the request further comprises an indication of a priority level associated with the tile.
  • this aspect it is possible, for example, to prioritize requests for high quality tiles over requests for high quality tiles. low quality, or prioritize requests for which a response has not yet been received over requests for which at least one response has already been received.
  • the probability is increased that all the necessary tiles will have been received at the time of display. In other words, if some tiles are still missing at the time of display, these will not be the most important for the user, and bandwidth between head-mounted display and video server will have been saved.
  • the request is a request for delivery of the encoded tile corresponding to the identified tile.
  • the request is a request cancellation of delivery of the encoded tile corresponding to the identified tile, followed by a new request for delivery of the encoded tile, comprising the new quality level or the new priority level associated with the identified tile.
  • the iteration is not the first and if the quality level associated with the identified tile has decreased compared to the previous iteration, no new request is issued if the tile has already been received.
  • connection between the head-mounted display and the video server includes a separate stream per identified tile.
  • the connection between the head-mounted display and the video server uses the HTTP / 2 protocol.
  • HTTP / 2 "Hypertext Transfer Protocol", version 2 of the hypertext transfer protocol, in English, described in the normative document rfc7540), is a protocol allowing to manage several flows in the same connection, and in particular allowing cancellation of flows (tiles) during delivery in order for example to correct a characteristic or prioritization of the flow (of the tile), without interrupting the connection. It is therefore particularly suitable for implementing the proposed method.
  • the invention also relates to a device for obtaining video segments from a video sphere for display in a head-mounted display connected to a video server, the video segments being spatially divided into a plurality of tiles encodable in at least two distinct quality levels, a high quality level and a low quality level, a part of the video sphere intended to be displayed at a display instant being called display window, the device comprising a receiver, a transmitter, a decoder, a processor and a memory coupled to the processor with instructions intended to be executed by the processor for:
  • This device capable of implementing in all of its embodiments the obtaining method which has just been described, is intended to be implemented in a user terminal such as for example a head-mounted display.
  • the invention also relates to a head-mounted display comprising a device according to that just described, a position and movement sensor, and a screen.
  • head-mounted display it is necessary to understand any user terminal allowing a user to at least partially view a video sphere.
  • the invention also relates to a computer program comprising instructions for implementing the steps of the method for obtaining data from a video sphere for display in a head-mounted display connected to a video server, which has just been described, when this program is executed by a processor.
  • the invention also relates to an information medium readable by a device included in a head-mounted display, and comprising instructions of a computer program as mentioned above.
  • the program mentioned above can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in n any other desirable form.
  • a support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or also a magnetic recording means.
  • a storage means such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or also a magnetic recording means.
  • Such storage means can for example be a hard disk, a flash memory, etc.
  • an information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means.
  • a program according to the invention can in particular be downloaded from a network of the Internet type.
  • an information medium can be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.
  • FIG. 1 shows an example of cutting a video sphere into tiles, according to a particular embodiment of the invention
  • FIG. 2 schematically presents an example of sequencing the steps of the process for obtaining video segments, according to a particular embodiment of the invention
  • FIG. 3 shows an example of the structure of an obtaining device video segments, according to a particular aspect of the invention.
  • the embodiment presented below uses a subdivision of a video sphere into 24 tiles, a duration of the video segments of 1 second, two iterations of prediction of the display window of 500 ms each for each interval between segments, and the HTTP / 2 protocol for the connection between the head-mounted display and the video server, but these choices represent only an indicative and non-limiting example of embodiment of the invention.
  • video sphere is not limited to a sphere but designates any video of which only a part can be displayed at any time, the displayed part depending on the real or virtual position of the display terminal, or on its orientation, that is to say the direction pointed by this one, compared to the complete video.
  • the examples developed below include a head-mounted display, but the invention works with any terminal allowing a user to view a "video sphere”.
  • Figure 1 shows an example of cutting a video sphere into tiles, according to a particular embodiment of the invention.
  • the video sphere is spatially divided into 24 rectangles.
  • Each of the rectangles, at a given display instant corresponds to a spatial subdivision of a video segment, also called a tile.
  • the rectangles are called tiles in the following.
  • the tiles are numbered T1 to T24. For the sake of clarity, only the tiles T1, T2, T23 and T24 are indicated, the locations of the other tiles can easily be deduced.
  • the tiles can be encoded (compressed) independently of each other, at different quality levels, for example using a HEVC ("High Efficiency Video Coding") encoder on the video server side and a corresponding decoder on the client side, i.e. on the head-end side.
  • HEVC High Efficiency Video Coding
  • the display window At any time, only part of the video sphere, called the display window, can be viewed by the user of the head-mounted display, which makes it unnecessary to transmit the complete set of tiles forming the sphere.
  • the exact determination of the display window is a problem of prediction, of which several solutions are known. These solutions require the division of the video sphere into different regions, according to their probability of being in the display window during the next display period of a video segment in the head-mounted display.
  • FIG. 1 uses regions numbered 1 to 4, and represents a prediction of the display window before any display instant:
  • Region 1 represents an estimate of the display window; parts of this area have a very high probability of being included in the display window
  • Region 2 represents the extension zone of the display window, corresponding to slight natural head movements of the user; parts of this area have a high probability of being included in the display window,
  • Region 3 represents the area of the immediate background, corresponding to larger movements when the user turns his head; parts of this area have a medium probability of being included in the window display,
  • Region 4 represents the area of the distant background, corresponding approximately to half of the sphere opposite the display window; parts of this area have a low probability of being included in the display window.
  • Region 1 touches 6 tiles: T8 to T10, and T14 to T16.
  • Region 2 although slightly larger on the surface, touches the same 6 tiles, no tiles are to be added compared to region 1.
  • 10 tiles are to be added: tiles T2 to T5, T1 1, T17, and T20 to T23.
  • tiles T1, T6, T7, T12, T13, T18, T19 and T24 are to be added.
  • region 2 is configured to be larger than region 1 by 10% in a horizontal axis, and by 5% in a vertical axis.
  • Region 4 has no external limits.
  • region 2 is the smallest region used, it also includes the tiles from region 1.
  • FIG. 2 schematically shows an example of sequencing the steps of the process for obtaining video segments, according to a particular embodiment of the invention.
  • the client requests the tiles from region 1 with a high quality level (greater amount of data per tile), and the tiles from region 3 with a low quality level (less amount of data per tile).
  • the customer can additionally request the tiles from region 1 with a higher priority than those from region 3. If the bandwidth is insufficient for all the tiles, those from region 1 will be thus received in priority.
  • Viewing a 360-degree video is done segment by segment, the time interval between two segment displays being fixed, for example 1 second.
  • the method is described below in detail for displaying the tiles the display window at a display instant, and, in parallel with the display, for obtaining the tiles for the next display instant. which is 1 second later. Viewing and obtaining must therefore be repeated as many times as there are time intervals (i.e. seconds) in the full video.
  • the client Beforehand, the client must obtain from a server information describing the structure of the content to be recovered, during a step G1.
  • This can be for example an MPD file ("Media Presentation Description", or description of the presentation of the medium, in English).
  • This file tells the client how the video sphere is spatially subdivided (number of tiles, position in the video sphere), what levels of encoding quality are available for a tile, etc.
  • the client processes the information extracted from the file and prepares the display of the very first display window, called the current window. For example, the client issues requests in separate HTTP / 2 streams for each of the tiles it needs for this display window.
  • the next step G3 comprises the steps E1 to E5, and is repeated for each display instant, every second, if the time interval between 2 display windows is 1 second, as in our example.
  • the client displays the current window, that is to say that the tiles touching the current display window are "played" for the user of the head-mounted display (or "viewed").
  • Step E2 the client estimates the next display window, and issues requests for the tiles making up this next display window.
  • Step E2 includes steps F1 to F3 repeated several times. For example, a first iteration of steps F1 to F3 is executed at the start of the current time interval, then a second iteration is executed 500 ms later, halfway through the duration of the interval. For the sake of simplicity, the number of iterations is here limited to 2 but a larger number is possible.
  • the duration of each iteration is limited in our example to 500 ms, but any other division of the time interval is possible, respecting the minimum duration necessary for an iteration, which depends on factors such as the client's computing power, the volume of video data it must receive, the effective bandwidth between the client and the video server, etc.
  • the client estimates the position of the display window which is most likely to be noted at the end of the current interval. Any prediction technique can be used, based for example on the instant position of the head-mounted display, and / or on the trajectory of the head-mounted display, and / or based on information relating to elements of content of particular interest found in certain places of the video sphere in the segments played or still to be played, and / or based on other types of information.
  • estimating the position of the display window it is also the limits of each of the regions taken into account (regions 2 and 3) which are estimated.
  • the client identifies the tiles from each of the regions taken into account, and associates with each of the tiles an adequate level of quality. For example, the high quality level is associated with the tiles touching region 2, and the low quality level is associated with the tiles touching region 3. As it is the first iteration, no tile for the next display moment has yet been requested by the client.
  • the client then sends as many tiles delivery requests as identified tiles to the video server.
  • the client can include a weight for each of its requests, proportional to the priority that the client wishes to be given by the server to the delivery of the tile requested in the request. For a tile touching region 2, a high weight is included in the request. On the contrary, for a tile touching region 3, a low weight is included in the request.
  • step F1 is repeated identically, 500 ms later than the first time, in our exemplary embodiment with 2 iterations and 1 second per time interval.
  • the new estimation of the display window is likely to be better because it is made less before the end of the interval, i.e. less time before the head-mounted display reaches the position which will be the at the next display time.
  • step F2 is repeated identically, with a potentially different result.
  • the client identifies the tiles for each of the regions, which are determined this time based on the new estimate.
  • step F3 of the second iteration requests to the video server are also sent, but in a different way compared to the first iteration. Indeed, all the necessary tiles have already been required once. However, the new estimation of the display window can make certain quality levels associated with the tiles already required unsuitable.
  • the request for delivery of this tile is canceled by issuing a request to cancel delivery of this tile, then a new request for delivery of this tile is issued with a level of low quality. If the response to the request from the previous iteration, for the tile with a high quality level, has already been received, the customer nevertheless keeps this tile rather than asking for the delivery of the same tile with a lower quality, in order to preserve the bandwidth between the head-mounted display and the video server.
  • the request for delivery of this tile is canceled by issuing a request to cancel delivery of this tile, then a new request for delivery of this tile is issued with a high quality level.
  • the client can however decide to be content with it, in order to preserve the bandwidth between the head-mounted display and the video server.
  • a tile that has not changed region compared to the previous iteration does not give rise to the issuance of a new request, unless the customer finds a delay in the delivery of certain important tiles, i.e. - say, typically, tiles from region 2.
  • the client can decide to review the weight associated with a tile, in order to speed up or slow delivery by the server, compared to others.
  • a request for cancellation of delivery of the tile is issued, followed by a request for delivery of this tile with the revised weight.
  • the steps F1 to F3 of the following iterations are identical to those of the second iteration described above.
  • HTTP / 2 allows the management of a flow per tile in the same connection between the head-mounted display and the video server. Also, HTTP / 2 allows the cancellation of a current request, as well as the indication in a request of the required quality level, and of the desired priority level (using weights).
  • step E3 the client receives tiles from the video server, in responses to requests made during steps F3 of step E2. It should be noted that some of these responses can be received while step E2 has not yet been completed.
  • This step E3 is in fact composed of multiple sub-steps for receiving a tile.
  • the client determines the display window observed at the end of the current time interval. This window is determined by the actual instantaneous position of the head-mounted display, that is to say the position of the user's head, at the end of the time interval.
  • the client decodes the tiles received covering the observed display window, then combines these tiles to build a single video segment. Some tiles at the edge of the display window may be only partially included. Alternatively, the client can decode all the tiles received in order to build as much of the 360-degree video as possible, then extract the part necessary for the observed display window. To be able to build the complete 360 degree video, the tiles of the video sphere must be received. For this, it suffices to replace region 3 of this example of implementation of the method with region 4 of FIG. 1, or to add region 4 as a third region, with for example an even lower level of quality. for region 4 than for region 3.
  • step E1 the observed display window becomes the current display window and the method returns to step E1, in order to process the next time interval. All of the steps E1 to E5 (that is to say the step G3 in FIG. 2), is repeated until the last time interval of the 360-degree video.
  • FIG. 3 an example of the structure of a device for obtaining video segments is now presented, according to a particular aspect of the invention.
  • the attachment device 100 implements the process for obtaining video segments, various embodiments of which have just been described.
  • Such a device 100 can be implemented in a HMD1 head-mounted display comprising a screen Scr and a position and movement sensor Pos.
  • the device 100 comprises a transmitter 101, a receiver 102, a processing unit 130, equipped for example with a microprocessor mR, and controlled by a computer program 110, stored in a memory 120 and implementing the process for obtaining according to the invention.
  • the transmitter and receiver can be wireless and use a protocol such as for example WiFi, BlueTooth, 4G, etc.
  • the device also includes a decoder 103 of audiovisual encoding format such as for example HEVC.
  • the code instructions of the computer program 110 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 130.
  • Such a processing unit 130 is capable of, and configured for:
  • Estimate the display window as a function of a prediction of an orientation of the head-mounted display capable of being taken at the time of display, for example according to data relating to the head-mounted display transmitted by the sensor (Pos),
  • processing unit 130 is also able to, and configured for:

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Controls And Circuits For Display Device (AREA)

Abstract

Méthode et dispositif de diffusion de vidéo à 360 degrés L'invention concerne un procédé d'obtention de segments vidéo d'une sphère vidéo pour affichage dans un visiocasque connecté à un serveur vidéo, les segments vidéo étant divisés spatialement en une pluralité de tuiles encodables dans au moins deux niveaux distincts de qualité, dont un niveau de qualité élevé et un niveau de qualité bas, une partie de la sphère vidéo destinée à être affichée à un instant d'affichage étant appelée fenêtre d'affichage, le procédé comprenant avant l'instant d'affichage au moins deux itérations de la suite (E2) d'étapes suivantes: - estimation (F1) de la fenêtre d'affichage, en fonction d'une prédiction d'une orientation du visiocasque susceptible d'être prise à l'instant d'affichage, - identification (F2) de tuiles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité élevé, - identification (F2) de tuiles voisines de celles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité bas, - émission (F3) à destination d'un serveur vidéo, pour au moins une des tuiles identifiées, d'une requête relative à l'obtention de la tuile encodée, la requête comprenant une indication du niveau de qualité associé, le procédé comprenant en outre les étapes suivantes: - réception (E3) de réponses aux requêtes émises, en provenance du serveur vidéo, comprenant des tuiles encodées, - détermination (E4) de la fenêtre d'affichage à l'instant d'affichage en fonction d'une position constatée du visiocasque, - décodage (E5) et affichage (E1) des tuiles reçues, correspondant à la fenêtre d'affichage déterminée.

Description

Méthode et dispositif de diffusion de vidéo à 360 degrés
1. Domaine de l'invention
L'invention se situe dans le domaine de la réalité virtuelle, et plus particulièrement celui des systèmes de diffusion en mode continu ("streaming" en anglais) de vidéo à 360 degrés.
2. Etat de la technique antérieure
Dans un système de diffusion en streaming de vidéo à 360 degrés, l’utilisateur regarde à chaque instant une partie seulement de la vidéo sphérique complète, appelée sphère vidéo. Cette partie, appelée fenêtre d’affichage, dépend de l’orientation de la tête de l’utilisateur et de la taille de l’écran dans son terminal, appelé visiocasque, ou casque HMD ("Head Mounted Device", dispositif monté sur tête, en anglais). Pour assurer une bonne qualité d’expérience, aussi appelée qualité d’immersion virtuelle, et pour éviter la cinétose (mal des transports), le terminal de l’utilisateur doit adapter à chaque instant le contenu audiovisuel dans la fenêtre d’affichage en fonction des mouvements de tête de l’utilisateur.
Une première technique de diffusion de vidéo à 360 degrés consiste à transmettre au terminal de l’utilisateur l’intégralité du contenu de la sphère vidéo. Le terminal de l’utilisateur se charge alors localement d’extraire de la sphère vidéo la partie à insérer dans la fenêtre d’affichage du casque de l’utilisateur. Cette technique présente l’inconvénient de transporter une quantité de données très supérieure à celle qui est réellement exploitée par le terminal de l’utilisateur. En effet la fenêtre d’affichage représente environ 15% seulement de la sphère vidéo complète. Cette problématique de consommation des ressources réseau est majeure dans le cas de la vidéo à 360 degrés puisque le débit de streaming d’une sphère vidéo complète peut être compris entre plusieurs dizaines et plusieurs centaines de mégabits par seconde. Une deuxième technique de diffusion a pour objectif de pallier l’inconvénient de la première, à savoir réduire la quantité de données transportées. Cette deuxième technique comprend plusieurs opérations.
Les premières opérations interviennent dans la préparation de la vidéo, avant son transport à travers le réseau de télécommunication. La sphère vidéo est d’abord projetée sur un plan à deux dimensions (2D). Puis elle est découpée spatialement en plusieurs parties appelées tuiles, formant par exemple un quadrillage du plan. Ensuite chaque tuile est encodée indépendamment des autres tuiles composant la vidéo. Chaque tuile peut ainsi être décodée indépendamment des autres tuiles sur le terminal de l’utilisateur. Plus précisément, chaque tuile est encodée en plusieurs versions correspondant à différents niveaux de qualités ou à différentes résolutions, par exemple, au moins une version à qualité haute et au moins une version à qualité basse. La vidéo est découpée temporellement en segments (ou "chunks" en anglais), par intervalle de temps. La durée des intervalles de temps (et donc la durée des segments) est fixe pour toute la vidéo, et l’ordre de grandeur de cette durée est une ou plusieurs secondes typiquement. Chaque segment est lui-même composé d'images successives, dont le nombre dépend du nombre d'images par seconde (ou "frame rate", en anglais) de la vidéo, par exemple 60.
Le terme tuile désigne donc une subdivision à la fois spatiale et temporelle de la sphère vidéo. Autrement dit, une tuile représente quelques instants (1 seconde par exemple) de la vidéo sur une surface partielle de la sphère. Les opérations suivantes sont exécutées au niveau du terminal de l’utilisateur. Ces opérations doivent être réalisées pour chacun des segments de la sphère vidéo, au cours de l’intervalle de temps précédant l'affichage du segment. Une première opération consiste à prédire l’orientation donnée par la tête de l'utilisateur au visiocasque, au cours du prochain intervalle de temps, c’est-à-dire prédire la bonne fenêtre d'affichage pour le segment. La seconde opération consiste à demander et recevoir le contenu vidéo pour ce segment et cette fenêtre d'affichage. Il est à noter que la fenêtre d’affichage dans le visiocasque est généralement plus grande que la taille d'une tuile ; l'affichage de la fenêtre d’affichage nécessite donc l'assemblage, au niveau du terminal de l’utilisateur, d’un ensemble de tuiles adjacentes. Le terminal doit ainsi demander et recevoir en qualité haute les tuiles qui recouvrent la fenêtre d’affichage prédite pour le prochain intervalle de temps. Le terminal doit aussi demander et recevoir en qualité basse les autres tuiles (celles qui sont en dehors de la fenêtre d’affichage prédite mais qui risquent de s'y trouver si la prédiction n'est pas juste). Ces tuiles en qualité basse permettent de maintenir l’affichage, si nécessaire en qualité basse, de la vidéo lorsque l’utilisateur effectue des mouvements de tête très marqués et imprévus (i.e. en dehors de la fenêtre d’affichage prédite). En effet, afficher une qualité basse dans tout ou partie de la fenêtre d’affichage provoque certes une dégradation de la qualité d’expérience pour l'utilisateur, mais elle est préférable à l’affichage d’une image fixe ou d’un écran noir. Par ailleurs, ces tuiles en qualité basse permettent aussi à cette seconde technique de transporter à travers le réseau une quantité de données inférieure à la première technique décrite ci-dessus.
L’inconvénient de cette seconde technique est une dégradation de la qualité d’expérience ressentie par l’utilisateur lorsque la prédiction n'est pas parfaite, comme c'est souvent le cas, par exemple lorsqu'il effectue un mouvement de tête très marqué et en dehors de la fenêtre d’affichage prédite.
Un des buts de l'invention est de remédier à ces inconvénients de l'état de la technique.
3. Exposé de l'invention
L'invention vient améliorer la situation à l'aide d'un procédé d'obtention de segments vidéo d'une sphère vidéo pour affichage dans un visiocasque connecté à un serveur vidéo, les segments vidéo étant divisés spatialement en une pluralité de tuiles encodables dans au moins deux niveaux distincts de qualité, dont un niveau de qualité élevé et un niveau de qualité bas, une partie de la sphère vidéo destinée à être affichée à un instant d'affichage étant appelée fenêtre d'affichage, le procédé comprenant avant l'instant d'affichage au moins deux itérations de la suite d'étapes suivantes:
• estimation de la fenêtre d'affichage, en fonction d'une prédiction d'une orientation du visiocasque susceptible d'être prise à l'instant d'affichage,
• identification de tuiles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité élevé,
• identification de tuiles voisines de celles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité bas,
• émission à destination d'un serveur vidéo, pour au moins une des tuiles identifiées, d'une requête relative à l'obtention de la tuile encodée, la requête comprenant une indication du niveau de qualité associé,
le procédé comprenant en outre les étapes suivantes:
• réception de réponses aux requêtes émises, en provenance du serveur vidéo, comprenant des tuiles encodées,
• détermination de la fenêtre d'affichage à l'instant d'affichage en fonction d'une position constatée du visiocasque,
• décodage et affichage des tuiles reçues, correspondant à la fenêtre d'affichage déterminée.
Entre deux instants d'affichage, plus on attend pour prédire l'orientation du visiocasque susceptible d'être prise au prochain instant d'affichage, plus cette prédiction est précise. Donc, plus le procédé attend pour estimer la prochaine fenêtre d'affichage, plus cette estimation est précise car proche du prochain instant d'affichage, mais moins il reste de temps au procédé pour émettre les requêtes et recevoir les tuiles nécessaires en réponse. Le procédé proposé rend inutile ce compromis. Par rapport à la technique antérieure où une seule estimation est effectuée le plus tôt possible pour l'instant d'affichage suivant, le procédé proposé améliore l'estimation à l'aide d'au moins une seconde estimation, tout en garantissant la réception de toutes les tuiles nécessaires. En effet, si après la seconde estimation il ne reste plus suffisamment de temps pour requérir à nouveau toutes les tuiles nécessaires, la première salve de requêtes garantit la réception des tuiles manquantes, même si elles ne sont pas forcément toutes du niveau de qualité correspondant à la seconde estimation.
De plus, le procédé permet un nombre d'itérations de la phase d'estimation supérieur à deux, dans la limite constituée par le temps restant avant le prochain instant d'affichage, et par d'autres paramètres tels que la bande passante de la connexion entre le visiocasque et le serveur vidéo liaison, la puissance de calcul dont bénéficie le visiocasque, etc.
La durée entre deux instants d'affichage est celle d'un segment. On comprend que l'expression "instant d'affichage" désigne en l'instant du début du visionnage d'un segment.
Pour prédire l'orientation du visiocasque, différentes techniques sont possibles, en combinaison ou indépendamment les unes des autres. Les techniques de prédiction connues prennent en compte:
des données relatives au visiocasque, c’est-à-dire son orientation instantanée et sa trajectoire;
des données relatives au contenu de segments vidéo, c’est-à-dire des indications sur des événements particuliers, tels qu'un bruit ou une lumière dans un segment vidéo visionné ou en cours de visionnage, nettement perceptible par l'utilisateur et venant d'un point précis de la sphère vidéo;
des données relatives à des statistiques comportementales propres à un ensemble d'utilisateurs ayant visionné le même type de vidéo à 360 degrés; des données relatives au profil de l'utilisateur, c’est-à-dire propres à sa façon de consommer le contenu de ce type de vidéo à 360 degrés.
Aucune de ces techniques de prédiction n'est parfaite, et un des avantages du procédé proposé est de contribuer à compenser les erreurs de prédiction inévitables, par une stratégie innovante d'obtention des tuiles.
Selon un aspect du procédé d'obtention, la requête comprend en outre une indication d'un niveau de priorité associé à la tuile.
Grâce à cet aspect, il est possible par exemple de prioriser les requêtes concernant des tuiles à niveau de qualité élevé sur les requêtes concernant des tuiles à niveau de qualité bas, ou de prioriser les requêtes pour lesquelles une réponse n'a pas encore été reçue sur des requêtes pour lesquelles au moins une réponse a déjà été reçue. Ainsi, la probabilité est augmentée que toutes les tuiles nécessaires auront été reçues à l'instant d'affichage. Autrement dit, si certaines tuiles sont encore absentes à l'instant d'affichage, ce ne seront pas les plus importantes pour l'utilisateur, et de la bande passante entre visiocasque et serveur vidéo aura été économisée.
Selon un aspect du procédé d'obtention, si l'itération est la première, la requête est une requête de livraison de la tuile encodée correspondant à la tuile identifiée.
Grâce à cet aspect, au moins pour la première estimation de la fenêtre d'affichage, toutes les tuiles identifiées sont requises.
Selon un aspect du procédé d'obtention, si l'itération n'est pas la première et si le niveau de qualité ou le niveau de priorité associé à la tuile identifiée a changé par rapport à l'itération précédente, la requête est une requête d'annulation de livraison de la tuile encodée correspondant à la tuile identifiée, suivie d'une nouvelle requête de livraison de la tuile encodée, comprenant le nouveau niveau de qualité ou le nouveau niveau de priorité associé à la tuile identifiée.
Grâce à cet aspect, de la bande passante entre visiocasque et serveur vidéo est économisée, suite à l'annulation des requêtes concernant des niveaux de qualité ou de priorité devenus non optimaux.
Selon un aspect du procédé d'obtention, si l'itération n'est pas la première et si le niveau de qualité associé à la tuile identifiée a baissé par rapport à l'itération précédente, aucune nouvelle requête n'est émise si la tuile a déjà été reçue.
Grâce à cet aspect, une tuile encodée déjà reçue avec un niveau de qualité supérieur à celui nécessaire pour une tuile identifiée n'est pas redemandée, et de la bande passante entre visiocasque et serveur vidéo est ainsi économisée.
Selon un aspect du procédé d'obtention, la connexion entre le visiocasque et le serveur vidéo comprend un flux distinct par tuile identifiée.
Grâce à cet aspect, il est aisé de gérer individuellement l'obtention des tuiles encodées, notamment pour opérer des modifications sur les requêtes, par exemple suite à un changement de niveau de qualité ou de niveau de priorité d'une tuile identifiée, lors d'une estimation postérieure à la première.
Selon un aspect du procédé d'obtention, la connexion entre le visiocasque et le serveur vidéo utilise le protocole HTTP/2.
HTTP/2 ("Hypertext Transfer Protocol", version 2 du protocole de transfert d'hypertexte, en anglais, décrit dans le document normatif rfc7540), est un protocole permettant de gérer plusieurs flux dans une même connexion, et permettant en particulier l'annulation de flux (tuiles) en cours de livraison afin par exemple corriger une caractéristique ou la priorisation du flux (de la tuile), sans interrompre la connexion. Il est donc particulièrement adapté pour la mise en œuvre du procédé proposé.
Les différents aspects du procédé d'obtention qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L'invention concerne aussi un dispositif d'obtention de segments vidéo d'une sphère vidéo pour affichage dans un visiocasque connecté à un serveur vidéo, les segments vidéo étant divisés spatialement en une pluralité de tuiles encodables dans au moins deux niveaux distincts de qualité, dont un niveau de qualité élevé et un niveau de qualité bas, une partie de la sphère vidéo destinée à être affichée à un instant d'affichage étant appelée fenêtre d'affichage, le dispositif comprenant un récepteur, un émetteur, un décodeur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :
• estimer la fenêtre d'affichage, en fonction d'une prédiction d'une orientation du visiocasque susceptible d'être prise à l'instant d'affichage,
• identifier des tuiles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité élevé, et des tuiles voisines de celles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité bas,
• émettre à destination d'un serveur vidéo, pour au moins une des tuiles identifiées, une requête relative à l'obtention de la tuile encodée, la requête comprenant une indication du niveau de qualité associé,
• répéter, au moins une fois avant l'instant d'affichage, l'estimation pour corriger l'identification des tuiles et corriger des requêtes encore sans réponse,
• recevoir des réponses aux requêtes émises, en provenance du serveur vidéo, comprenant des tuiles encodées,
• déterminer la fenêtre d'affichage à l'instant d'affichage en fonction d'une position constatée du visiocasque,
• décoder et afficher des tuiles reçues, correspondant à la fenêtre d'affichage déterminée.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé d'obtention qui vient d'être décrit, est destiné à être mis en œuvre dans un terminal d'utilisateur tel que par exemple un visiocasque.
L'invention concerne encore un visiocasque comprenant un dispositif conforme celui qui vient d'être décrit, un capteur de position et de mouvement, et un écran.
Plus généralement, par visiocasque, il faut comprendre tout terminal d'utilisateur permettant à un utilisateur de visualiser au moins partiellement une sphère vidéo.
L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé d'obtention de données d'une sphère vidéo pour affichage dans un visiocasque connecté à un serveur vidéo, qui vient d'être décrit, lorsque ce programme est exécuté par un processeur.
L’invention vise aussi un support d'informations lisible par un dispositif compris dans un visiocasque, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le programme mentionné ci-dessus peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
Le support d'informations mentionné ci-dessus peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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.
Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc. D'autre part, un support d'informations 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. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
4. Présentation des figures
D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
- la figure 1 présente un exemple de découpage d'une sphère vidéo en tuiles, selon un mode particulier de réalisation de l'invention,
la figure 2 présente de façon schématique un exemple de séquencement des étapes du procédé d'obtention de segments vidéo, selon un mode particulier de réalisation de l'invention,
la figure 3 présente un exemple de structure d'un dispositif d'obtention de segments vidéo, selon un aspect particulier de l'invention.
5. Description détaillée d'au moins un mode de réalisation de l'invention
Le mode de réalisation présenté ci-après utilise une subdivision d'une sphère vidéo en 24 tuiles, une durée des segments vidéo de 1 seconde, deux itérations de prédiction de la fenêtre d'affichage de 500ms chacune pour chaque intervalle entre segments, et le protocole HTTP/2 pour la connexion entre le visiocasque et le serveur vidéo, mais ces choix ne représentent qu'un exemple indicatif et non-limitatif de réalisation de l'invention.
L'expression "sphère vidéo" ne se limite pas à une sphère mais désigne toute vidéo dont une partie seulement peut être affichée à tout moment, la partie affichée dépendant de la position réelle ou virtuelle du terminal d'affichage, ou de son orientation, c’est-à-dire la direction pointée par celui-ci, par rapport à la vidéo complète. Les exemples développés ci-après comprennent un visiocasque, mais l'invention fonctionne avec tout terminal permettant à un utilisateur de visualiser une "sphère vidéo".
La figure 1 présente un exemple de découpage d'une sphère vidéo en tuiles, selon un mode particulier de réalisation de l'invention.
Pour générer une vidéo à 360 degrés, plusieurs vidéos classiques peuvent être nécessaires afin de couvrir l'ensemble de la sphère vidéo. La préparation de la vidéo à 360 degrés avant son visionnage demande plusieurs opérations. Suite à l'assemblage en une sphère vidéo des différentes vidéos classiques la composant, la dite sphère est projetée en deux dimensions pour faciliter sa subdivision en parties appelées tuiles. Cette subdivision est adaptée au streaming et ne correspond pas forcément aux composantes vidéo servant de source pour générer la vidéo à 360 degrés. Une projection commune est la projection dite équi-rectangulaire, dont un exemple est illustré par la figure 1. Dans cette projection qui n'est qu'un exemple donné à titre indicatif et non limitatif, la sphère vidéo est divisée spatialement en 24 rectangles. A chacun des rectangles, à un instant d'affichage donné, correspond une subdivision spatiale d'un segment vidéo, aussi appelée tuile. Par commodité, les rectangles sont appelé tuiles dans la suite. Les tuiles sont numérotées T1 à T24. Par souci de clarté seules les tuiles T1 , T2, T23 et T24 sont indiquées, les emplacements des autres tuiles pouvant aisément être déduits.
Les tuiles peuvent être encodées (compressées) indépendamment les unes des autres, à différents niveaux de qualité, par exemple en utilisant un codeur HEVC ("High Efficiency Video Coding", ou codage vidéo de haute efficacité, en anglais) côté serveur vidéo et un décodeur correspondant côté client, c’est-à-dire du côté du visiocasque.
A tout moment, seule une partie de la sphère vidéo, appelée fenêtre d'affichage, peut être regardée par l'utilisateur du visiocasque, ce qui rend inutile de transmettre l'ensemble complet des tuiles formant la sphère. Comme l'utilisateur fait bouger le visiocasque par ses mouvements de tête, la détermination exacte de la fenêtre d'affichage est un problème de prédiction, dont plusieurs solutions sont connues. Ces solutions nécessitent le découpage de la sphère vidéo en différentes régions, selon leur probabilité de se trouver dans la fenêtre d'affichage lors de la prochaine période d'affichage d'un segment vidéo dans le visiocasque.
L'exemple de la figure 1 utilise des régions numérotées 1 à 4, et représente une prédiction de la fenêtre d'affichage avant un instant d'affichage quelconque:
La région 1 représente une estimation de la fenêtre d'affichage; des parties de cette zone ont une probabilité très forte d'être incluses dans la fenêtre d'affichage
La région 2 représente la zone d'extension de la fenêtre d'affichage, correspondant à de légers mouvements de tête naturels de l'utilisateur; des parties de cette zone ont une probabilité forte d'être incluses dans la fenêtre d'affichage,
La région 3 représente la zone de l'arrière-plan immédiat, correspondant à des mouvements plus grands lorsque si l'utilisateur tourne la tête; des parties de cette zone ont une probabilité moyenne d'être incluses dans la fenêtre d'affichage,
La région 4 représente la zone de l'arrière-plan lointain, correspondant approximativement à la moitié de la sphère opposée à la fenêtre d'affichage; des parties de cette zone ont une probabilité faible d'être incluses dans la fenêtre d'affichage.
La région 1 touche 6 tuiles: les tuiles T8 à T10, et T14 à T16. La région 2, quoique légèrement plus grande en surface, touche les mêmes 6 tuiles, aucune tuile n'est à ajouter par rapport à la région 1. Pour couvrir la région 3, 10 tuiles sont à ajouter: les tuiles T2 à T5, T1 1 , T17, et T20 à T23. Enfin, pour couvrir la région 4, les tuiles T1 , T6, T7, T12, T13, T18, T19 et T24 sont à ajouter.
Les limites extérieures d'une région, par rapport à la région de rang inférieur, peuvent être configurées à l'avance. Par exemple, la région 2 est configurée pour être plus grande que la région 1 de 10% dans un axe horizontal, et de 5% dans un axe vertical. La région 4 quant à elle n'a pas de limites extérieures.
Un découpage en un plus grand nombre de régions est possible, mais par souci de clarté et de simplicité, un découpage en 2 régions est utilisé dans la suite. Dans le mode de réalisation de l'invention décrit ci-après, indicatif et non limitatif, le découpage retenu est en deux régions correspondant à la région 2 à forte probabilité, et à la région 3 à faible probabilité. Afin de pouvoir afficher le contenu vidéo d'une région, il est rappelé que le client doit récupérer du serveur toutes les tuiles touchant cette région, même si certaines tuiles ne sont que partiellement couvertes (par exemple les tuiles T8 et T14 de la région 2 dans la figure 1 ), car la granularité du codage est basée sur la tuile. Dans la suite de la description, comme la région 2 est la plus petite région utilisée, elle inclut également les tuiles de la région 1.
La figure 2 présente de façon schématique un exemple de séquencement des étapes du procédé d'obtention de segments vidéo, selon un mode particulier de réalisation de l'invention. Selon ce procédé, afin de réduire la bande passante nécessaire pour recevoir les tuiles, le client demande les tuiles de la région 1 avec un niveau de qualité élevé (plus grande quantité de données par tuile), et les tuiles de la région 3 avec un niveau de qualité bas (moins grande quantité de données par tuile). Afin de réduire davantage la bande passante nécessaire, le client peut en plus demander les tuiles de la région 1 avec une priorité plus élevée que celles de la région 3. Si la bande passante est insuffisante pour toutes les tuiles, celles de la région 1 seront ainsi reçues en priorité.
Le visionnage d'une vidéo à 360 degrés se fait segment par segment, l'intervalle temporel entre deux affichages de segments étant fixe, par exemple 1 seconde. Le procédé est décrit ci-dessous en détail pour l'affichage des tuiles la fenêtre d'affichage à un instant d'affichage, et, en parallèle avec l'affichage, pour l'obtention des tuiles pour l'instant d'affichage suivant qui est 1 seconde plus tard. Affichage et obtention doivent donc être répétés autant de fois qu'il y a d'intervalles temporels (c’est-à-dire de secondes) dans la vidéo complète.
Au préalable, le client doit obtenir auprès d'un serveur des informations décrivant la structure du contenu à récupérer, lors d'une étape G1. Cela peut être par exemple un fichier MPD ("Media Présentation Description", ou description de la présentation du médium, en anglais). Ce fichier indique au client comment la sphère vidéo est subdivisée spatialement (nombre de tuiles, position dans la sphère vidéo), quels niveaux de qualité d'encodage sont disponibles pour une tuile, etc.
Lors d'une étape G2, le client traite les informations extraites du fichier et prépare l'affichage de la toute première fenêtre d'affichage, dite fenêtre courante. Par exemple, le client émet des requêtes dans des flux HTTP/2 séparés pour chacune des tuiles dont il a besoin pour cette fenêtre d'affichage.
L'étape suivante G3 comprend les étapes E1 à E5, et est répétée pour chaque instant d'affichage, toutes les secondes, si l'intervalle temporel entre 2 fenêtres d'affichage est de 1 seconde, comme dans notre exemple. Lors d'une étape E1, le client affiche la fenêtre courante, c’est-à-dire que les tuiles touchant la fenêtre d'affichage courante sont "jouées" pour l'utilisateur du visiocasque (ou "visionnées").
Lors d'une étape E2 se déroulant en parallèle à l'étape E1 , le client estime la fenêtre d'affichage suivante, et émet des requêtes pour les tuiles composant cette fenêtre d'affichage suivante. L'étape E2 comprend les étapes F1 à F3 répétées plusieurs fois. Par exemple, une première itération des étapes F1 à F3 est exécutée au début de l'intervalle temporel courant, puis une deuxième itération est exécutée 500 ms plus tard, à la moitié de la durée de l'intervalle. Par souci de simplicité, le nombre d'itération est ici limité à 2 mais un plus grand nombre est possible. Pour un intervalle temporel de 1 seconde et 2 itérations, la durée de chaque itération est limitée dans notre exemple à 500ms, mais tout autre découpage de l'intervalle temporel est possible, en respectant la durée minimale nécessaire pour une itération, qui dépend de facteurs tels que la puissance de calcul du client, le volume des données vidéo qu'il doit recevoir, la bande passante effective entre le client et le serveur vidéo, etc.
Lors d'une étape F1 de la première itération, le client estime la position de la fenêtre d'affichage qui est la plus probable d'être constatée à la fin de l'intervalle courant. Toute technique de prédiction est utilisable, se basant par exemple sur la position instantanée du visiocasque, et/ou sur la trajectoire du visiocasque, et/ou se basant sur des informations relatives à des éléments de contenu d'intérêt particulier se trouvant à certains endroits de la sphère vidéo dans les segments joués ou encore à jouer, et/ou se basant sur d'autres types d'information. En estimant la position de la fenêtre d'affichage, c'est aussi les limites de chacune des régions prises en compte (régions 2 et 3) qui sont estimées.
Lors d'une étape F2 de la première itération, le client identifie les tuiles de chacune des régions prises en compte, et associe à chacune des tuiles un niveau de qualité adéquat. Par exemple, le niveau de qualité élevé est associé aux tuiles touchant la région 2, et le niveau de qualité bas est associé aux tuiles touchant la région 3. Comme c'est la première itération, aucune tuile pour le prochain instant d'affichage n'a été encore requise par le client. Lors d'une étape F3 de la première itération, le client émet alors vers le serveur vidéo autant de requêtes de livraison de tuiles que de tuiles identifiées. Optionnellement, le client peut inclure un poids à chacune de ses requêtes, proportionnel à la priorité que le client souhaite voir donné par le serveur à la livraison de la tuile demandée dans la requête. Pour une tuile touchant la région 2, un poids élevé est inclus dans la requête. Au contraire, pour une tuile touchant la région 3, un poids bas est inclus dans la requête.
Pour la deuxième itération, l'étape F1 est répétée de façon identique, 500 ms plus tard que la première fois, dans notre exemple de mode de réalisation à 2 itérations et 1 seconde par intervalle temporel. La nouvelle estimation de la fenêtre d'affichage a de fortes chances d'être meilleure car elle est faite moins longtemps avant la fin de l'intervalle, c’est-à-dire moins longtemps avant que le visiocasque atteigne la position qui sera la sienne au prochain instant d'affichage.
Pour la deuxième itération, l'étape F2 est répétée de façon identique, avec un résultat potentiellement différent. Le client identifie les tuiles de chacune des régions, qui sont déterminées cette fois en fonction de la nouvelle estimation.
Lors de l'étape F3 de la deuxième itération, des requêtes vers le serveur vidéo sont également émises, mais d'une façon différente par rapport à la première itération. En effet, toutes les tuiles nécessaires ont déjà été requises une fois. Cependant, la nouvelle estimation de la fenêtre d'affichage peut rendre inadaptés certains niveaux de qualité associés aux tuiles déjà requises.
Par exemple, si une tuile précédemment identifiée en région 2 se trouve à présent en région 3, la requête de livraison de cette tuile, effectuée avec un niveau de qualité élevé est annulée par l'émission d'une requête d'annulation de livraison de cette tuile, puis une nouvelle requête de livraison de cette tuile est émise avec un niveau de qualité bas. Si la réponse à la requête de l'itération précédente, pour la tuile avec un niveau de qualité élevé, a déjà été reçue, le client garde toutefois cette tuile plutôt que de redemander la livraison de la même tuile avec une moindre qualité, afin de préserver la bande passante entre le visiocasque et le serveur vidéo.
Inversement, si une tuile précédemment identifiée en région 3 se trouve à présent en région 2, la requête de livraison de cette tuile, effectuée avec un niveau de qualité bas, est annulée par l'émission d'une requête d'annulation de livraison de cette tuile, puis une nouvelle requête de livraison de cette tuile est émise avec un niveau de qualité élevé. De même, si la réponse à la requête de l'itération précédente, pour la tuile avec un niveau de qualité bas, a déjà été reçue ou est sur le point d'être reçue mais avec peu de bande passante restante, le client peut toutefois décider de s'en contenter, afin de préserver la bande passante entre le visiocasque et le serveur vidéo.
Une tuile n'ayant pas changé de région par rapport à l'itération précédente ne donne pas lieu à l'émission d'une nouvelle requête, sauf si le client constate un retard dans la livraison de certaines tuiles importantes, c’est-à-dire, typiquement, des tuiles de la région 2. Dans ce cas, le client peut décider de revoir le poids associé à une tuile, afin d'en accélérer ou ralentir la livraison par le serveur, par rapport à d'autres. En cas de modification de poids, une requête d'annulation de livraison de la tuile est émise, suivie d'une requête de livraison de cette tuile avec le poids révisé.
Si dans un autre mode de réalisation le nombre d'itérations est supérieur à 2, les étapes F1 à F3 des itérations suivantes sont identiques à celles de la deuxième itération décrite ci-dessus.
HTTP/2 permet la gestion d'un flux par tuile dans une même connexion entre le visiocasque et le serveur vidéo. Aussi, HTTP/2 permet l'annulation d'une requête en cours, ainsi que l’indication dans une requête du niveau de qualité requis, et du niveau de priorité souhaité (à l'aide de poids).
Lors d'une étape E3, le client reçoit des tuiles en provenance du serveur vidéo, en réponses à des requêtes faites lors d'étapes F3 de l'étape E2. Il est à noter que certaines de ces réponses peuvent être reçues alors que l'étape E2 n'est pas encore terminée. Cette étape E3 est de fait composée de multiples sous-étapes de réception d'une tuile.
Lors d'une étape E4, le client détermine la fenêtre d'affichage constatée à la fin de l'intervalle de temps courant. Cette fenêtre est déterminée par la position réelle instantanée du visiocasque, c’est-à-dire la position de la tête de l'utilisateur, à la fin de l'intervalle temporel.
Lors d'une étape E5, le client décode les tuiles reçues couvrant la fenêtre d'affichage constatée, puis combine ces tuiles pour construire un segment vidéo unique. Certaines tuiles en bordure de la fenêtre d'affichage peuvent n'être incluse que partiellement. Alternativement, le client peut décoder toutes les tuiles reçues afin de construire la plus grande partie possible de la vidéo à 360 degrés, puis en extraire la partie nécessaire pour la fenêtre d'affichage constatée. Pour pouvoir construire la vidéo à 360 degré au complet, il faut que les tuiles de la sphère vidéo soient reçues. Pour cela, il suffit de remplacer la région 3 de cet exemple de mise en œuvre du procédé par la région 4 de la figure 1 , ou d'y ajouter la région 4 comme troisième région, avec par exemple un niveau de qualité encore plus bas pour la région 4 que pour la région 3.
Puis la fenêtre d'affichage constatée devient la fenêtre d'affichage courante et le procédé revient à l'étape E1 , afin de traiter l'intervalle temporel suivant. L'ensemble des étapes E1 à E5 (c’est-à-dire l'étape G3 dans la figure 2), est répété jusqu'au dernier intervalle temporel de la vidéo à 360 degrés.
En relation avec la figure 3, on présente maintenant un exemple de structure d'un dispositif d'obtention de segments vidéo, selon un aspect particulier de l'invention.
Le dispositif 100 d'attachement met en œuvre le procédé d'obtention de segments vidéo, dont différents modes de réalisation viennent d'être décrits.
Un tel dispositif 100 peut être mis en œuvre dans un visiocasque HMD1 comprenant un écran Scr et un capteur de position et de mouvement Pos. Par exemple, le dispositif 100 comprend un émetteur 101 , un récepteur 102, une unité de traitement 130, équipée par exemple d'un microprocesseur mR, et pilotée par un programme d'ordinateur 1 10, stocké dans une mémoire 120 et mettant en œuvre le procédé d'obtention selon l'invention. L'émetteur et le récepteur peuvent être sans fil et utiliser un protocole tel que par exemple WiFi, BlueTooth, 4G, etc. Le dispositif comprend également un décodeur 103 de format d'encodage audiovisuel tel que par exemple HEVC.
A l’initialisation, les instructions de code du programme d’ordinateur 1 10 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 130.
Une telle unité de traitement 130 est apte à, et configurée pour :
• estimer la fenêtre d'affichage, en fonction d'une prédiction d'une orientation du visiocasque susceptible d'être prise à l'instant d'affichage, par exemple en fonction de données relatives au visiocasque transmises par le capteur (Pos),
• identifier des tuiles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité élevé, et des tuiles voisines de celles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité bas,
• émettre, à l'aide de l'émetteur 101 , à destination d'un serveur vidéo, pour au moins une des tuiles identifiées, une requête (HTTP/2 req) relative à l'obtention de la tuile encodée, la requête comprenant une indication du niveau de qualité associé,
• répéter, au moins une fois avant l'instant d'affichage, l'estimation pour corriger l'identification des tuiles et corriger des requêtes encore sans réponse,
• recevoir, à l'aide du récepteur 102, en provenance du serveur vidéo, des réponses (HTTP/2 rep) aux requêtes émises, comprenant des tuiles encodées,
• déterminer la fenêtre d'affichage en fonction de la position constatée du visiocasque à l'instant d'affichage, transmise par le capteur (Pos),
• décoder, à l'aide du décodeur 103, des tuiles reçues et correspondant à la fenêtre d'affichage déterminée, et les transmettre à l'écran (Scr) pour visionnage.
Avantageusement, l'unité de traitement 130 est également apte à, et configurée pour :
• émettre, à l'aide de l'émetteur 101 , à destination du serveur vidéo, une requête de livraison d'une tuile comprenant en outre une indication d'un niveau de priorité associé à la tuile,
• émettre, à l'aide de l'émetteur 101 , à destination du serveur vidéo, une requête (HTTP/2 req) d'annulation de livraison d'une tuile encodée.

Claims

REVENDICATIONS
1. Procédé d'obtention de segments vidéo d'une sphère vidéo pour affichage dans un visiocasque (HMD1 ) connecté à un serveur vidéo,
les segments vidéo étant divisés spatialement en une pluralité de tuiles (T1-T24) encodables dans au moins deux niveaux distincts de qualité, dont un niveau de qualité élevé et un niveau de qualité bas,
une partie de la sphère vidéo destinée à être affichée à un instant d'affichage étant appelée fenêtre d'affichage,
le procédé comprenant avant l'instant d'affichage au moins deux itérations de la suite (E2) d'étapes suivantes:
• estimation (F1 ) de la fenêtre d'affichage, en fonction d'une prédiction d'une orientation du visiocasque susceptible d'être prise à l'instant d'affichage,
• identification (F2) de tuiles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité élevé,
• identification (F2) de tuiles voisines de celles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité bas,
• émission (F3) à destination d'un serveur vidéo, pour au moins une des tuiles identifiées, d'une requête relative à l'obtention de la tuile encodée, la requête comprenant une indication du niveau de qualité associé,
le procédé comprenant en outre les étapes suivantes:
• réception (E3) de réponses aux requêtes émises, en provenance du serveur vidéo, comprenant des tuiles encodées,
• détermination (E4) de la fenêtre d'affichage à l'instant d'affichage en fonction d'une position constatée du visiocasque,
• décodage (E5) et affichage (E1 ) des tuiles reçues, correspondant à la fenêtre d'affichage déterminée.
2. Procédé selon la revendication 1 , où la requête comprend en outre une indication d'un niveau de priorité associé à la tuile.
3. Procédé selon l'une des revendications 1 ou 2, où, si l'itération est la première, la requête est une requête de livraison de la tuile encodée correspondant à la tuile identifiée.
4. Procédé selon la revendication 2, où, si l'itération n'est pas la première et si le niveau de qualité ou le niveau de priorité associé à la tuile identifiée a changé par rapport à l'itération précédente, la requête est une requête d'annulation de livraison de la tuile encodée correspondant à la tuile identifiée, suivie d'une nouvelle requête de livraison de la tuile encodée, comprenant le nouveau niveau de qualité ou le nouveau niveau de priorité associé à la tuile identifiée.
5. Procédé selon l'une des revendications 1 ou 2, où, si l'itération n'est pas la première et si le niveau de qualité associé à la tuile identifiée a baissé par rapport à l'itération précédente, aucune nouvelle requête n'est émise si la tuile a déjà été reçue.
6. Procédé selon l'une des revendications précédentes, où la connexion entre le visiocasque et le serveur vidéo comprend un flux distinct par tuile identifiée.
7. Procédé selon la revendication 6, où la connexion entre le visiocasque et le serveur vidéo utilise le protocole HTTP/2.
8. Dispositif (100) d'obtention de segments vidéo d'une sphère vidéo pour affichage dans un visiocasque (HMD1 ) connecté à un serveur vidéo,
les segments vidéo étant divisés spatialement en une pluralité de tuiles (T1-T24) encodables dans au moins deux niveaux distincts de qualité, dont un niveau de qualité élevé et un niveau de qualité bas,
une partie de la sphère vidéo destinée à être affichée à un instant d'affichage étant appelée fenêtre d'affichage,
le dispositif comprenant un récepteur (101 ), un émetteur (102), un décodeur (103), un processeur (130) et une mémoire (120) couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :
• estimer la fenêtre d'affichage, en fonction d'une prédiction d'une orientation du visiocasque susceptible d'être prise à l'instant d'affichage,
• identifier des tuiles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité élevé, et des tuiles voisines de celles recouvrant la fenêtre d'affichage estimée, auxquelles est associé un niveau de qualité bas,
• émettre à destination d'un serveur vidéo, pour au moins une des tuiles identifiées, une requête relative à l'obtention de la tuile encodée, la requête comprenant une indication du niveau de qualité associé,
• répéter, au moins une fois avant l'instant d'affichage, l'estimation pour corriger l'identification des tuiles et corriger des requêtes encore sans réponse,
• recevoir des réponses aux requêtes émises, en provenance du serveur vidéo, comprenant des tuiles encodées,
• déterminer la fenêtre d'affichage à l'instant d'affichage en fonction d'une position constatée du visiocasque,
• décoder et afficher des tuiles reçues, correspondant à la fenêtre d'affichage déterminée.
9. Visiocasque (HMD1 ) comprenant un dispositif (100) conforme à la revendication 8, un capteur (Pos) de position et de mouvement, et un écran (Scr).
10. Programme d'ordinateur, comprenant des instructions pour la mise en œuvre des étapes du procédé d'obtention de données d'une sphère vidéo pour affichage dans un visiocasque connecté à un serveur vidéo selon la revendication 1 , lorsque ce programme est exécuté par un processeur.
11. Support d'informations lisible par un dispositif d'obtention (100) compris dans un visiocasque, et comportant des instructions d'un programme d'ordinateur conforme à la revendication 10.
EP19835685.9A 2018-08-10 2019-08-12 Méthode et dispositif de diffusion de vidéo à 360 degrés Pending EP3834421A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1857459A FR3084980A1 (fr) 2018-08-10 2018-08-10 Methode et dispositif de diffusion de video a 360 degres
PCT/FR2019/051918 WO2020030882A2 (fr) 2018-08-10 2019-08-12 Méthode et dispositif de diffusion de vidéo à 360 degrés

Publications (1)

Publication Number Publication Date
EP3834421A2 true EP3834421A2 (fr) 2021-06-16

Family

ID=67262344

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19835685.9A Pending EP3834421A2 (fr) 2018-08-10 2019-08-12 Méthode et dispositif de diffusion de vidéo à 360 degrés

Country Status (4)

Country Link
US (1) US11490094B2 (fr)
EP (1) EP3834421A2 (fr)
FR (1) FR3084980A1 (fr)
WO (1) WO2020030882A2 (fr)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10419737B2 (en) * 2015-04-15 2019-09-17 Google Llc Data structures and delivery methods for expediting virtual reality playback
KR102173635B1 (ko) * 2016-05-26 2020-11-03 브이아이디 스케일, 인크. 뷰포트 적응형 360도 비디오 전달의 방법 및 장치
WO2018083211A1 (fr) * 2016-11-04 2018-05-11 Koninklijke Kpn N.V. Diffusion en continu d'une vidéo de réalité virtuelle
WO2019120575A1 (fr) * 2017-12-22 2019-06-27 Huawei Technologies Co., Ltd. Vidéo de réalité virtuelle (vr) à 360° pour utilisateurs finaux distants
EP3844104A1 (fr) * 2018-08-27 2021-07-07 ExxonMobil Research and Engineering Company Tamis moléculaires et procédé de fabrication de tamis moléculaires
US10826964B2 (en) * 2018-09-05 2020-11-03 At&T Intellectual Property I, L.P. Priority-based tile transmission system and method for panoramic video streaming

Also Published As

Publication number Publication date
WO2020030882A3 (fr) 2020-04-02
FR3084980A1 (fr) 2020-02-14
US20210297676A1 (en) 2021-09-23
WO2020030882A2 (fr) 2020-02-13
US11490094B2 (en) 2022-11-01

Similar Documents

Publication Publication Date Title
FR2884027A1 (fr) Procede et dispositif de transmission et de reception de sequences d'images entre un serveur et un client
EP3225027A1 (fr) Procédé de composition d'une représentation vidéo intermédiaire
EP3449634B1 (fr) Procédé de composition contextuelle d'une représentation vidéo intermédiaire
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
FR2959636A1 (fr) Procede d'acces a une partie spatio-temporelle d'une sequence video d'images
FR2988964A1 (fr) Technique de distribution d'un contenu video de type immersif
EP3780632B1 (fr) Systeme de distribution d'un contenu audiovisuel
FR3013933A1 (fr) Diffusion adaptative de contenus multimedia
EP3378232B1 (fr) Procédé de traitement de données codées, procédé de réception de données codées, dispositifs, et programmes d'ordinateurs associés
WO2020030882A2 (fr) Méthode et dispositif de diffusion de vidéo à 360 degrés
WO2019220034A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique au sein d'un terminal de restitution d'un réseau de communication local
EP3840335B1 (fr) Réception d'un contenu numérique en mode truque
EP2819424A1 (fr) Procédé d'amelioration du temps de changement entre programmes audiovisuels
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images
FR3101503A1 (fr) 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
EP2536075B1 (fr) Procédé de demande d'accès par un terminal à un contenu numérique apte à être téléchargé depuis un réseau.
WO2021209706A1 (fr) Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau
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
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.
WO2020234030A1 (fr) Restitution d'un contenu en arrière-plan ou sous forme d'incrustation dans le cadre d'un téléchargement progressif adaptatif de type has
FR2845556A1 (fr) Embrouillage adaptatif et progressif de flux video
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
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.
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
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.

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

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: 20210226

AK Designated contracting states

Kind code of ref document: A2

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

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
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: 20230314