FR2964234A1 - Method for controlling display rate of video signal issued from e.g. Blu-Ray reader of wireless communication system, involves adapting number of inactive lines in image of video signal at receiving device according to calculated drift - Google Patents

Abstract

The method involves calculating a drift (800) between a control signal (SV1) i.e. vertical synchronization signal, and another control signal i.e. horizontal synchronization signal (SHL) at an image rate of a receiving device. A number of inactive lines in an image of a video signal at a level of the receiving device is adapted according to the calculated drift, where the image contains active lines including information on pixels to be displayed by a display device i.e. screen. A display rate of the video signal is controlled by a horizontal signal at the image rate of the receiving device. Independent claims are also included for the following: (1) a device for controlling a display rate of a video signal from a video source, comprising a calculation unit (2) a communication system including a video source (3) a computer loadable program comprising a set of instructions to perform a method for controlling the display rate of a video signal issued from a video source.

Description

The present invention relates to a synchronization method for controlling the display timing of a video signal between a transmitting device and a receiving device. In general, the present invention relates to the field of Information and Communication Technologies.

The present invention relates more particularly to a wireless video system. This type of system replaces traditional wiring between video sources and video receivers. A video transmitter transmits a video stream through a wireless interface to video receivers. Video stream transport systems in networks must solve the problem of real-time video playback synchronization. On the one hand, the video stream is generated based on a first video clock of the video source device, and on the other side, the video stream is read based on a second video clock of the receiver. If the two clocks do not operate at precisely the same speed, this means that the video receivers will play the video stream too quickly or too slowly. If the receiver plays the video stream too quickly, it will not have enough video and playback will be interrupted. If, on the other hand, the receiver plays the video stream too slowly, it will not have enough buffer space for receiving video packets and will lose video data. Two types of solutions are known for solving the problem of differences in the writing and reading speeds of video data. The first type of solution is based on the modification of the quantity of images read. In the case where the receiver is faster than the video source, the receiver will sporadically duplicate an image to increase the number of images constituting the reconstituted video stream. In the opposite case where the receiving node is slower than the video source, the receiving node will sporadically delete an image to reduce the number of images constituting the reconstituted video stream. The main advantage of this solution is that it does not modify any of the sync signals of the video. Indeed, the adaptation of the image frequency of the receiver node with respect to the image frequency of the video source is performed only by varying the amount of images. The receiving node thus generates its own video synchronization signals from its local oscillator, which is a guarantee of the stability and the good quality of its video synchronization signals. The major disadvantage of this solution is the deletion of video images. Indeed, this has the effect of degrading the quality of playback of the video stream. The second type of solution is based on the use of PLL (Phase-Locked Loop) loops. A phase locked loop or PLL has the function of generating a first clock signal (resulting signal) synchronous to a second clock signal (reference signal). The resulting clock signal has a multiple frequency or is a fraction of the reference clock signal. The resulting clock signal is fed back into the PLL to allow constant comparison with the reference signal in order to ensure that the resulting clock signal is always synchronous with the reference clock signal, despite the variations that can have the reference clock signal. Depending on the implementations of the PLL, a given amplitude and frequency of variation is tolerated on the reference clock signal. When this tolerance is exceeded, the PLL "hangs up" and the resulting signal is stopped. The use of a PLL for the purpose of harmonizing the image rates of a video source and a receiver node functions as described below. The receiver first reconstitutes a temporal reference of the image rate of the source. There are three equivalent time references respectively the pixel clock (one cycle per pixel), the horizontal synchronization (one cycle per line) and finally the vertical synchronization (one cycle per image). When the source and the receiver are separated by a communication network, the state of the art favors the transport of time references related to either horizontal synchronization or vertical synchronization, because they are less frequent and therefore easier to use. reconstitute without introducing too many errors. Thus, the receiver uses for example the horizontal synchronization signal of the video source as reconstituted by the receiving node as reference clock signal of the PLL. The receiving node provides as division factor of the PLL the number of pixels per line to have as a resultant clock signal a synchronous pixel clock signal of the horizontal synchronization signal of the video source. Then, from a synchronous counter of the pixel clock thus obtained, it generates a synchronous horizontal synchronization signal of the pixel clock as a function of a predetermined number of pixels per line. Similarly, from a synchronous counter of the horizontal synchronization signal thus obtained, it generates a synchronous vertical synchronization signal of the horizontal synchronization signal according to a desired number of lines per image. Similarly, so-called invisible blanking periods ("horizontal blanking" and "vertical blanking" in English terminology) are inserted, used for the insertion of additional control data or to allow the taking into account of the information of the image. synchronization in anticipation of the active periods of the image data and thus allow a processing time prior to the processing of the image data. Unlike the first solution, the solution of PLLs does not allow the use of video synchronization signals generated by the receiving node. On the contrary, the video synchronization signals are generated from the PLLs and will vary according to the variations of the source video signal as reconstituted by the source node. However, this system ensures that all the resulting video synchronization signals (pixel clock, horizontal synchronization, vertical synchronization) will vary completely synchronously because the horizontal synchronization and vertical synchronization signals are directly obtained by a multiplication of the pixel clock. There is therefore no risk of stalling the display due to the quality of the video synchronization signals. In addition, this solution does not have the disadvantages of the first solution insofar as it strictly respects the integrity of the video data (no deletion of images). On the other hand, this solution is based on the fact that the reference synchronization signal reconstituted by the receiver is of a certain stability. Indeed, it has been seen above that the PLLs are sensitive to variations (jitter or "jitter" in English) of the reference clock signal. If the reference signal varies too much (for example, in the case of a video source switchover), the PLLs are no longer able to provide a resultant clock signal. PLLs capable of accepting highly disturbed reference clock signals are very complex and very expensive to implement. Moreover, the protocols allowing a less disturbed reconstitution of the synchronization signal of the video source by the receiver are just as complex and expensive to implement. It is also known, from US Pat. No. 5,517,253, a method of synchronizing the image reading rhythms of a reception device to the image rate of a video source. The method described in this prior art document is based on adding and removing pixels in the invisible part of the lines. Although it does not require PLL and although it respects the integrity of the data, the solution described in this prior art document involves the alteration of the two horizontal and vertical synchronization signals. An object of the present invention is to provide a solution for the synchronization of the playback rate of the video by a receiver on the rhythm of the video source such that the integrity of the video data is preserved (no deletion of images). Another object of the present invention is to provide a solution for the synchronization of the playback rate of the video by a receiver on the rhythm of the video source such that the quality of the synchronization signals of the video is as stable as possible, c that is, the corrections made on the synchronization signals are the "weakest" possible.

Another object of the present invention is to provide a solution for the synchronization of the video playback rate by a receiver on the rhythm of the video source such that the cost of implementing the solution is reasonable (no use of PLL).

The present invention aims to achieve at least one of the aforementioned objects by providing a method of controlling the display timing of a video signal from a video source, transmitted by a transmitting device (DE) to a receiving device ( DR) and intended to be displayed on a display device, the video signal comprising images, each image containing active lines including information on pixels to be displayed by the display device and inactive lines not including information on pixels to be displayed by the display device, characterized in that the display timing is controlled by at least a first control signal (SV1) synchronized to the frame rate of the video source, the method comprising the steps following - calculating a drift between the first control signal (SV1) and a signal (SVL) synchronized to the frame rate at the receiving device; according to the calculated drift, adaptation of the number of inactive lines in an image of the video signal at the receiving device. The determination of a possible drift (such a drift translates a non-synchronization between the image rhythms or rates respectively defined by the video source and the receiving device) makes it possible to decide whether a correction of the drift must be applied to reset the signals SV1 and SVL in relation to each other. Note that the frame rate corresponds to a frame number per second, that is to say a certain data rate. The image rate can also be defined by the frequency of a clock whose rising edge is set at the beginning of each image. The signal SVL is for example fixed on the first control signal SV1.

The arrival rate of the signal or video stream is thus used as a reference.

Note that the local signal to the receiver device based on a local clock for the determination of a drift may be a synchronization signal of the video signal image display. The first control signal SV1 is for example a vertical synchronization signal regenerated by the receiver device. It will be noted that the adaptation of the number of inactive lines of an image has the effect of modulating the reading speed of the video data (pixels) of the image. The playback rate of the video data of the video signal by the receiving device is thus controlled by the rate of generation of the video data by the video source by adapting (adding and deleting) the number of idle lines in an image to be displayed. . The control proposed by the invention strictly respects the integrity of the video data (pixels to be displayed) because the inactive lines added and deleted are in the non-visible part of the image. In an exemplary embodiment, the control signals comprise a pixel clock signal and a horizontal sync signal (SHL), as well as a vertical sync signal (SV1) .The video signal control signals are the most stable possible.

Indeed, the pixel clock is totally stable because generated locally to the receiver device without modulation. The horizontal synchronization signal is totally stable because generated locally without modulation. Only the vertical synchronization signal is progressively slaved (soft control) to the rhythm of the vertical synchronization signal of the video source.

The cost of implementing the control according to the invention is reasonable because, on the one hand, there is no implementation PLL for drift correction by this solution. And, on the other hand, the regeneration of the vertical synchronization signal of the video source by the receiver device does not require a stability as great as that imposed by a PLL. Indeed, the reconstituted vertical synchronization signal is used to detect a phase shift of more or less a line with for example the local vertical synchronization signal. This comparison can be done reasonably with a precision of a few pixels. Note that the transmitting device may or may not be included in the video source. If it is not part of the source, the transmitting device can be associated with the source, for example by being connected to the source. According to one characteristic, the display rate is also controlled by at least a second control signal synchronized to the image rate of the receiver device. Thus, the display timing of the video signal is controlled by combining at least one local control signal with the receiver device and a control signal (SV1) which follows the rhythm of the video data of the video source (ex: rhythm imposed by a video signal). clock of the video source). It should be noted that the second control signal is for example a horizontal synchronization signal and a third control signal is for example a pixel clock signal.

According to one characteristic, the method comprises a step of deleting at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the receiving device is in advance of phase with respect to the video source. According to one characteristic, the method comprises a step of adding at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the receiving device is out of phase with respect to the video source. . Whether there is a phase advance or a phase delay between the composite signals compensation is performed on the inactive lines of an image and thus without altering the synchronization signals. According to one characteristic, the method further comprises a step of readjustment, by the receiver device, of the rising edge of the first control signal (SV1) so that it realigns itself at a beginning of the line when the correction of the calculated drift does not occur. not translated by an integer of inactive line (s). The first control signal is thus locked on a line start when, after deleting or adding a line, a drift remains between the signals. According to one characteristic, the method comprises a step of generating the first control signal (SV1) by the receiver device. According to one characteristic, the calculation of a drift is carried out regularly. The receiving device can indeed regularly monitor over time any drift between the signals. The invention also relates to a device for controlling the display timing of a video signal from a video source, transmitted by a transmitting device (DE) and intended to be displayed on a display device, the signal video comprising images, each image containing active lines including information on pixels to be displayed by the display device and inactive lines not including information on pixels to be displayed by the display device, characterized in that the display rate is controlled by at least a first control signal (SV1) synchronized to the frame rate of the video source, the control device comprising: means for calculating a drift between the first control signal (SV1) and a signal (SVL) synchronized to the image rate of the receiver device, - means for adapting, as a function of the calculated drift, the number of inactive lines in an image of the video signal. According to other features of the device: the display rate is also controlled by at least a second control signal synchronized to the image rate of the receiving device. the display timing is controlled by the second control signal which is a horizontal synchronization signal (SHL) and by a third control signal which is a pixel clock signal. it comprises means for deleting at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the receiving device is in advance of phase with respect to the video source. it comprises means for adding at least one idle line in the image of the video signal to be displayed when the calculated drift reflects the fact that the receiver device is out of phase with respect to the video source. it furthermore comprises means for readjusting the rising edge of the first control signal (SV1) so that it realigns itself at a start of a line when the correction of the calculated drift does not result in an integer number of lines (s). ) inactive (s). it comprises means for generating the first control signal (SV1). the first control signal is a vertical synchronization signal. - The calculation of a drift is done regularly. The invention also relates to a communication system comprising a video source, a transmitting device (DE), a receiving device (DR), a display device and a device for controlling the display rate of a video signal. from the video source, transmitted by the transmitting device (DE) to the receiving device (DR) and intended to be displayed on a display device, the video signal comprising images, each image containing active lines including information on pixels to be displayed by the display device and inactive lines not including information on pixels to be displayed by the display device, characterized in that the display timing is controlled by at least a first signal control device (SV1) synchronized to the frame rate of the video source, the control device comprising: means for calculating a drift between the first control signal (SV1) and a synchronous signal (SVL) it is adapted to the image rate of the receiver device, means for adapting, as a function of the calculated drift, the number of inactive lines in an image of the video signal.

The present invention also relates to a computer program loadable in a computer system, said program comprising instructions for carrying out the method as briefly described above, when this program is loaded and executed by a computer system.

The invention will be better understood from the following description, given purely for explanatory purposes, of an embodiment of the invention, with reference to the appended drawings in which: FIG. 1 illustrates an example of communication system according to the invention; FIG. 2 represents a generic communication device capable of being used as sending node 102 (DE) or as receiving node 103 (DR); Figure 3 illustrates interconnection details between modules in the transmitter portion 206 of Figure 2; Figure 4a illustrates a possible video packet format; FIG. 4b represents the algorithm executed by the video packet transmission module 216 of FIG. 3; Figure 5a is a detailed view of the "display portion" module 205 of Figure 2; Figure 5b is a detailed view of the "Vsync regen" module 504 of Figure 5a; Figure 5c shows the algorithm executed by the module 500 of Figure 5a; FIG. 6a illustrates the algorithm implemented by the drift management module 506 of FIG. 5a; FIG. 6b represents the algorithm executed by the "Vsync monitor" module 530 of FIG. 5b; FIGS. 7a and 7b illustrate digital signals making it possible to control the display rate of a video stream; and FIGS. 8a, 8b and 8c illustrate in the form of algorithms the operation of the "video synchro generator" module 503 of FIG. 5a.

Figure 1 illustrates an example of a wireless video stream communication system. The video system includes a video source 101. This video source 101 may for example be a Blu-Ray player, a digital decoder ("set top box" in English terminology) or a multimedia hard disk The video source generates a stream The video source 101 is connected to a transmitting device (DE) or transmitting node 102 via a standard digital video connection (for example in accordance with the HDMI standard). the source and the transmitting device may alternatively be part of the same communication apparatus The transmitting device 102 communicates with a receiving device (DR) or receiving node 103 by means of a wireless transmission (eg 60 GHz 801.15.3c) The receiver node 103 is connected to a display device 104 such as a display by means of a standard digital video connection 105 (for example to the HDMI standard). communication device or generic node capable of being used as transmitting node 102 or as receiving node 103.

The generic node consists of a video controller portion 204 and a network controller portion 207. The network controller portion 207 is responsible for implementing wireless communications of the video data and control data. The controller portion 204 includes a display sub-portion 205 and a source sub-portion 206. The display sub-portion 205 is responsible for playing the video received (in the form of a video stream) from the controller of the controller. network 207 on a video display device such as the display device 104. The source sub-part 206, meanwhile, is responsible for capturing a video stream from a video source device such as the source 101 and to send it to the receiving node such as the node 103 through the network controller part 207. The two parts 204 and 207 are controlled by a CPU system composed of a data processing unit (CPU) 201, a random access memory (RAM) 202 and a read only memory (ROM) 203. The network controller portion 207 is a standard 60 GHz communication subsystem, implementing either the IEEE 802.15.3 standard or the WirelessHD standard. It is composed of a MAC module 208, a PHY module 209, a transmission antenna module 210, and a reception antenna module 211. For the detailed description of these modules, the reader can refer to either the IEEE standard (standard 802.15.3 modification c) or to the WirelessHD consortium. The network controller 207 also operates a network protocol that ensures that all nodes in the network have access to a single time reference. For example, the network controller may implement the IEEE 1588 protocol.

The source sub-portion 206 of the video controller portion 204 includes an HDMI receiver module 215 capable of receiving a video stream in HDMI format from a video source, through an HDMI connector. This HDMI receiver module 215 outputs image data or pixels on a bus, as well as a plurality of synchronization or video control signals. For example, three video synchronization signals, namely a pixel clock signal, a horizontal synchronization signal and a vertical synchronization signal, are transmitted to two modules 216, 217. Note that the HDMI receiver module 215 may for example be a module marketed under the reference AD9880 by the company Analog Device. The module 216 is a video packet transmission module which receives video data from the receiver module 215. The module 216 also receives from the module 217, called the "Vsync Sampler" module, time information, called timestamps or time tags (known in English terminology as "time stamp"). The module 216 develops video data packets as will be described in more detail with reference to FIG. 3 and transmits them to the network controller portion 207. The module 217, in turn, is responsible for sampling the video data packets. appearances of the vertical synchronization signal from the HDMI receiver module 215. The sampling is more particularly carried out by generating a time stamp relative to a reference network time, as received by the party. network controller 207. The time stamp thus generated is transmitted to the module 216 so as to be inserted in the header of a packet. The display sub-portion 205 includes a video packet receiving module 214 which receives packets from the network controller portion 207.

The module 214 extracts from the received packets the image data or pixels contained in the latter in order to store them and extracts the time stamp, which is then transmitted to a synchronization management module RX.

The module 213 generates synchronization or video control signals and transmits them to an HDMI transmitter module 212. The module 213 also reads the pixels stored in the module 214 and transmits them to the module 212. This display sub-part 205 will be described in more detail with reference to Figures 5a and 5b. The module 212 implements an HDMI TX controller for controlling the display of the data on the display device 104. More particularly, the module 212 receives as input the pixels carried by a bus as well as the three synchronization signals. or video control, namely respectively a pixel clock signal, a horizontal synchronization signal and a vertical synchronization signal. The module 212 drives an HDMI connector out. It will be noted that the HDMI transmitter module is for example marketed by the company Analog Device under the reference of circuit 20 AD9889B. The receiver modules 215 and transmitter 212 are controlled and initialized by the CPU 201 through an I2C bus not shown for the sake of clarity. In addition, the CPU implements an HDMI software driver that can be obtained from the manufacturer of chips or circuits compliant with the HDMI standard. Note that a transmitting device or node has the video controller portion 204 which includes the source sub-part 206. However, for the device or transmitter node function, the display sub-part 205 is not necessary. . Likewise, a receiving device or node has a video controller portion 204 including the display sub-portion 205 without necessarily including the source sub-portion 206 that is not necessary for this feature of the node. As indicated above, FIG. 3 illustrates in greater detail the interconnections between the different modules of the source sub-part 206 of FIG. 2. The reception module HDMI 215 receives from an HDMI connector not shown in FIG. 3, an HDMI 308 video data stream and output the different types of data received. More particularly, the module 215 provides a bus 300 of image data or pixels as well as a control signal of "311" called "Data Enable" and video synchronization control signals 301 (pixel clock signal), 302 (horizontal sync signal) and 304 (vertical sync signal). The sampler module 217 receives from the receiver module HDMI 215 a signal 304 called "Vsync" and receives from the network controller part 207 a network time reference 305 ("network time" in English terminology). The module 217 in turn generates and transmits to the module 216 timestamps 306 ("time stamps").

The video packet transmission module 216 receives from the receiver module HDMI 215 the various aforementioned data 300, 311, 301, 302 and 304 and from the module 217 the timestamps 306. The module 216 thus produces video data packets 307 on the basis of the The above information and data is transmitted to the network controller portion 207. Figure 4a illustrates a possible format of video data packets. The structure of the video packet shown comprises a header 400 and a portion containing payload called payload 401 (known in English as "payload").

The header 400 comprises several fields including a field 402 of image start indication ("start of image flag" in English terminology). This tag is defined by the module 216 of Figures 2 and 3 when the latter builds the first packet of an image. The header 400 also includes a timestamp field 403 (known in English terminology as the "time stamp field") which is defined by the module 216 during the construction of the first packet of an image. Header 400 also includes a first line number field 404. This field 404 contains the number of the first line of an image in the payload 401. Note that each packet can carry several lines of the same image. This field is defined by the module 216 during the development of the payload 401. The header 400 also comprises a last line number indication field 405. This field contains the number of the last line in payload 401.

This field is defined by the module 216 during the development of the payload 401. The payload 401 contains the lines of the video stream which go from the first line shown in FIG. 4a to reference 406 (indicated by the 404 field). ) at the last line represented by 407 (indicated by 405). As will be seen later, these lines of the video stream include information on pixels to be displayed by a display device. FIG. 4b is an algorithm executed by the video packet transmission module 216 of FIGS. 2 and 3 in a transmitting device or node, such as the one referenced 102 in FIG. 1. This algorithm comprises a succession of steps or instructions (portions of software code) that are executed by the module 216 in the event of transmission of data to a receiving device or node, such as that referenced 103 in FIG. 1. The algorithm comprises a first step 410 waiting for the start of an image.

The beginning of an image occurs when the HDMI receiver module 215 of Figures 2 and 3 provides the Vsync vertical control synchronization signal. When the beginning of a new image is detected, the step 410 is followed by a step 411 during which a time stamp 306 is provided by the sampler module 217. The timestamp 306 represents the instant of occurrence of the signal "Vsync" as detected in step 410. This time is defined with respect to a network reference time provided by the network controller part 207.

In the next step 412, the header 400 (FIG. 4a) of the video packet including the timestamp 306 obtained in step 411 is constructed. In the next step 413, the payload 401 of the video packet is constructed by concatenating a plurality of video stream lines (e.g., 16 lines) that are, for example, active lines in the sense that these lines include information about video streams. pixels to be displayed by a display device. In the next step 414, the video data packet thus constructed is transmitted to the network controller portion 207 of Figure 2. The next step 415 of Figure 4b is a test to determine whether the end of the affected image in the video stream is reached or not.

It is considered that the end of the image is reached when all lines of the image have been sent. Note that the number of lines per image depends on the video format used. The information on the video format used is provided by the HDMI receiver module 215 of FIGS. 2 and 3 to the CPU 201 processing unit. This unit 201 then supplies the video packet transmitter module 216 with the number of lines per image information. of the video stream.

In the case where the end of the image concerned has not been reached (number of lines of the image not reached), step 415 is followed by a step 416. During this step, a header of video data packets is built. This header is for a video package that does not contain the beginning of the image. In this packet header, the "timestamp" field 403 is not filled. Step 416 is followed by the step 413 already described during which the payload of a packet is constructed. In the case where the end of the image has been reached (test of step 415), step 415 is followed by the image waiting step 410 already described. Figure 5a shows in detail the display sub-part 205. The display sub-part 205 is used by the receiver device or node 103 to extract the video sent by the transmitting device or node 102 and display this extracted video on the display device 104. The display sub-part 205 comprises the module 214 in charge of the reception of the video packets and the module 213 in charge of generating the synchronization or video control signals as well as the associated pixel flow. The packets and signals are then transmitted to the video interface module 212 (transmission module). The module 214 comprises a network reception module ("Rx from network") 500 which is in charge of recovering the synchronization data as present in the headers 400 of the packets (FIG. 4a) and sending these synchronization data to a module "Vsync regen" 504 of the module 213. The module 500 must also extract the video data as present in the useful part 401 of the packets and store the video data thus extracted in a storage means "FIFO video" 501. The Detailed algorithm of the operation of the module 500 will be described with reference to Figure 5c. The module 213 comprises the "Vsync regen" module 504 already mentioned whose function is to progressively regenerate a signal, named peer-vsync "507 (control signal synchronized to the frame rate of the video source, also denoted SV1), representative of the signal vertical synchronization of the source 101. The reconstitution of the vertical synchronization signal is made from the synchronization information received from the module 500. The module "Vsync regen" 504 has a capacity limited to a regeneration described as "soft" (for example no more than 10 pixels every 3 frames.) If the difference between the vertical sync signal of the source 101 and the regenerated sync signal "peer_vsync" 507 is greater than the "soft" sync capability of the "Vsync Regen" module 504, then the frequency of the local pixel clock signal 514 is changed in the module 515 which generates it.The details of realization of the module "Vsync re Gen. 504 are shown in Figures 5b and 6b. The signal "peer_vsync" 507 (control signal SV1) is supplied by the module 504 at the input of a phase detector module 505. The other input of the detector 505 receives a signal "Vsync" "508 (vertical synchronization signal also noted SVL) provided by a video synchro generator 503. The video synchronization generation module 503 generates the video sync signals according to the local pixel clock signal 514 and parameters representative of the desired video format (number of pixels per line, number of lines per image, duration of the vertical and horizontal synchronization signals, etc.). The operation of this module as well as the detail of the video format parameters are illustrated in Figures 8a, 8b and 8c. The video format parameters are stored by the CPU 201 in a RAM 502. The start of the "video synchro generator" module 503 is synchronized on the first rising edge of the regenerated signal "peer_vsync" 507. The detection module 505 calculates the phase difference between the vertical synchronization signal of the receiver device or node 103, "Vsync" 508 (SVL signal synchronized with the image timing of the receiver device) and the vertical synchronization signal of the video source 101, reconstituted progressively and represented by the signal "peer_vsync" 507 (SV1). The implementation of a phase difference detection module is well known to those skilled in the art and will not be described further here. A drift manager module 506 receives the phase difference information provided by the module 505 and, depending on the nature of the difference or drift found (positive, negative) and the magnitude of the difference. difference or drift found (less than one line, more than one line), the module 506 operates the commands "add_line" 509 or "remove line" 510 to the video synchronization generation module 503. On receipt of the acknowledgment of one of the two commands ("ack_change" 511) by the module 503, the module 506 sends the module 504 a "realign" command 525 to realign the "peer vsync" signal 507 on the beginning of line. The detail of the drift management module 506 is shown in Figure 6a. The module "video synchro generator" 503 acts on the duration of the vertical masking period ("vertical_blanking" in English terminology) of the image on receipt of the commands "add_line" 509 or "remove_line" 510. The line or lines added or deleted at the beginning of the image to be displayed depend, for their number, on the magnitude of the previously calculated difference or drift. These lines are "invisible" to the display and are called inactive lines in that they do not contain information about image pixels to display. The action of the module 503 is at the level of the period called "back porch lines" 913 of FIGS. 7a and 7b. On receipt of a "remove_line" command 510 the module 503 shortens the duration of the "Back porch lines" period 913 of a line. On receipt of an "add line" command 509, the module 503 extends the duration of the "Back porch lines" period 913 by one line. Once the command has been executed, the module 503 sends the module 506 the acknowledgment signal "ack change" 511 already mentioned. The module 212 transmits the video stream to the display device 104 from the "peer_vsync" signal 507 (SV1) as provided by the "Vsyncregen" module 504, "Hsync" signals 512 (SHL) and "from" 513 as provided by the module 503, the local pixel_clock clock signal 514 and a pixel bus extracted from the storage means 501. The storage means 501 is read at the rate of the "of" signal 513 which defines the instants corresponding to the "active" pixels in the active lines of the image to be displayed (see FIGS. 7a and 7b).

The module 515 for generating the local pixel clock signal 514 (this signal cadence / rhythm the pixel display time) is for example composed of a quartz oscillator generating a frequency of 24 MHz, a PLL with a ratio of 116/100, thus generating a clock at 27.84 MHz, then a multiplier to reach the pixel frequency as defined by the video format used (information contained in the RAM 502). Two other ratios that can be used in addition to 116/100, namely 117/100 and 115/100 in case the "soft" synchronization capacity of the "Vsync regen" module 504 is too limited. The invention is advantageously implemented in the device or receiver node 103 since the module 213 is completely synchronous ("full synchronous" in English). Indeed, this module depends only on a single clock signal, namely the pixel clock signal "pixelclock" 514. Other implementations based on PLL depend on at least two clock signals: a local pixel clock such as the clock 514 and a clock resulting from the PLL. The local pixel clock 514 may be generated from a PLL in the module 515, but the pixel clock signal 514 remains the only clock source for all the other modules. In addition, this implementation guarantees a smooth modulation of the phase of the vertical synchronization signal "peer_vsync" 507 by the "Vsync Regen" module 504, thus avoiding a sudden correction of the synchronization. Furthermore, this implementation fully respects the integrity of the video data since the "video synchro generator" module 503 only removes lines that are not active in the images to be displayed. Furthermore, this implementation does not alter the horizontal synchronization signal Hsync 512 since the video synchro generator module 503 does not modify the duration of the active and non-active lines but only their number in an image.

Figure 5b shows in more detail the module "Vsync regen" 504. This module regenerates the vertical synchronization signal (SV1) of the source 101 in the device or receiver node 103 from the synchronization information (timestamps). This synchronization information is inserted into the packet headers by the sending device or node 102 (step 412 of Figure 4b), after which this synchronization information is extracted from the headers in the receiving device or node 103 by the "RX from network" module. "500, then sent to the module" Vsync regen "504.

The synchronization information is exploited by a module "Vsync monitor" 530 as described below with reference to Figure 6e. The "Vsync monitor" module 530 observes the period of the vertical synchronization signal of the source 101 and modulates the nominal duration of the regenerated signal "peer_vsync" 507 (SV1) by changing the value of a "nominal Vsync" register 516. It will be noted that the signal SV1 generated at the receiver device is modified pixel by pixel as a function of the drift of the receiver device with respect to the video source. A counter 517 fed by the pixel clock signal 514 is compared to the "nominal vsync" register 516 by a comparator 518. Whenever the counter reaches the nominal value of the vertical synchronization period, the comparator 518 generates a pulse towards a "high level Vsync" module 522 and to the reset command of the counter 517. The "high level Vsync" module holds the "peer_vsync" signal 507 high for a period defined by the video format used. This information is contained in the RAM 502. An example of these parameters will be provided later with reference to Figure 7b. A network time module 519 generates timestamp time information related to the network clock and as provided by the network controller portion 207. At each rising edge of the peer_vsync signal 507, the module 519 generates a timestamp ("time stamp") and sends it to the "Vsync monitor" module 530.

The "nominal Vsync" register 516 may also receive a realign realignment command 525 sent by the drift management module 506 (Figure 5a) This command includes a cycle time and a + or - sign. a sign -, the "nominal Vsync" register 516 increases its value by adding the difference between its own value and the cycle time included in the command.On receipt of a + sign, the "nominal vsync" register 516 decreases its value. value by subtracting the difference between its own value and the cycle time included in the command Figure 5c illustrates an algorithm executed by the module 500 of Figure 5a (receiving device or node 103). steps, instructions, or portions of software code that are executed during the execution of the algorithm The algorithm includes a first step 700 of waiting to receive a video data packet from the network controller portion 207 of 15Figure 2. As soon as a packet is received the next step 701 is executed. During this step, a test is performed to determine whether the header of the packet contains a flag indicating a start of image ("flag" 402 of Figure 4a). In case of a negative response, step 700 is executed again. In the opposite case (beginning of image), a next step 702 is executed. During this step, a timestamp ("time stamp") is extracted from the header of the packet and the next step 703 is executed. During this step, the extracted timestamp is transmitted to the "Vsync monitor" module 530 of Figure 5b and the next step 704 is executed. During this step, the active lines of the video stream of the useful part 401 of the packet of Figure 4a are stored in the storage means 501 of Figure 5a and the next step 705 is executed. During this step, a test is performed to determine if the end of an image is reached.

The end of an image is reached when all lines of the image have been stored. As already indicated above, the number of lines per image depends on the video format used and this information is sent by the HDMI receiver module 215 of Figure 2 to the processing unit CPU 201 of the sending device or node. The CPU unit 201 of the transmitting device or node transmits this information to the receiving device or node, more particularly to the CPU 201 of the latter, via control data of the network controller part 207. The unit CPU 201 of the device or receiver node sends information on the number of lines per frame of the video or module 500 of Figure 5a. Assuming that the end of an image is not reached, step 705 is followed by a step 706 of waiting for a next video packet from the network controller portion 207. In case of reception packet, step 706 is followed by step 704 already described. Assuming that the end of an image is reached, step 705 is then followed by step 700 already described above. Figure 6a illustrates an algorithm executed by the "Vsync monitor" module 530 of Figure 5b (receiving device or node 103). This algorithm comprises a series of steps, instructions or portions of software code executed during the execution of the algorithm.

This algorithm comprises a first step 600 during which the register 516 is loaded with a value ("nominal Vsync") representative of the target image frequency and which is representative of the frequency of the local pixel clock signal 514 (this means that the nominal value thus charged is equal to the number of pixels per image, including the blanking periods. This value is set by the CPU 201 and stored in the RAM 502.

By way of example, for a 1080p video format using a frequency of 60 Hz, the nominal value of the register 516 is fixed at 2,475,000, corresponding to 1125 (lines per picture) x 2200 (pixels per line). In the next step 601, a timestamp ("time stamp") is expected from the module 500 of Figure 5a. Upon receipt of this time stamp, step 601 is followed by step 602. During this step, counter 517 of Figure 5b starts. Counter 507 is synchronized with the beginning of an image. During this step, the variables "remote V1" and "local V1" are respectively fixed to the previous values (time t-1) of timestamp ("time stamp") and network time. Step 602 is then followed by a step 604 waiting for the occurrence of the next time stamp coming from the module 500 and the occurrence of a local time stamp triggered by the "peer_vsync" signal 507. When this signal 507 mounts, the value of the reference time stamp takes the value of the network time 519. The network time 519 is controlled by the network controller part 207. The step 604 is then followed by a test step 605 to determine if the "Remote Vsync" signal of the video source is slower than the "peer_vsync" signal 507. The information representative of the "Remote Vsync" signal is obtained from the timestamps present in the packet headers. They make it possible to determine the period of the signal from the difference between two timestamps extracted from received packets and which respectively represent the instant of appearance of two consecutive rising edges of said signal. In order to carry out this test, the values [remote time stampremote V1] and [local time stamp-local V1] are compared, where the variables "remote time stamp" 30 and "local time stamp" have respective values for the current values (instant t ) time stamp and network time.

If the first value is greater than the second value, then the "Remote Vsync" signal is slower and step 609 is executed. If not, step 605 is followed by step 607. In step 609, a test is performed to determine whether the timing correction can be softly applied. As previously described, the correction capacity of the module is limited to a predetermined number K of pixels every N cycles. Thus, if the last correction has occurred before N cycles (for example three cycles) have elapsed, step 609 is then followed by step 604 already described and no correction is applied. If the amount or importance of the correction ([remote time stampremote V1] - [local time stamp-local V1]) is greater than the number of pixels K (for example ten pixel clock strokes), then a signal The "local pixel clock ratio" change is sent from module 504 to module 515 ("coarse_correction" 523 in FIG. 5a). Thus, the speed of the pixel clock generated by the module 515 will be modified to be closer to the rhythm of the video source. In the aforementioned case the correction capacity of K pixels by N cycles is exceeded and the requested correction is considered "brutal" Step 609 is then followed by step 604 already described and no correction is applied. If not, step 609 is followed by step 606. In step 606, the "peer_Vsync" signal 507 is slowed down by a number of clock ticks (of the local pixel clock signal). 514) as determined in step 609. More particularly, the signal 507 is slowed by correspondingly activating the decrement control 520 of the register 516 (Figure 5b). Then, the variables "remote V1" and "local V1" respectively take as values the new values of "remote time stamp" and "local time stamp".

Step 606 is then followed by step 604 already described in order to wait for new time stamps information ("time stamps"). Returning to step 605, in the case of a negative test, this step is followed by step 607.

During this step, a test is practiced in order to know if the signal "Remote Vsync" is faster than the signal "peer_vsync" 507. For the implementation of this test, one proceeds to the comparison between the values [remote time stamp-remote V1] and [local time stamp-local V1]. If the first value is less than the second value, then the signal "Remote Vsync" is faster and step 607 is followed by the test step 610. Otherwise, the variables "remote V1" and "local" V1 "respectively take as values the new values of" remote time stamp "and" local time stamp ".

Step 607 is then followed by step 604 already described above. Returning to step 610, a test is performed to determine if the timing correction can be applied smoothly (i.e., not abruptly). As already described, the correction capacity of this module is limited to a number K of pixels every N cycles. Thus, if the last correction has occurred before N cycles (for example three cycles) have elapsed, then step 610 is followed by step 604 already described and no correction is applied. If the quantity or importance of the correction ([local time stamp-local V1] - [remote time stamp-remote V1]) is greater than the number K (for example ten pixel clock shots), then a signal of change the "local pixel clock ratio" is sent by the module 504 to the module 515 of Figure 5a ("coarse_correction" 523) and the step 610 is then followed by the step 604 already described without any correction has been applied.

In the opposite case, step 610 is followed by a step 608 during which the "peer_vsync" signal is accelerated by a number of local pixel clock pulses 514 as defined in step 609.

The signal acceleration is obtained more particularly by correspondingly activating the incrementation control 521 of the nominal register 516 of FIG. 5b. Then, the variables "remote V1" and "local VI" respectively take the values of "remote time stamp" and "local time stamp". Step 608 is then followed by step 604 already described in order to wait for new time stamps information (time stamps). Figure 6b describes an algorithm implemented by the drift management module 506 of Figure 5a.

This module is implemented by the receiving device or node 103 to control the addition and deletion of idle lines by the "video synchro generator" module 503 of FIG. 5a. The adaptation of the number of inactive lines in an image is performed according to the phase shift (or drift) determined by the detection module 505 on the "Vsync" signals 508 and "peer_vsync" 507. The "Vsync" signal 508 is generated by the "video synchro generator" module 503 and is therefore representative of the image frequency supplied to the display device 104. The "peer_vsync" signal 507 is generated by the "Vsync regen" module 504 from information representative of the image frequency of the source 101.

During the initial step 620 of the algorithm, the module waits for a phase difference detection (or drift) calculated by the "phase detector" module 505. Then, when a phase difference has has been detected, the module 506 goes to the next step 621. In the step 621 the module 506 determines via a test the direction of the phase shift that has been determined by the "phase detector" module 505. If the signal "peer_vsync" 507 is in phase advance with respect to the "Vsync" signal 508, then the module proceeds to step 622, otherwise the "Vsync" signal 508 is in phase advance with respect to the "peer_vsync" signal 507 and the module proceeds to step 627.

In step 622, the module 506 determines by a test whether the phase difference (or drift) has reached or exceeded the value of a line. The value of a line is provided by the CPU unit or obtained from the RAM 502. For example, for a 1080p video format the value of a line corresponds to 2200 pixel clock fronts 514. Thus, if the phase difference is equal to or greater than the value of a line, then the module 506 proceeds to step 623, otherwise it loops back to step 620 already described.

In step 623, the module 506 activates the "remove_line" command 510 to reduce the period of the "Vsync" signal 508 (SVL) which is out of phase with the "peer_vsync" signal 507 (SV1). The example in Figure 7a illustrates this case. The module 506 then proceeds to step 624.

During step 624, the module 506 waits for the acknowledgment signal "ack_change" 511 which will be sent by the "video synchro generator" module 503 as soon as the command placed is taken into account. Once the acknowledgment signal has been received, the module 506 proceeds to step 625. In step 625, the module 506 releases the commands placed, then sends a "realign" command 525 to realign the "peer_vsync" signal 507 on the beginning of line. The value of the realignment is for example equal to the difference in the cycle time between the "Vsync" signal 508 and the "peer_vsync" signal 507. The cycle time of the "Vsync" signal 508 is contained in the RAM 502 and the time the "peer_vsync" signal cycle is known from the "Vsync regen" module 504. If the acknowledged command is "add_line" 509 (Figure 5a), then the realignment command includes the indication - and the cycle time of the "Vsync" signal. 508 contained in the RAM 502. If the acknowledged command is "remove_line" 510 (Figure 5a), then the realignment command includes the + indication and the cycle time of the "Vsync" signal 508 contained in the RAM 502. Then, the module 506 loops back to the initial step 620 already described. Returning to step 627, the module 506 tests whether the phase difference has reached or exceeded the value of a line as defined above. Thus, if the phase difference is equal to or greater than the value of a line, then the module proceeds to step 628, otherwise it loops back to step 620 already described. In step 628 the module activates the "add_line" command 509 in order to increase the period of the "Vsync" signal 508 (SVL) which is in phase advance with respect to the "peer_vsync" signal 507 (SV1). The module 506 then proceeds to the step 624 already described. FIG. 7a illustrates in the form of timing diagrams various signals used for the synchronization of a video stream and, more particularly, for controlling the display rate of the images of the video stream on a display device such as the device 104 of FIG. Figure 1. More particularly, the "de" (data_enable) signals 513 of Figure 5a, "Hsync" (SHL) 512 (horizontal synchronization signal) of Figure 5a, "Vsync" (SVL) 508 (signal vertical synchronization) and "peer_vsync" (SV1) 507 (regenerated signal) of Figure 5a. The signals "of", "Hsync" and "Vsync" are signals punctuated on the local clock of the receiving device or node, while the "peer_vsync" signal is clocked on the clock of the video source or the device or node transmitter if source and sending device are merged. The combination of a control signal (SV1) synchronized to the video source with one or more synchronized signals on the receiving device or node makes it possible to control the display timing of the video and thus to make corrections for display in a particularly gentle way. The signals "Hsync", "Vsync" and "peer_vsync" are each represented by a succession of pulses which are in fact slots as shown in Figure 7b which will be described below. The "Vsync" signal pauses the display of images while the "Hsync" signal pauses the display of lines within an image. The "of" signal, meanwhile, paces the display of pixels on an active line in combination with the local pixel clock signal 514 not shown in Figure 7a for the sake of clarity. As shown in FIG. 7a, a deviation or drift occurs between the "peer_vsync" (SV1) and "Vsync" (SVL) signals and is calculated by the module 505 of FIG. 5a.

The successive deviations or drifts detected are represented by references 800, 801 and 802 in FIG. 7a. Assuming that an image to be displayed contains a number K of lines (including active and inactive lines), the incoming stream consisting of these K lines is punctuated by the signal "peer_vsync" which is synchronized with the clock of the video source. As long as the drift between the "peer_vsync" and "Vsync" signals remains less than one line (drifts 800 and 801 in FIG. 7a), the display of these K lines can be performed according to the display rate provided by the local clock of the device or receiving node without a correction intervenes. However, when the observed drift (eg drift 802) is greater than one line, the invention provides for setting up a correction so that the local clock of the receiving device or node and all the useful signals derived therefrom synchronize. on the signal "peer_vsync" and therefore on the clock of the video source. Indeed, with such a drift if no correction is made then the K lines of the image can not be displayed on a single image and will "overflow" on the next image, creating unacceptable visual disturbances.

As shown in FIG. 7a following the detected drift 802, a correction is made for the display of the next image, thus making it possible to obtain a synchronization between the "peer_vsync" and "Vsync" signals as represented by the reference 803 In the example shown, the correction made is adapted to the drift that has been detected and consists in deleting an inactive line among the (KM) inactive lines of K lines of the image to be displayed M representing the number of lines active). The number of inactive lines to be deleted from an image (or to be added according to the sign of the phase shift between the signals "peer_vsync" and "Vsync") depends on the amplitude of the drift that has been determined. Figure 7b shows on a larger scale the "de", "Hsync" and "Vsync" signals. - Figure 7b is divided into two parts: a first upper portion 900 represents the timing diagram of a video line and a second lower portion 901 represents the timing diagram of an image. On the first part 900 a new line starts with a rising edge of the signal "Hsync" 512 (SHL). Upstream of this rising edge is the period "front porch pixels" 905. Downstream of the falling edge is the period "Back porch pixels" 906. The set including the period "front porch pixels" 905, the period covering high state 909 of the signal "Hsync", and the period "Back porch pixels" 906 forms the period 908 called "horizontal_blanking" (horizontal masking) during which the pixels of the line are invisible (inactive), that is to say say they are not to display. The inactive part of the line is signaled by a low state of the "de" (data_enable) signal 513. The period between the "Back porch pixels" period 906 and the next "Front porch pixels" period 905 defines the active part 907 of line.

During the active part 907 of the line, the pixels to be displayed are taken into account and displayed. The active part of the line is signaled by a high state of the "from" signal 513. It is the pixel clock signal that paces the number of clock ticks from which the first pixel of a line is to be displayed. . The pixel clock signal is not shown in this diagram for the sake of clarity.

When the "from" signal 513 is high, one pixel must be provided at each rising edge of the pixel clock signal. For example, for the video format used1080p60 as defined by the CEA-861-D standard, the "Front porch pixels" period has a duration equivalent to 88 pixels, the high level of the "Hsync" signal has a duration equivalent to 44 pixels, the "Back porch pixels" period has a duration equivalent to 906 pixels and the active part of the line comprises 1920 pixels. On the second lower portion 901 of Figure 7b, a new image begins with a rising edge of the "Vsync" signal 508 (SVL). Upstream of the rising edge of the "Vsync" signal is the "Front porch lines" period 911. Downstream of the falling edge of the "Vsync" signal is the "Back porch lines" period 913. The set comprising the "Front porch" period porch lines ", the period covering the high state 912 of the signal" Vsync "and the period" Back porch Unes "913 form the period 910 called" vertical_blanking "(vertical masking). During the "vertical_blanking" period 910 the lines are invisible (inactive), that is, they are not displayed. The "of" signal 513 is also in the low state during the entire "vertical_blanking" period 910. On the other hand, the "Hsync" signal 512 continues to indicate the line boundaries even if they are inactive during the "vertical_blanking" period. "910. Beyond the" vertical_blanking "period 910, the lines are said to be active (period referenced 914) and therefore contain pixels to be displayed (eg: M active lines in FIG. 7a). In general, depending on the drift, the period "back porch lines" 913 can be increased by one or more lines inside an image to slow down the image frequency on average (during the display of an image the display time has been lengthened by one or more lines). Conversely, depending on the drift, the period "back porch lines" 913 can be reduced by one or more lines in an image to accelerate on average the image frequency (during the display of an image the display time s' is found shortened by one or more lines). In the example of Figure 7a, the period 913 has been shortened (shortened period noted 913 ') by deleting an inactive line of the image. Under the Hsync signal periods 911 and 912 + 913 have been represented with braces and the period 906 preceding the appearance of a rising edge of the "513" signal has also been indicated. Moreover, the correction made (modified period 913 ') for modifying the rate of display of an image was represented after the rising edge triggering a new image. This new image thus contains only K-1 lines counted according to the local clock of the device or receiving node instead of K images (the number of M active lines to display has not changed). Alternative embodiments could act on the "front porch lines" period 911 or on the duration of the high state 912 of the "Vsync" signal 508. The embodiment described here, however, is the most advantageous.

Indeed, the period "Back porch lines" 913 is the longest, so reducing it by one line gives the smallest change ratio, which turns out to be less disturbing for the display device 104 of FIG. 1. Furthermore, changing the duration of the high state 912 of the signal "Vsync" would add another risk of disturbance of the display device 104. The orders of magnitude are for example indicated as follows, for the format 1080p60 as defined by the CEA-861-D standard: the "front porch lines" period 911 has a duration equivalent to 5 lines, the high level 912 of the "Hsync" signal has a duration equivalent to 5 lines, the "Back porch lines" period 913 has a duration equivalent to 36 lines and the number M of active lines 914 is equal to 1080 lines. Note that the signals shown in Figs. 7a and 7b bear different references to those shown in Fig. 3 (301, 302, 304 and 311) but they are the same signals. Figures 8a, 8b and 8c illustrate the operation of the video synchro generator module 503 of Figure 5a. The "video synchro generator" module 503 implements three algorithms in parallel respectively shown in FIGS. 8a, 8b and 8c. A first algorithm illustrated in FIG. 8a is intended to generate the "Hsync" signal 512 (SHL) and an internal horizontal_blanking signal, referenced 908 in FIG. 7b, taken into account by the algorithm of FIG. FIG. 8c for the generation of the "from" signal 513. During the initial step 640 of the algorithm the module 503 waits for a rising edge of the "peer_vsync" signal 507 in order to synchronize its start on this signal . During this step the signal "Hsync" 512 is kept low and the signal "horizontal_blanking" is kept in a high state. Upon detection of a rising edge of the "peer_vsync" signal 507 the module 503 proceeds to the next step 641. In the step 641 the module 503 enters horizontal synchronization phase. During this step, the "Hsync" signal 512 is kept high 909 in FIG. 7b (first part 900) and the "horizontal_blanking" signal is kept in a high state. The duration of this state is a function of the image format contained in the RAM 502 and which is, for example, 44 fronts of the pixel clock signal 514 for a 1080p60 video format. At the end of this period the module 503 proceeds to the next step 642. In the step 642 the module 503 enters the period of "Back porch pixels" 906 in Figure 7b (first part). During this step the signal "Hsync" 512 is kept low and the signal "horizontal_blanking" is kept in a high state. The duration of this state is a function of the image format as stored in the RAM 502. This duration is for example 148 fronts of the pixel clock signal 514 for a 1080p60 video format. At the end of this period the module 503 proceeds to the next step 643.

In step 643 the module 503 enters the display phase of the "active" pixels of an active line of an image (phase referenced 907 in FIG. 7b). During this step the signal "Hsync" 512 is kept low as is the signal "horizontal_blanking". The duration of this state is a function of the image format as stored in the RAM 502. This duration is for example 1920 fronts of the pixel clock signal 514 for a 1080p60 video format. At the end of this period the module 503 proceeds to the next step 644. In the step 644 the module 503 enters the period of "Front porch pixels" (period 905 in Figure 7b). During this step the signal "Hsync" 512 is kept low and the signal "horizontal_blanking" is kept in a high state. The duration of this period or state is a function of the image format as stored in the RAM 502. This duration is for example 88 edges of the pixel clock signal 514 for a 1080p60 video format. At the end of this period the module 503 returns to the already described step 641.

Steps 641, 642 and 644 correspond to the "horizontal_blanking" period 908 of Figure 7b during which the pixels are "inactive" (no pixel display). Step 643 corresponds to the period 907 of FIG. 7b where the pixels of a line are "active", that is to say that they are displayed at the rhythm of the local pixel clock.

A second algorithm illustrated in FIG. 8b is intended to generate the "Vsync" signal 508 (SLV) of FIGS. 5a and 7a and an internal vertical_blanking signal, referenced 910 in FIG. 7b, taken into account. by the algorithm of FIG. 8c for the generation of the "from" signal 513. This algorithm is furthermore in charge of the management of the "add_line" commands 509 and "remove_line" 510 of FIG. 5a. During the initial step 650 of the algorithm the module 503 waits for a rising edge of the "peer_vsync" signal 507 in order to synchronize its start on this signal. During this step, the "Vsync" signal 508 (SVL) is kept low and the "vertical_blanking" signal 910 is kept in a high state. On detection of a rising edge of the "peer vsync" signal 507 the module 503 proceeds to the next step 651.

In step 651 the module 503 enters a period or phase of vertical synchronization (referenced 912 in Figure 7b). During this step, the "Vsync" signal 508 is kept high, as is the "vertical_blanking" signal. The duration of this state is a function of the image format as known from the RAM 502. This duration is for example 5 lines for a 1080p60 video format. At the end of this period, the module 503 proceeds to the next step 652. In the step 652, the module carries out a test to determine whether it has received an "add_line" command 509 or "remove_line" 510 from the manager. drift 506 (Fig. 5a). If it has received one of the two commands, it goes on to the next step 653. Otherwise, it goes on to the next step 655. In step 653 the module 503 modifies the duration of the "Back porch lines" period. (Period 913 in Figures 7a and 7b) to come. This new duration is a function of the command received and is adapted to the drift between the signals "Vsync" (SVL) and "peer-vsync" (SV1). The duration of the "back porch lines" period 913 is a function of the image format contained in the RAM 502 and is, for example, 36 lines for a 1080p60 format. If the command received is "add_line" 509, then the duration of the period "Back porch lines" is incremented by one unit (37 lines for example). If the received command is "remove_line" 510, then the duration of the period "Back porch lines" is decremented by one unit as in the example of Figure 7a (35 lines for example). The modified duration noted 913 'has been represented in FIG. 7a. These new values are not stored in RAM 502. Module 503 then proceeds to step 654.

In step 654 the module 503 sends an acknowledgment signal "ack change" to the drift management module 506. The module 503 then proceeds to step 655. In step 655 the module 503 enters the "Back porch lines" period (913 in Figures 7a and 7b). During this step, the "Vsync" signal 508 is kept low and the "vertical_blanking" signal 910 is kept in a high state. If the transition to this state comes directly from step 652, then the duration of this state is a function of the known image format of the RAM 502. The duration is for example 36 lines for a 1080p60 format. If the transition to this state comes from steps 653 and 654 then the duration of this state is a function of the calculation performed in step 653 and is, for example 35 or 37 lines. At the end of this period the module 503 proceeds to the next step 656. In the step 656 the module 503 enters a phase or period of display of active lines (914 in Figure 7b). During this step, the "Vsync" signal 508 is kept low as is the vertical_blanking signal. "The duration of this state is a function of the known image format of the RAM 502. This duration is, for example, 1080 lines for a 1080p60 format At the end of this period the module 503 proceeds to the next step 657. At the step 657 the module 503 enters a period of "front porch lines" (911 in FIGS. 7b) During this step, the "Vsync" signal 508 is kept low and the "vertical_blanking" signal is kept in a high state The duration of this state depends on the known image format of the RAM memory 502. This duration is for example 5 lines for a 1080p60 video format At the end of this period, the module 503 returns to the step 651 already described.The steps 651, 655 and 657 correspond to the vertical_blanking period "910 of the Figure 7b during which lines are inactive (no line display) . Step 656 corresponds to the "Active lines" period 914 during which the lines are active, that is to say that they are displayed.

A third algorithm illustrated in FIG. 8c is intended to generate the signal "from" 513. This algorithm consists of a single step 660 executed continuously and which positions the signal "from" 513 of FIGS. 5a, 7a and 7b to the high state when the two signals "horizontal_blanking" and "vertical_blanking" are themselves in the high state. Otherwise, if one of the two signals "horizontal_blanking" or "vertical_blanking" is set low, then the "from" signal 513 is also set low.

Claims (20)

1. A method for controlling the timing of display of a video signal from a video source, transmitted by a transmitting device (DE) to a receiving device (DR) and intended to be displayed on a display device , the video signal comprising images, each image containing active lines including information on pixels to be displayed by the display device and inactive lines not including information on pixels to be displayed by the display device , characterized in that the display timing is controlled by at least a first control signal (SV1) synchronized to the frame rate of the video source, the method comprising the following steps: - calculating a drift between the first signal of control (SV1) and a synchronized signal at the image rate of the receiver device; according to the calculated drift, adaptation of the number of inactive lines in an image of the video signal at the receiving device. 2. Method according to claim 1, characterized in that the display rate is also controlled by at least a second control signal synchronized to the image rate of the receiver device. 3. Method according to claim 2, characterized in that the display timing is controlled by the second control signal which is a horizontal synchronization signal (SHL) and by a third control signal which is a pixel clock signal . 4. Method according to one of claims 1 to 3, characterized in that it comprises a step of removing at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the device receiver is in advance of the video source. 5. Method according to one of claims 1 to 3, characterized in that it comprises a step of adding at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the receiver device is out of phase with the video source. 6. Method according to claim 4 or 5, characterized in that it further comprises a step of readjustment, by the receiving device, frontfront amount of the first control signal (SV1) so that it realigns on a beginning of line when the correction of calculated drift does not result in an integer number of inactive line (s). 7. Method according to one of claims 1 to 6, characterized in that it comprises a step of generating the first control signal (SV1) by the receiving device. 8. Method according to one of claims 1 to 7, characterized in that the first control signal is a vertical synchronization signal. 9. Method according to one of claims 1 to 8, characterized in that the calculation of a drift is performed regularly. 10. Device for controlling the timing of display of a video signal from a video source and transmitted by a transmitting device (DE) and intended to be displayed on a display device, the video signal comprising images, each image containing active lines including information on 15 pixels to be displayed by the display device and inactive lines not including information on pixels to be displayed by the display device, characterized in that the rate of the display is controlled by at least a first control signal (SV1) synchronized to the frame rate of the video source, the control device comprising: means for calculating a drift between the first control signal (SV1) and a signal (SVL) synchronized to the image rate of the receiver device; means for adapting, as a function of the calculated drift, the number of inactive lines in an image of the video signal. 25 11. Device according to claim 10, characterized in that the display rate is also controlled by at least a second control signal synchronized to the image rate of the receiver device. Device according to claim 11, characterized in that the display timing is controlled by the second control signal which is a horizontal synchronization signal (SHL) and by a third control signal which is a clock signal. pixel. 13. Device according to one of claims 10 to 12, characterized in that it comprises means for deleting at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the device receiver is in advance of the video source. 14. Device according to one of claims 10 to 12, characterized in that it comprises means for adding at least one inactive line in the image of the video signal to be displayed when the calculated drift reflects the fact that the receiver device is out of phase with the video source. 15. Device according to claim 13 or 14, characterized in that it further comprises means for readjusting the rising edge of the first control signal (SV1) so that it realigns on a beginning of line when the correction of the Calculated drift does not result in an integer of inactive row (s). 16. Device according to one of claims 10 to 15, characterized in that it comprises means for generating the first control signal (SV1). 17. Device according to one of claims 10 to 16, characterized in that the first control signal is a vertical synchronization signal. 18. Device according to one of claims 10 to 17, characterized in that the calculation of a drift is performed regularly. 19. A communication system comprising a video source, a transmitting device (DE), a receiving device (DR), a display device and a device for controlling the display rate of a video signal from the video source, transmitted by the transmitting device (DE) to the receiving device (DR) and intended to be displayed on a display device, the video signal comprising images, each image containing active lines including information on pixels to be displayed by the display device and inactive lines not including information on pixels to be displayed by the display device, characterized in that the display timing is controlled by at least a first synchronized control signal (SV1) at the frame rate of the video source, the control device comprising: means for calculating a drift between the first control signal (SV1) and a signal (SVL) synchronized with the frame rate of the device receiver, means for adapting, as a function of the calculated drift, the number of inactive lines in an image of the video signal. 20. A computer program loadable in a computer system, said program containing instructions for implementing the control method according to one of claims 1 to 9, when the program is loaded and executed by a computer system. 10