EP4360298A1 - Gestion d'une audioconference audio et/ou video - Google Patents

Gestion d'une audioconference audio et/ou video

Info

Publication number
EP4360298A1
EP4360298A1 EP22737648.0A EP22737648A EP4360298A1 EP 4360298 A1 EP4360298 A1 EP 4360298A1 EP 22737648 A EP22737648 A EP 22737648A EP 4360298 A1 EP4360298 A1 EP 4360298A1
Authority
EP
European Patent Office
Prior art keywords
client terminal
audio
acoustic
audio data
data stream
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
EP22737648.0A
Other languages
German (de)
English (en)
Inventor
Julien Faure
Jean Francois LETELLIER
Sonia Laurent
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 EP4360298A1 publication Critical patent/EP4360298A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/568—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities audio processing specific to telephonic conferencing, e.g. spatial distribution, mixing of participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2236—Quality of speech transmission monitoring
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/018—Audio watermarking, i.e. embedding inaudible data in the audio signal

Definitions

  • the invention relates to the field of audioconferencing and videoconferencing, and relates more particularly to the ability of a user to be heard or not by another user during an audioconference or videoconference.
  • Videoconferencing or audioconferencing systems have experienced significant growth in recent years and this trend has further amplified in the current health context.
  • An audio conference (or audio conference) allows participants to communicate by audio instantly while a video conference (or video conference) allows not only to communicate by audio but also by image instantly.
  • video streams are exchanged between the participants' terminals so that everyone can see and hear their interlocutors.
  • audio streams are exchanged without there being any image stream.
  • the present invention relates to a first method implemented by a first client terminal during a communication session in cooperation with an audio and/or video conference server managing exchanges of audio data streams between the first terminal client and at least one second client terminal during an audio and/or video conference.
  • the first method comprises: - Sending to the audio and/or video conference server, an audio data stream marked by integration of a code assigned to said first terminal in a first audio data stream;
  • said at least one management action comprising: o restitution, by a user interface of the first client terminal, of information depending on the audio capacity data received, indicating whether said at least one second client terminal is capable of receiving an audio data stream from the first client terminal.
  • the first method comprises receiving, from a mediation server (SV2), the code assigned to the first client terminal.
  • SV2 mediation server
  • said code assigned to said first client terminal is received in response to a request to said mediation server comprising an identifier of the first client terminal.
  • the first audio data stream is generated from acoustic signals acquired by a first microphone coupled to the first client terminal.
  • the acoustic signals from which the first audio data stream is generated represent a background noise acquired by the first microphone, the intensity of the background noise being lower than a first intensity value.
  • the first method comprises the first audio data stream is generated by emulating random noise.
  • the first method comprises, before sending the marked audio data stream to the audio and/or video conference server: activation of the first microphone of the first client terminal; deactivation of an echo cancellation function so as to allow acoustic acquisition by the first microphone of the first client terminal of an acoustic emission from a first loudspeaker coupled to said at least one first client terminal; generation of a test acoustic signal by means of the first loudspeaker; acoustic acquisition, by means of the first microphone, of the acoustic test signal emitted by the first loudspeaker; and determination, from a result of said acoustic acquisition, of acoustic capacity data characterizing the acoustic capacities of the first microphone; wherein the information returned by the user interface is further representative of the acoustic capabilities of the first microphone of the first client terminal.
  • the first method comprises: a) obtaining a watermarked audio data stream by embedding a digital marking code into a first watermarked audio data stream; b) sending the tagged audio data stream to the audio and/or video conferencing server; c) receiving, from a mediation server, audio capability data representative of whether said at least one second client terminal has detected the digital marking code in an audio data stream received from the audio conferencing server and/or video ; and d) triggering at least one action for managing the audio and/or video conference from the audio capability data received, said at least one management action comprising: restitution, by a user interface of the first client terminal, of information, depending on the audio capacity data received, indicating whether said at least one second client terminal is capable of receiving an audio data stream from the first client terminal.
  • obtaining a) comprises: e) sending a mediation server a digital marking code request, said request comprising an identifier of the first client terminal; f) receiving, in response to said request, the digital marking code assigned to the first client terminal.
  • the first method comprises: determining, when establishing the communication session, an identifier of the audio and/or video conference; and inserting in the digital marking code request the identifier of the audio conference before sending to the mediation server, so as to allow said mediation server to record the digital marking code in association with the identifier of the first terminal client and the identifier of the audio and/or video conference.
  • an identifier of the audio and/or video conference can notably allow the mediation server to recognize a request associated with the audio and/or video conference in progress, and thus to obtain or generate a code (such as a digital marking code for example) unique for the first client terminal.
  • the mediation server can in particular supervise an audio stream reception test for a plurality of distinct audio and/or video conferences, including when the first client terminal T1 takes part in several conferences simultaneously or successively over a given period.
  • the first audio data stream is generated from acoustic signals acquired by a first microphone coupled to the first client terminal. It is thus possible to carry out an audio test while transmitting sounds from the first client terminal to the second client terminal during the audio and/or video conference.
  • the acoustic signals from which the first audio data stream is generated represent a background noise acquired by the first microphone, the intensity of the background noise being lower than a first intensity value. It is thus possible to carry out an audio test while the user of the first client terminal is silent (not speaking) during the conference in progress.
  • the sending of the digital marking code request is triggered on detection, by means of the first microphone of the first client terminal, of a period of silence of a duration at least equal to a first duration, during which a background noise of an intensity lower than said first intensity value is detected. It is thus possible to automatically trigger an audio test when the user of the first client terminal is silent (not speaking) during the conference in progress.
  • the sending of the digital marking code request is triggered upon detection that the first microphone is deactivated for at least a second duration.
  • the first audio data stream is generated by emulating random noise. It is thus possible, at least in certain embodiments, to carry out an audio test in a reliable and robust manner, independently of any audio data stream likely to be transmitted by the first client terminal during the conference in progress.
  • At least some of the steps a)-d) of the method implemented on the first client terminal can be reiterated during said communication session, so as to check several times (for example periodically) whether said at least one second client terminal is capable of receiving an audio data stream transmitted by the first client terminal. It is thus possible to check over a given period, repeatedly (periodically or regularly) or continuously, whether the second client terminal is capable of receiving an audio data stream sent by the first client terminal during the conference in progress.
  • the audio capability data received represents that said at least one second client terminal has detected the digital marking code in a stream of audio data received from the audio conferencing server
  • the information restored by the user interface indicate that said at least one second client terminal is capable of receiving an audio data stream emitted by the first client terminal. The user of the first client terminal can thus ensure that he is or will be heard during the conference in progress.
  • the first client terminal sends to the mediation server a notification informing of the sending of the marked data stream to the audio and/or video conference server. It is thus possible for the mediation server to be informed when an audio test is initiated by the first client terminal. From this notification, the mediation server can in particular determine whether it receives a notification from the second client terminal, indicating that the latter has detected the digital marking code.
  • said at least one management action comprises: if the received audio capability data represents that said at least one second client terminal has not detected the digital marking code in the mixed audio data stream received from the audioconference server, changing an audio configuration of the first client terminal.
  • the first client terminal can adapt its configuration when an audio stream reception problem is detected, and therefore improve the chances that the user of the first client terminal will be heard by the second client terminal when the conference.
  • the first method comprises, successively for each of a plurality of audio configurations, as long as a first audio condition is not satisfied: configuration of the first client terminal according to said audio configuration; and repeating at least some of steps a)-d).
  • the first method comprises, before sending the marked audio data stream to the audio and/or video conference server: activation of the first microphone of the first client terminal; deactivation of an echo cancellation function so as to allow acoustic acquisition by the first microphone of the first client terminal of an acoustic emission from a first loudspeaker coupled to said at least one first client terminal; generation of an acoustic test signal by means of the first loudspeaker; acoustic acquisition, by means of the first microphone, of the acoustic test signal emitted by the first loudspeaker; and determination, from a result of said acoustic acquisition, of acoustic capacity data characterizing the acoustic capacities of the first microphone; wherein the information returned in d) by the user interface is further representative of the acoustic capabilities of the first microphone of the first client terminal.
  • the first method further comprises: receiving, from the mediation server, acoustic capacity data representative of acoustic capacities of a second loudspeaker coupled to said at least one second client terminal to be produced an acoustic output; the information returned in d) by the user interface also being representative of the acoustic capacities of the second loudspeaker of the second client terminal.
  • the user of the first client terminal can thus be informed of the capacity of the acoustic processing chain of the first client terminal to produce an acoustic emission (output).
  • the invention also relates to a second method implemented by a second client terminal during a communication session in cooperation with an audio and/or video conference server. managing audio data stream exchanges between a first client terminal and the second client terminal during an audio and/or video conference.
  • the second method comprises: reception, from the audio and/or video conference server, of an audio data stream; and sending a notification comprising a code embedded in said received audio data stream, in association with an identifier of the second client terminal.
  • the second method further comprises, upon detection of said code in said received audio data stream: activation (C100) of a second microphone (MIC2) coupled to the second client terminal; deactivation (C102) of an echo cancellation function (F2) so as to allow acoustic acquisition by the second microphone of an acoustic emission from a second loudspeaker (HP2) coupled to said second client terminal; generation (C104) of an acoustic test signal (SA2) by means of the second loudspeaker; acoustic acquisition (C106), by means of the second microphone, of the acoustic test signal emitted by the second loudspeaker; determination (C108), from a result of said acoustic acquisition, of acoustic capacities (DTB2) of the second loudspeaker of the second client terminal to produce an acoustic emission; and sending to the mediation server (SV2) the acoustic capacities of the second loudspeaker.
  • the second method comprises: g) reception, from the audio and/or video conference server, of a stream of marked audio data; h) detection, in the marked audio stream, of a digital marking code embedded in the watermarked audio data stream; and i) sending, to a mediation server, a notification indicating the detection of the digital marking code, said notification comprising the digital marking code in association with an identifier of the second client terminal.
  • Sending said notification to the mediation server allows said server to generate audio capacity data indicating whether the second client terminal has detected the code integrated into the stream received.
  • the mediation server can in particular transmit this audio capacity data to the first client terminal in order to indicate to it whether or not the second client terminal is able to receive an audio stream emitted by the first client terminal during the conference.
  • the second method further comprises, in response to the detection h): activation of a second microphone coupled to the second client terminal; deactivation of an echo cancellation function so as to allow acoustic acquisition by the second microphone of an acoustic emission from a second loudspeaker coupled to said second client terminal; generation of an acoustic test signal by means of the second loudspeaker; acoustic acquisition, by means of the second microphone, of the test acoustic signal emitted by the second loudspeaker; determination, from a result of said acoustic acquisition, of the acoustic capacities of the second loudspeaker of the second client terminal to produce an acoustic emission; and sending to the mediation server the acoustic capacities of the second loudspeaker.
  • the invention also relates to a third method implemented by a system, comprising a first client terminal and a second client terminal respectively executing the first and second methods defined above, in at least some of their embodiments, and described in specific examples below.
  • the invention relates to a third method implemented by a client system, comprising a first client terminal and a second client terminal, during a communication session in cooperation with an audio and/or video conference server managing exchanges of audio data streams between the first client terminal and the second client terminal during an audio and/or video conference, in which the first terminal executes a first method as defined above; in which the second terminal executes a second method as defined above; the information returned in d) by the first client terminal indicating that the second client terminal is capable of receiving an audio data stream transmitted by the first client terminal.
  • the third method further comprises (for example in response to detection h), the following steps implemented by said second client terminal: activation of a second microphone coupled to the second client terminal; deactivation of an echo cancellation function so as to allow acoustic acquisition by the second microphone of an acoustic emission from a second loudspeaker coupled to said second client terminal; generation of an acoustic test signal by means of the second loudspeaker; acoustic acquisition, by means of the second microphone, of the test acoustic signal emitted by the second loudspeaker; determination, from a result of said acoustic acquisition, of the acoustic capacities of the second loudspeaker of the second client terminal to produce an acoustic output; and sending to the mediation server the acoustic capacities of the second loudspeaker; the method further comprising the following step implemented by the first client terminal: reception, from the mediation server, of acoustic capacity data representative of said acoustic capacities of the second louds
  • the invention also relates to a fourth method implemented by a mediation server in cooperation with a plurality of client terminals (comprising a first client terminal and a second client terminal) participating in an audio and/or video conference during which audio data streams are exchanged via an audio and/or video conference server.
  • a mediation server in cooperation with a plurality of client terminals (comprising a first client terminal and a second client terminal) participating in an audio and/or video conference during which audio data streams are exchanged via an audio and/or video conference server.
  • the fourth method comprises: sending to a first client terminal a code assigned to the first client terminal and registered, in association with an identifier (ID1) of the first client terminal; upon receipt, from a second client terminal, of a notification comprising the code assigned to said first client terminal in association with an identifier of the second client terminal; determining audio capability data indicating whether the second client terminal is capable of receiving an audio data stream from the first client terminal; and sending said audio capability data to the first client terminal.
  • ID1 an identifier
  • an absence of reception of said notification is determined if no said notification, indicating that the second client terminal (T2) has detected the code assigned to said first terminal, is received within a first period at count from a reference instant.
  • the fourth method comprises: j) sending to a first client terminal a digital marking code assigned to the first client terminal and recorded, in marking data of said mediation server, in association with an identifier of the first client terminal; k) determining, from the marking data, whether a notification indicating that a second client terminal has detected the digital marking code is received from said second client terminal, said notification comprising the digital marking code in association with a identifier of the second client terminal;
  • the mediation server is thus capable of supervising the audio test initiated by the first client terminal to assess whether the second client terminal is able to receive an audio data stream emitted by the first client terminal during the conference.
  • the mediation server determines that the second client terminal has not detected the digital marking code if said mediation server does not receive a notification to this effect from the second client terminal.
  • the mediation server executes steps j) to m) for a plurality of second client terminals, so as to send in m) to the first client terminal audio capacity data of each of the plurality of second client terminals.
  • the mediation server can thus supervise audio tests initiated by the first client terminal so as to assess whether a plurality of second client terminals participating in the conference are able to receive an audio data stream transmitted by the first client terminal.
  • the different steps of the first, second, third and fourth methods as defined above, and as described below in specific examples, are determined by computer program instructions.
  • the invention also relates to computer programs on information media (or recording media), these programs being able to be implemented in terminals or in servers, or more generally in computers, these programs comprising instructions adapted to the implementation respectively of the steps of the first, second, third and fourth methods.
  • each of the methods of the invention can be implemented by means of a non-volatile memory storing computer program instructions and a processor executing these instructions.
  • module may correspond in this document to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned.
  • Such a software component can be executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).
  • a hardware component can correspond to any element of a hardware assembly (or hardware) able to implement a function or a set of functions, according to what is described below for the module concerned. It can be a hardware component that can be programmed or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing firmware ( firmware), etc
  • the present invention also relates to a first client terminal (and respectively a second client terminal) configured to implement the first method (and respectively the second method) of the invention as defined above and described below in examples individuals.
  • the present invention also relates to a system comprising the first and second client terminals of the invention, configured to implement the third method of the invention.
  • the present invention also relates to a mediation server configured to implement the fourth method of the invention as defined above and described below in specific examples. It should be noted that the different embodiments mentioned above (as well as those described below) in relation to the different methods of the invention as well as the associated advantages apply in a similar way to the client terminals, system and server of mediation of the invention.
  • the associated device (or physical entity) of the invention may comprise a corresponding module configured to perform said step.
  • FIG. 1 schematically represents an environment comprising client terminals and a mediation server, according to a particular embodiment of the invention
  • Figure 2 schematically represents a first client terminal according to at least one embodiment of the invention
  • Figure 3 schematically represents a second client terminal according to at least one embodiment of the invention
  • FIG. 4 schematically represents a mediation server according to at least one embodiment of the invention
  • FIG. 5 represents, in the form of a diagram, the process steps implemented by client terminals and by a mediation server, according to certain embodiments of the invention
  • FIG. 6 represents, in the form of a diagram, the process steps implemented by client terminals and by a mediation server, according to certain embodiments of the invention
  • FIG. 7 represents, in the form of a diagram, the steps of a method implemented by a first client terminal, according to at least one embodiment of the invention
  • FIG. 8 represents, in the form of a diagram, the steps of a method implemented by a second client terminal, according to at least one embodiment of the invention.
  • audio conference also called audio conference
  • videoconference also called video conference
  • audio and/or video conferences involve the exchange of at least audio type data.
  • audio conferences involve exchanges of audio streams
  • video conferences involve exchanges of image streams and audio streams (video streams).
  • the invention proposes in particular to allow a user participating in an audio and/or video conference (also called more simply “conference”) to verify that he is or will be heard by at least one other given participant.
  • the invention uses, according to its various embodiments, a code, assigned to a first client terminal, such as a digital marking code, which is integrated into an audio data stream to determine whether at least one second terminal client is able to receive an audio data stream transmitted by the first client terminal.
  • a first client terminal can be configured to send a stream of tagged audio data to an audio and/or video conferencing server (also called “conference server”) managing audio data stream exchanges between the first client terminal and at least one second client terminal during an audio and/or video conference.
  • This marked audio data stream may comprise a code, such as a digital marking code, integrated for example by digital watermarking in an audio data stream.
  • the first client terminal may further receive, from a mediation server, audio capability data representative of whether said at least one second client terminal has detected the digital marking code in an audio data stream received from the audio and/or video conference. It is thus possible for the first client terminal to determine whether said at least one second client terminal is capable of receiving an audio data stream from the first client terminal.
  • the invention relates in particular to a second client terminal configured to process a stream of audio data marked as indicated above, a corresponding mediation server, as well as corresponding methods and computer program.
  • first(s) (or first(s)), “second(s)”, etc. are used in this document by arbitrary convention to identify and distinguish different elements (such as terminals, process) implemented in the embodiments described below.
  • FIG. 1 schematically represents, by way of non-limiting example, an environment comprising a first client terminal T1, a second client terminal T2, an audio and/or video conference server SV1 and a mediation server SV2 (also called control).
  • client terminals T1 and T2 are used respectively by users UR1 and UR2 to communicate by audio during an audio and/or video conference.
  • the conference server SV1 manages exchanges of audio data streams FX between the client terminals participating in the conference.
  • the number and the nature of the client terminals participating in the communication session during the conference may vary depending on the case.
  • the number of second client terminals within the meaning of the invention, of which the first client terminal T1 tests the audio reception can vary depending on the case.
  • second client terminals T3 and T4 can also cooperate with the conference server SV1 and with the mediation server SV2, although implementations of the invention are also possible with only two client terminals, namely the first client terminal T1 and the second client terminal T2 in this example.
  • the principle of the invention is described below in specific examples mainly involving the terminal T1 as the first client terminal and the terminal T2 as the second client terminal within the meaning of the invention.
  • the invention can however be applied analogously to a plurality of second client terminals (T2, T3 and/or T4 for example) operating as second terminals within the meaning of the invention.
  • each of the client terminals T1-T4 can also be configured to act both as a first terminal and as a second terminal within the meaning of the invention.
  • the client terminals are each capable of cooperating with the conference server SV1 via any communication network, such as the Internet, or an Intranet network or any other appropriate network.
  • the T1-T4 client terminals can be computers (PCs, laptops, etc.), tablets, smart phones or "smartphones", or any other type of terminal capable of exchanging audio data streams during an audio conference. and/or video with at least one other participant.
  • the conference server SV1 is configured to manage audio communications during a communication session established with the client terminals T1-T4 during an audio and/or video conference. To do this, the conference server SV1 is able to establish the communication session with each of the client terminals, then to receive the audio data streams FX transmitted or generated by the client terminals T1-T4. The conference server SV1 then processes these audio data streams in order to redistribute them to the other participants. More particularly, the conference server SV1 can for example decode the audio data streams FX received according to appropriate codecs (those used by the corresponding client terminals), carry out a mixing of these audio data and generate a stream of audio data mixed by a re-encoding of the mixed audio data. This mixed audio data stream can then be sent to the various client terminals so that their users can hear all the audio communications exchanged by the participants.
  • the client terminals T1-T4 can also be capable of cooperating with the mediation server SV2 through any appropriate communication network.
  • the mediation server SV2 can be configured for example to evaluate the audio capacities of at least some of the client terminals and to transmit to at least some of the client terminals audio capacity data DTA representative of capacities audio from at least some of the client terminals T1-T4.
  • the mediation server SV2 can transmit to at least some of the client terminals (for example to each) a code WT, such as a digital marking code, which is assigned to it.
  • a code WT such as a digital marking code
  • the mediation server SV2 can send digital marking codes WT 1 and WT2 to the client terminals T 1 and T2, respectively. As described later, these digital marking codes can be used subsequently to test the ability of client terminals to receive an audio data stream emitted by, in particular, the first client terminal T1 in this example.
  • the mediation server SV2 can also send to client terminals acoustic capacity data DTB (FIG. 1) representative of the acoustic capacities of client terminals, as described later.
  • DTB acoustic capacity data representative of the acoustic capacities of client terminals
  • the client terminal T 1 comprises a processor 2, a volatile memory (RAM) 4, a non-volatile memory 6, a communication interface INT 1 , a user interface IU1 and a non-volatile memory. volatile rewritable MR1.
  • the memory 6 is for example a rewritable non-volatile memory or a read only memory (ROM), this memory constituting a recording medium (or information medium) in accordance with a particular embodiment, readable by the client terminal T1, and on which is recorded a first computer program PG1 conforming to a particular embodiment.
  • This computer program PG1 includes instructions for the execution of the steps of a first method (also called first management method) according to a particular embodiment, as described in more detail later.
  • the client terminal T1 is able to use its communication interface INT1 to communicate with the conference server SV1 and with the mediation server SV2.
  • the nature of this interface depends on the type of communication network used.
  • the rewritable non-volatile memory MR1 (for example of the flash or EEPROM type) is capable of storing an identifier ID1 of the client terminal T1, a code, such as a digital marking code, WT 1 and audio capacity data DTA. If necessary, the memory MR1 can also be used to store acoustic capacity data DTB.
  • a first loudspeaker HP1 and a first microphone MIC1 are coupled to the first client terminal T 1 so that the user UR1 can hear and transmit audio communications during an audio conference and/or or video.
  • Variant embodiments without at least one of the loudspeaker HP1 and the microphone MIC1 are however possible.
  • the loudspeaker HP1 enables the generation of sounds (known as acoustic signals) from audio data while the microphone MIC1 enables the generation of audio data by acoustic acquisition of sounds (or acoustic signals).
  • the loudspeaker HP1 and the microphone MIC1 constitute audio means which can be used by the processor 2 by means of an audio card and/or any other hardware and/or software means which are configured according to a particular audio configuration.
  • the loudspeaker HP1 can be configured to emit in particular an acoustic test signal denoted SA1 which the microphone MIC1 can acquire acoustically.
  • the processor 2 uses, for example, the volatile memory 4 to control the various components (memories, communication interface, etc.) and to carry out the various operations and functions necessary for the operation of the client terminal T1, including for executing the program of computer PG1 during the implementation of the first method of the invention.
  • the second client terminal T2 has a structure identical to that of the first terminal T1, so that these two terminals can be used interchangeably to execute the first and second processes within the meaning of the invention.
  • the second client terminal T2 comprises a processor 10, a volatile memory (RAM) 12, a non-volatile memory 14, a communication interface INT2, a user interface IU2 and a rewritable non-volatile memory MR2 .
  • the memory 12 is for example a rewritable non-volatile memory or a read-only memory (ROM), this memory constituting a recording medium (or information medium) in accordance with a particular embodiment, readable by the client terminal T2, and on which is recorded a second computer program PG2 conforming to a particular embodiment.
  • This computer program PG2 includes instructions for the execution of the steps of a second method (also called second management method) according to a particular embodiment, as described in more detail later.
  • the client terminal T2 is able to use its communication interface INT2 to communicate with the conference server SV1 and with the mediation server SV2. As already indicated, the nature of this interface depends on the type of communication network used.
  • the rewritable non-volatile memory MR2 (for example of the flash or EEPROM type) is able to store an identifier ID2 of the client terminal T2, a digital marking code WT2 and audio capacity data DTA. If necessary, the MR2 memory can also be used to store acoustic capacity data DTB.
  • a second loudspeaker HP2 and a second microphone MIC2 are coupled to the second client terminal T2 so that the user UR2 can hear and transmit audio communications during an audio conference and/or video.
  • Variant embodiments without at least one of the loudspeaker HP2 and the microphone MIC2 are however possible.
  • the loudspeaker HP2 allows the generation of acoustic signals from audio data while the microphone MIC2 allows the generation of audio data by the acoustic acquisition of acoustic signals.
  • the loudspeaker HP2 and the microphone MIC2 constitute audio means which can be used by the processor 10 by means of an audio card and/or any other hardware and/or software means which are configured according to a particular audio configuration.
  • the loudspeaker HP2 can be configured to emit in particular an acoustic test signal denoted SA2 which the microphone MIC2 can acquire acoustically.
  • the processor 10 uses, for example, the volatile memory 12 to control the various components (memories, communication interface, etc.) and to carry out the various operations and functions necessary for the operation of the client terminal T2, including for executing the program of computer PG2 during the implementation of the second method of the invention.
  • the first client terminal T1 and the second client terminal T2 together form a client system SY1, the latter possibly also comprising one or more client terminals, such as the terminals T3 and/or T4 for example.
  • the client system SY1 is configured to implement a third method within the meaning of the invention by executing the instructions of the computer programs PG1 and PG2 by the client terminals T1 and T2.
  • the mediation server SV2 comprises a processor 20, a volatile memory (RAM) 22, a non-volatile memory 24, a communication interface INT3 and a rewritable non-volatile memory MR3.
  • the memory 24 is for example a rewritable non-volatile memory or a read only memory (ROM), this memory constituting a recording medium (or information medium) in accordance with a particular embodiment, readable by the mediation server SV2, and on which is recorded a third computer program PG3 conforming to a particular embodiment.
  • This computer program PG3 comprises instructions for the execution of the steps of a fourth method according to a particular embodiment, as described in more detail later.
  • the mediation server SV2 is able to use its communication interface INT3 to communicate with the client terminals T 1 and T2. As already indicated, the nature of this interface depends on the type of communication network used. In this example, the mediation server SV2 is also able to communicate by means of its communication interface INT3 with the client terminals T3 and/or T4, although implementations without these additional client terminals are possible as already indicated.
  • the rewritable non-volatile memory MR3 (for example of the flash or EEPROM type) is able to store marking data DM and audio capacity data DTA.
  • the marking data DM comprises at least one digital marking code WT in association with an identifier ID of a respective client terminal to which said digital marking code WT has been assigned.
  • the marking data DM can thus comprise a plurality of pairs (ID, WT), a distinct digital marking code WT being assigned to each client terminal.
  • the processor 20 uses, for example, the volatile memory 22 to control the various components (memories, communication interface, etc.) and to perform the various operations and functions necessary for the operation of the mediation server SV2, including to execute the program for computer PG3 during the implementation of the fourth method of the invention.
  • the processor 2 controlled by the computer program PG1 here implements a certain number of modules in the first client terminal T1, namely: a module for obtaining MD2, a MD4 sending module, an MD6 receiving module, an MD8 control module, and possibly also an MD10 acoustic test module.
  • the obtaining module MD2 is configured to obtain an audio data stream FX1 marked by integrating a digital marking code WT1 into a first audio data stream by digital watermarking. As described below, this audio data stream marked FX1 can be obtained in various ways by the first client terminal T1.
  • the MD4 sending module is configured to send the audio data stream marked FX1 to the audio and/or video conference server SV1.
  • the reception module MD6 is configured to receive, from the mediation server SV1, audio capacity data DTA representative of whether said at least one second client terminal T2 has detected the digital marking code WT 1 in an audio data stream FX received from audio and/or video conferencing server SV1.
  • the MD8 control module is configured to trigger at least one audio and/or video conference management action based on the DTA audio capability data received.
  • the action(s) performed can be of various types and can be adapted as appropriate.
  • Said at least one management action may comprise, for example, the restitution, by the user interface IU1 of the first client terminal T1, of information which is a function of the DTA audio capacity data received and which indicates whether said at least one second client terminal T2 is able to receive an audio data stream FX from the first client terminal T 1.
  • the acoustic test module MD10 can also be configured to carry out an acoustic test of the audio equipment of the first client terminal T1, in particular to carry out an acoustic test of the microphone MIC1 and/or of the loudspeaker HP1.
  • the processor 10 controlled by the computer program PG2 here implements a certain number of modules in the second client terminal T2, namely: a reception module MD20, a module detection module MD22, a sending module MD24, and possibly also an acoustic test module MD26.
  • the reception module MD20 is configured to receive, from the audio and/or video conference server, a stream of marked audio data denoted FX2.
  • the detection module MD22 is configured to detect, in the audio stream marked FX2, a digital marking code WT (WT 1 for example), the latter being integrated into the audio data stream FX2 by digital watermarking.
  • WT 1 digital marking code
  • the sending module MD24 is configured to send, to the mediation server SV2, a notification indicating the detection of the digital marking code WT (WT1 for example), said notification comprising the digital marking code in association with the identifier ID2 of the second client terminal T2.
  • the acoustic test module MD26 can also be configured to carry out an acoustic test of the audio equipment of the second client terminal T2, in particular to carry out an acoustic test of the microphone MIC2 and/or of the loudspeaker HP2.
  • the processor 20 controlled by the computer program PG3 here implements a certain number of modules in the mediation server SV2, namely: a sending module MD40, a first determination module MD42, a second determination module MD44 and a sending module MD46.
  • the sending module MD40 is configured to send to the first client terminal T1 a digital marking code WT1 assigned to the first client terminal T1 and to record, in marking data DM of the mediation server SV2, in association with the identifier ID1 of the first client terminal T1.
  • the marking data DM is stored in the non-volatile memory MR3.
  • the first determination module MD42 is configured to determine, from the recorded marking data DM, whether a notification indicating that the second client terminal T2 has detected the marking code W1 is received from the second client terminal T2, this notification comprising the digital marking code W1 in association with the identifier ID2 of the second client terminal T2.
  • the second determination module MD44 is configured to determine, from a result of the determination carried out by the first determination module MD42, audio capacity data DTA2 indicating whether the second client terminal T2 is able to receive a data stream audio FX coming from the first client terminal T 1.
  • the sending module MD46 is configured to send to the first client terminal T1 the audio capacity data DTA2 determined by the second determination module MD44.
  • the sending module MD46 is also configured to send to the first client terminal T1 acoustic capacity data DTB2 of the second audio terminal T2, these acoustic capacity data DTB2 being able to characterize the acoustic equipment of the second client terminal T2, and in particular its microphone MIC2 and/or its loudspeaker HP2.
  • first client terminal T1 and the second client terminal T2 as previously described with reference to Figures 1-3 respectively implement a first method and a second method by executing the computer programs PG1 and PG2. These first and second methods collectively form a third method implemented by the system SY 1 represented in FIG. 1.
  • the mediation server SV2 as previously described with reference to FIGS. 1 and 4 implements a fourth method by executing the PG3 computer program.
  • the users UR1 and UR2 respectively use the client terminals T1 and T2 to communicate together, at least by audio, during an audio and/or video conference. To do this, it is considered that a communication session is established by the client terminals T1 and T2 in cooperation with the audio and/or video conference server SV1 which manages the audio data streams FX between the first client terminal T1 and the second client terminal T2 during an audio and/or video conference.
  • the mediation server SV2 sends a digital marking code WT1 which is received by the first client terminal T1 at B2.
  • This digital marking code WT 1 which can take various forms, is assigned to the first client terminal T1.
  • This digital marking code WT1 is a code (or marker) which can be integrated by digital watermarking (also called “watermarking”) in an audio data stream.
  • the first terminal T 1 obtains an audio data stream FX1, these audio data being marked by integration of the digital marking code (also called "mark”) WT1 in an audio data stream , for example by watermarking.
  • the digital watermarking technique makes it possible to insert marking information into host data, in this case audio data, so that this marking information is not perceptible (audible) for a user, for example.
  • bits of the digital marking code are encoded into the audio data stream which serves as the carrier signal.
  • the first client terminal T 1 determines or generates (B4) the marked audio data stream FX1 from the digital marking code WT1 received at B2, by integrating the digital marking code WT 1 by digital watermarking into a first watermarking audio data stream.
  • the first client terminal T1 obtains in B4 the stream of audio data marked FX1 in another way.
  • the first client terminal T1 does not receive the digital marking code WT1 from the mediation server DV2 but obtains this code in B2 in another way, for example by consulting its memory MR1 in which said code is prerecorded WT 1 .
  • the first client terminal T 1 can then insert the digital marking code WT1, for example by digital watermarking, into an audio data stream FX to obtain the audio data stream marked FX1.
  • the audio data stream marked FX1 is pre-recorded in a memory (for example MR1) of the first client terminal T1 and the latter consults its memory to obtain in B4 the audio data stream marked FX1, so that the step B2 of reception is not necessary either.
  • a memory for example MR1
  • the mediation server SV2 records in its memory (here the memory MR2), during a step D3 d recording (FIG. 5), marking data DM associating the identifier ID1 of the first client terminal T1 with the digital marking code WT1 assigned to said first client terminal T 1 .
  • the first client terminal T1 sends the audio data stream marked FX1 to the conference server SV2.
  • the conference server SV2 receives the audio data stream marked FX1 during a reception step A6.
  • the conference server SV1 then sends (step A8, FIG. 5) to the second client terminal T2 a second audio data stream marked FX2 comprising the digital marking code WT1 integrated for example by digital watermarking.
  • the conference server SV1 determines beforehand the stream of audio data marked FX2 from a processing of the stream of audio data marked FX1 received at A6.
  • the audio data stream marked FX2 comprises the audio data stream marked FX1.
  • the audio data stream marked FX2 can be a mixed audio data stream generated by the conference server SV1 by mixing (or combining) the audio data stream marked FX1 received at A6 with at least one other audio data stream transmitted by another client terminal, for example by the second client terminal T2.
  • the SV2 mediation server can thus mix the audio streams coming from the different client terminals when users speak or emit sounds so as to redistribute audio streams to all participants.
  • the conference server SV1 decodes (from codecs) each audio data stream that it receives from the client terminals (including the audio data stream marked FX1), then mixes the audio data thus decoded to generate a stream of mixed audio data which are marked since they incorporate the digital marking code WT 1.
  • the conference server SV1 then generates (from codes) the stream of marked audio data FX2 by re-encoding this mixed audio data.
  • the second client terminal T2 receives, during a reception step C8, the audio data stream marked FX2 coming from the conference server SV1.
  • the second client terminal T2 detects the digital marking code WT1 integrated into the marked audio data stream FX2, for example by digital watermarking. To do this, the second client terminal T2 analyzes the incoming audio data stream and checks whether this stream contains a digital marking code (or a mark). It is assumed in this example that the second client terminal T2 is capable of recognizing a digital marking code WT but does not know the client terminal associated with each digital marking code WT (although other examples are possible).
  • the second client terminal T2 it is not necessary for the second client terminal T2 to restore the audio data stream marked FX2 in acoustic form by means in this example of the loudspeaker HP2, although this is possible.
  • the sound reproduction of the FX2 audio stream can however be useful when at least one of the participants in the audio and/or video conference is emitting sounds.
  • the second client terminal T2 sends to the mediation server SV2 a notification NF1 indicating the detection of the digital marking code WT1, this notification NF1 comprising the digital marking code WT1 in association with the identifier ID2 of the second client terminal T1.
  • the mediation server SV2 receives the notification NF1 during a reception step D12 (FIG. 5).
  • the mediation server SV2 determines, from the marking data DM recorded in its memory MR3, whether a notification NF1 - indicating that the second client terminal T2 has detected the digital marking code WT1 - Is received from the second client terminal T2, this notification NF1 comprising the digital marking code WT1 in association with the identifier ID2 of the second client terminal T2.
  • the execution of the fourth method by the mediation server SV2 may vary at this stage depending on the result of the determination step D14.
  • the result of this step D14 can be positive (the mediation server SV2 detects the notification NF1) or negative (the mediation server SV2 does not detect the notification NF1).
  • the mediation server SV2 receives from the second client terminal T2 a notification indicating the detection of a digital marking code, it consults its marking data DM to determine whether this notification includes the digital marking code WT1 associated with identifier ID1 in its DM tagging data. If so, the mediation server SV2 determines that the second terminal client T2, identified by the identifier ID2 included in the notification NF1 received, has detected the digital marking code WT1 associated with the first client terminal T1.
  • the mediation server SV2 determines in D14 an absence of reception of the notification NF1 in D12 if no said notification, indicating that the second client terminal T2 has detected the digital marking code WT1, is received in a first delay DL1 from a reference instant tO.
  • the first delay DL1 expires without the notification NF1 having been received by the mediation server SV2, the latter detects that no notification NF1 indicating that the second client terminal T2 has detected the digital marking code WT1 n has been received.
  • this reference instant may vary depending on the case, and may correspond for example to an instant during which the sending D2 is carried out.
  • the mediation server SV2 determines, from a result of the determination D14, audio capacity data DTA2 indicating whether the second client terminal T2 is able to receive a data stream audio FX from the first client terminal T1.
  • the audio capacity data DTA2 characterizes the capacity of the second client terminal T2 to receive an audio data stream FX transmitted by the first client terminal T1 during the audio and/or video conference.
  • the detection by the second client terminal T2 of the digital marking code WT1 indicates that the second client terminal T2 has been able to receive the audio data stream marked FX2 comprising the audio data stream marked FX1 emitted at B6 by the first client terminal T 1 .
  • the audio capacity data DTA2 generated in D16 consequently indicate that the second client terminal T2 is able to receive an audio data stream transmitted by the first client terminal T 1 .
  • the second client terminal T2 has not detected the digital marking code WT2, this means that it has not been able to receive the audio data stream marked FX2 transmitted by the conference server SV1.
  • a negative result of the determination D14 means that the test of reception of an audio stream from the first client terminal T1 to the second client terminal T2 has failed.
  • the audio capacity data DTA2 generated at D16 by the mediation SV2 indicate that the second client terminal T2 is not able to receive an audio data stream from the first client terminal T 1.
  • the mediation server SV2 can optionally update previous audio capacity data DTA2 already stored in its memory MR3.
  • the mediation server SV2 then sends to the first client terminal T1 the audio capacity data DTA2 determined in D16.
  • the mediation server SV2 also sends (D18) to the first client terminal T1 acoustic capacity data DTB representative of acoustic capacities of the second loudspeaker HP2 coupled to the second client terminal T2 to produce a transmission (or output) acoustic.
  • acoustic capacity data DTB can be obtained in various ways by the mediation server SV2, specific embodiments being described below.
  • the first client terminal T 1 receives the audio capacity data DTA2, and if necessary the acoustic capacity data DTB2, during a reception step B20.
  • the data received may optionally be associated with the identifier ID2 of the second client terminal T2 to allow the first client terminal T 1 to determine that it is data characterizing the second client terminal T2.
  • the first client terminal T 1 then triggers, based on the DTA2 capacity data (and possibly the DTB2 acoustic capacity data) received, at least one action for managing the audio conference and/or current video.
  • the management action(s) executed by the first client terminal T1 may vary depending on the case and consist in adapting the operation of the first client terminal T1 according to the ability or non-ability of the second client terminal T2 to receive a data stream audio emitted by the first client terminal T1 (and possibly the ability to reproduce the corresponding sounds) during the audio and/or video conference.
  • the first client terminal T1 restores (or renders), by means of its user interface IU1, information IF1 which is a function of the audio capacity data DTA2 received (and also possibly acoustic capacity data DTB2 received), this information IF1 indicating whether the second client terminal T2 is capable of receiving an audio data stream FX (and possibly whether it is capable of restoring the corresponding sounds).
  • This restitution which can take various forms (visual, auditory, etc.) can help, at least in certain embodiments, the user UR1 to determine whether he is, or will be, heard correctly when he speaks or emits sounds during the audio and/or video conference.
  • the first client terminal T1 modifies at least one operating parameter or an audio configuration according to which it operates to exchange audio data streams in cooperation with the conference server SV1 at the course of the conference.
  • the first client terminal T1 switches from the audio and/or video conference in progress to a second audio and/or video conference (backup or replacement conference) in which also cooperate at least the terminals T1 and T2 to exchange audio streams.
  • the first terminal T1 can for example cooperate with at least the second client terminal T2 in several conferences simultaneously, or even in several successive conferences over a given period.
  • a switch to a new conference can allow the first client terminal T1 to resolve an audio reception problem identified from the data DTA2 (and possibly DTB2) received at B20 (FIG. 5).
  • the conference server SV1 can send the mixed audio data stream FX2 to a plurality of second client terminals, for example to T2, T3 and T4.
  • the client terminals T3 and T4 can process the audio data stream marked FX2 by executing the steps C8-C12 in the same way as the second client terminal T2.
  • the mediation server SV2 can then execute for example steps D12, D14 and D16 for at least one (for example each) of the second client terminals T2-T4 so as to generate in D16 audio capacity data DTA2, DTA3 and/or DTA4 respectively indicating whether said second client terminal has detected the code digital marking WT1 in an audio data stream received from the audio and/or video conference server SV1.
  • the mediation server SV2 can thus send in D18, to the first client terminal T1, the audio capacity data DTA2, DTA3 and/or DTA4 (as well as possibly acoustic capacity data DTB2, DTB3 and DTB4 associated respectively with the terminals T2, T3 and T4).
  • the management action or actions executed in B22 by the first client terminal T1 can be a function of the various data received.
  • the invention involves the sending by a first client terminal of an audio data stream incorporating a digital marking code.
  • a second third-party terminal can only detect the marking code if it has the capacity to receive and correctly process the audio data stream coming from the first client terminal. If the second client terminal detects the digital marking code, it then informs the mediation server SV2 thereof, which updates its audio capacity data, so that they indicate that the second client terminal is capable of receiving the audio data streams sent by the first terminal.
  • the digital marking technique may involve the use of an audio data stream to carry the digital marking code.
  • This code which may be inaudible to a user of the second client terminal, is used to mark the audio data stream reliably and securely to verify that the transmission of the audio stream from the first client terminal to the second client terminal is operational.
  • the conference server SV1 is for example in charge of managing the audio data stream exchanges between the first client terminal T1 and the second client terminals T2-T4.
  • the conference server SV1 can be configured to process all the audio data streams transmitted by the client terminals so as to produce a mixed audio data stream FX2 which is distributed to all of the client terminals (or at least to second customer terminal T2).
  • the processing carried out by the conference server SV1 can in particular comprise a decoding of the audio data streams FX received (including the stream FX1) and a mixing of these streams so as to produce a stream of mixed audio data which is re-encoded before sending to client terminals.
  • the technique of marking by digital watermarking can offer, at least in certain embodiments, good robustness insofar as the digital marking code WT1 present in the audio data stream marked FX1 received (A6, FIG. 5) coming from the first client terminal T 1 inherently resists the various processing operations of decoding, mixing, encoding, etc. made by the mediation server SV1.
  • the mixed audio data stream FX2 sent at A8 to the second client terminal T2 comprises the same digital marking code WT 1 as that present in the marked audio data stream FX1 received at A6 from the first client terminal T 1.
  • the first client terminal T1 and the second client terminal T2 respectively execute the computer programs PG1 and PG2 to implement a first method and a second method.
  • these first and second methods collectively form a third method implemented by the system SY1 represented in FIG. 1.
  • the mediation server SV2 (FIGS. 1 and 4) implements a fourth method by executing the program computer PG3.
  • the users UR1 and UR2 respectively using the client terminals T1 and T2 wish to communicate together, at least by audio, during an audio and/or video conference.
  • the client terminals T1 and T2 each establish a communication session in cooperation with the conference server SV1 managing exchanges of audio data streams between the first client terminal T1 and the second client terminal T2.
  • the first client terminal T 1 tests the audio reception of a single second client terminal T2, although other examples are possible where the audio reception of at least two second client terminals T2 is tested.
  • each second client terminal executes the second method in the same way as the second client terminal T2.
  • a unique identifier ID is assigned to each client terminal participating in the audio and/or video conference.
  • the first and second client terminals respectively obtain their respective identifiers ID1 and ID2.
  • the manner in which these terminals obtain their unique identifier may vary depending on the case. According to a particular example, it is the conference server SV1 which transmits to the client terminals T1 and T2 their respective identifier. According to another example, it is the users UR1 and UR2 who respectively define the identifiers ID1 and ID2 (or these are defined by default by their client terminal).
  • the first client terminal T1 can obtain (B4, FIG. 5) the audio data stream marked FX1 in various ways depending on the implementation considered.
  • the first client terminal T1 sends (B42, FIG. 6) to the mediation server SV2 a digital marking code request RQ1 (or code request request), this request RQ1 comprising the identifier ID1 of the first client terminal T1.
  • the mediation server SV2 receives this request RQ1 during a reception step D42.
  • the mediation server SV2 then obtains (D44) a digital marking code WT1 assigned to the first client terminal T1. To do this, the mediation server SV2 can determine or generate the digital marking code WT 1 in any suitable way. This marking code WT 1 can take various forms and can for example be a series of bits. The mediation server SV2 then sends (D46) the digital marking code WT 1 to the first client terminal T 1. In response to the request RQ1, the first client terminal T1 thus receives at B46 the digital marking code WT 1 assigned to it. According to a particular example, a distinct digital marking code WT is assigned by the mediation server SV2 to each second client terminal T2-T4.
  • the mediation server SV2 records, in marking data DM, the digital marking code WT1 in association with the identifier ID1 of the first client terminal T1. It should be noted that this recording step D48 can be carried out at various times, for example before or after the sending step D46, or even before the step D4 of receiving the request RQ1 (in the latter case, the server mediator SV2 defined the ID1/WT 1 association before receiving the RQ1 request).
  • the first client terminal T1 determines, during the establishment S2 of the communication session (or at least before the sending B42 of the request RQ1), an identifier IDC of the audio conference.
  • the first client terminal T1 can then insert into the request RQ1 this identifier IDC of the audio and/or video conference before sending B42 to the mediation server SV2, so as to allow, for example, the mediation server SV2 to record the code digital marking WT 1 in association with the identifier ID1 of the first client terminal T 1 and the identifier IDC of the audio and/or video conference.
  • the conference identifier IDC allows the mediation server SV2 to recognize the requests associated with the audio and/or video conference in progress, to generate a unique digital marking code WT for at least one client terminal (or even for each of among themselves) participating in said conference.
  • the mediation server SV2 can for example supervise the audio stream reception test for a plurality of distinct audio and/or video conferences, including when the first client terminal T1 participates in several conferences simultaneously or successively over a given period. .
  • the mediation server SV2 performs steps D44, D46 and D48 without this being requested by the first client terminal T1, that is to say independently of any request RQ1 sent by the first client terminal T 1.
  • the first client terminal T1 can obtain the audio data stream marked FX1 in various ways.
  • the first client terminal T1 generates or determines (B50) a stream of audio data marked FX1 by integrating (or inserting) by digital watermarking the digital marking code WT 1 into a first stream of audio data FXO which serves as the carrier stream.
  • This first audio data stream FXO can be a test audio data stream, that is to say a stream whose audio data is intended solely to test the audio reception of the second client terminal T2 and which is not intended to be returned by the second client terminal T2 to its user UR2.
  • the first client terminal T 1 generates the first audio data stream FXO by emulating random noise. In this example, this emulation can be performed while the microphone MIC1 of the first client terminal T 1 is deactivated. It is thus possible to produce a carrier signal for the digital marking code WT 1 , even if no acoustic signal is acquired by the microphone MIC1 (for example when a mute or “mute” function is activated).
  • the first client terminal T 1 generates the first audio data stream FXO from useful audio data, that is to say from audio data transmitted by the first client terminal T1 during the conference audio and/or video and intended to be returned by the second client terminal T2 to the user UR2.
  • the first audio data stream FXO can for example be generated from acoustic signals (or sounds) acquired by the first microphone MIC1 coupled to the first client terminal T1.
  • This variant makes it possible to test the audio reception of the second client terminal T2 while the first client terminal T1 is picking up sounds (for example while the user UR1 is speaking during the audio and/or video conference ).
  • the acoustic signals from which the first audio data stream FXO is generated represent (or result from) background noise acquired by the first microphone MIC1, the intensity of this background noise being less than a first intensity value 11.
  • the audio data stream marked FX1 can then be generated at B50 from this background noise, for example when the user UR1 of the first client terminal T1 is not speaking.
  • This value 11 can be adapted by those skilled in the art as appropriate.
  • the first client terminal T1 triggers the sending B40 of the digital marking code request RQ1 on detection, by means of its microphone MIC1, of a period of silence of a duration at least equal to a first duration D1, during which a background noise of an intensity lower than said first intensity value I1 is detected.
  • a period of silence is for example detected when a mute function (called “mute”) is activated, this function having the effect of deactivating the microphone MIC1 (blocking of acoustic acquisition).
  • mute mute function
  • This variant can help save processing and network resources by performing an audio reception test only to predict the ability or inability of the second client terminal T2 to receive an audio data stream even before the first client terminal T1 n transmit an audio data stream.
  • the first client terminal T1 then sends the audio data stream marked FX1 to the conference server SV1.
  • this sending B52 causes the conference server SV1 to send, to the second client terminal T2, a stream of audio data marked FX2 comprising the stream of audio data marked FX1.
  • the conference server SV1 receives the audio data stream marked FX1 during a reception step A52.
  • the first client terminal T1 also sends in B53 a notification NF2 informing of the sending B52 of the audio data stream marked FX1 to the conference server SV1 to carry out an audio test.
  • This notification NF2 which may include the identifier ID1 of the first client terminal T1
  • the reception D53 of the notification NF2 can mark, if necessary, a reference instant t0 subsequently used by the mediation server SV2 during the fourth method.
  • the conference server SV1 then carries out processing (A54) from the audio data stream marked FX1 received at A52, and possibly from at least one other audio data stream FX transmitted by a client terminal other than the first client terminal T1, so as to produce a stream of audio data marked FX2 comprising the digital marking code WT1.
  • the conference server SV1 decodes each audio data stream received (including the stream FX1), mixes or combines the decoded audio data and encodes the mixed audio data so as to obtain an audio data stream marked FX2 including the numeric marking code WT1.
  • the mediation server SV1 sends the audio data stream marked FX2 to the second client terminal T2.
  • the second client terminal T2 receives the audio data stream marked FX2 at C56 and detects in this stream FX2 the digital marking code WT1 at C58, identically respectively to the steps C8 and C10 previously described (FIG. 5).
  • the second client terminal T2 can reproduce the audio data stream marked FX2 in acoustic form by means in this example of the loudspeaker HP2, although variants are possible without such sound reproduction. If the second client terminal T2 generates acoustic signals from the audio stream FX2, then the digital marking code WT2 may not be perceptible for the user UR2 (the WT2 code is not converted into sound), so that it does not interfere with listening during the conference.
  • the second client terminal T2 sends (identically to sending C12, FIG. 5) a notification NF1 indicating that the second client terminal T2 has detected the digital marking code WT1, this notification NF1 comprising the digital marking code WT1 in association with the identifier ID2 of the second client terminal T2.
  • the mediation server SV2 receives the notification NF1 during a reception step D62.
  • the mediation server SV2 determines (D64) whether it has received a notification NF1 indicating that the second client terminal T2 has detected the digital marking code WT1. As already described, the mediation server SV2 can for this purpose consult its marking data DM and determine in D64 if the notification NF1 received includes the digital marking code WT1 associated with the identifier ID1 of the first client terminal T1 in the data of DM marking. The second client terminal T2 therefore does not need to know which other client terminal is associated with the digital marking code WT1.
  • the mediation server SV2 uses a reference time t0 to determine at D64 whether said notification NF1 is received within a first time period DL1 from this reference time t0.
  • This reference instant tO can, for example, correspond to the reception D53 of the notification NF2 sent, if necessary, by the first client terminal T1 to warn that an audio test is being carried out. It is thus possible for the mediation server SV2 to be informed when (for example each time) that the first client terminal T1 performs an audio test. Multiple audio tests can thus be carried out over time by the first client terminal T1 to test whether the user UR1 is, or will be, of course heard by the second client terminal T2.
  • the mediation server SV2 is configured to know in advance a reference instant t0 during which the first client terminal T1 carries out the sending B52 of the audio data stream marked FX1. According to a variant, the mediation server SV2 uses as reference time t0 a time during which any one of the steps D42, D44, D46 and D48 is performed.
  • the mediation server SV2 thus determines that the result of the determination D64 is positive if it detects that the notification NF1 emitted by the second client terminal T2 is received before the expiry of a first delay DL1 from this reference instant t0. Otherwise, the mediation server SV2 determines that the result of the determination D64 is negative.
  • the mediation server SV2 can then determine (D66), from a result of the determination D64, audio capacity data DTA2 indicating whether the second client terminal T2 is capable of receiving an audio data stream FX originating from the first client terminal T1. More specifically, if the result of the determination D64 is positive, the fourth method continues at step D66a, otherwise the fourth method continues at step D66b.
  • step D66a the mediation server SV2 determines, from the positive result of the determination D64, audio capacity data DTA2 indicating that the second client terminal T2 is able to receive an audio data stream coming from the first customer terminal T 1.
  • step D66b the mediation server SV2 determines, from the negative result of the determination D64, audio capacity data DTA2 indicating that the second client terminal T2 is not able to receive an audio data stream in from the first client terminal T 1.
  • the mediation server SV2 then sends (D68) the audio capacity data DTA2 to the first client terminal T1 as already described with reference to step D18 (FIG. 5).
  • the first client terminal T 1 thus receives at B68 the audio capacity data DTA2 sent by the mediation server SV2.
  • the first client terminal T1 can then perform steps D22 and D24 identically to steps B20 and B22 as previously described with reference to Figure 5.
  • the mediation server SV2 can also send (D70) the audio capacity data DTA2 to the second terminal T2 to indicate to it that its audio reception test from the client terminal T1 to the second client terminal T2 has failed.
  • the second client terminal T2 then receives the audio capability data DTA2 during a reception step C70.
  • the second client terminal T2 can thus perform at least one management action, such as for example restoring (C72a) by means of its user interface IU2 information IF2 indicating the failure of the reception test audio and/or modify (C72b) an audio configuration of the second client terminal T2 with a view, if possible, to resolving the audio reception problem.
  • This change of audio configuration can for example comprise a reconfiguration of any audio equipment of the second client terminal T2.
  • a change of audio configuration can include for example a change of an audio input used by the second terminal T2 to receive audio data streams during the audio and/or video conference.
  • the mediation server SV2 executes the fourth method according to steps D2-D18 (FIG. 5) or D42-D70 (FIG. 6) for a plurality of second client terminals, for example in cooperation with each of the terminals T2 , T3 and T4, so as to send in D68 to the first client terminal T1 audio capacity data DTA2, DTA3 and DTA4 respectively characterizing the second client terminals T2, T3 and T4.
  • the mediation server SV2 can generate, and transmit at D68 to the first client terminal T 1 , an audio capacity matrix indicating for each second client terminal T2-T4 whether it has detected the digital marking code WT 1 and therefore if it is capable of receiving an audio data stream FX transmitted by the first client terminal T 1 during the audio and/or video conference.
  • the first client terminal T1 can thus perform step B22 (FIGS. 5-6) by taking into account the audio capacity data DTA2, DTA3 and DTA4.
  • the first client terminal T1 can restore information IF1 indicating whether at least one (for example each) of the second client terminals T2, T3 and T4 is capable of receiving an audio data stream emitted by the first client terminal T 1 during of the current audio and/or video conference.
  • the user UR1 can easily know if he is, or will be, heard by each of the participants in the audio and/or video conference.
  • the invention makes it possible to test the ability of one or more second client terminals to receive an audio data stream transmitted by the first client terminal during an audio and/or video conference. The invention therefore makes it possible to limit the risks of the user UR1 speaking without being heard by another participant in the audio and/or video conference.
  • the second client terminal T2 is actually capable of receiving an audio data stream FX transmitted by the first client terminal T 1 , problems related to the acoustic equipment of the first client terminal and/or of the second client terminal may cause obstacle in the audio communications transmission chain from the microphone MIC1 of the first client terminal T 1 to the loudspeaker HP2 of the second client terminal T2.
  • the user UR1 does not have the guarantee that the user UR2 can or will be able to hear it even if the second client terminal T2 is capable of receiving an audio data stream emitted by the first client terminal T 1.
  • the invention may also comprise an acoustic test of at least one of the first client terminal T1 and the second client terminal(s) T2-T4, in order to complete the audio capacity data DTA2 generated by the mediation server SV2 (steps D16 and D66, Figures 5-6) with acoustic capacity data DTB.
  • the first client terminal T1 performs an acoustic test of the microphone MIC1 to which it is coupled (and more generally a test of the acoustic equipment of the first client terminal T1), by performing steps B80-B88 at course of the first method as described with reference to steps B2-B24 (FIG. 5) or steps B40-B68 (FIG. 6).
  • This test more generally makes it possible to test the entire acoustic chain (including the loudspeaker HP1 and the microphone MIC1) of the first client terminal T 1 .
  • the first client terminal T 1 activates (B80) its microphone MIC1 if it is not already active, and can optionally deactivate (B82) an echo cancellation function F1 in the case where such a function is active.
  • An echo cancellation function is in fact likely to hinder the smooth running of the acoustic test of the microphone MIC1.
  • the cancellation, where appropriate, of an echo cancellation function F1 allows good acoustic acquisition by the microphone MIC1 of an acoustic emission (or output) from the loudspeaker HP1 coupled to the first client terminal T 1 .
  • the first client terminal T1 generates an acoustic test signal denoted SA1 (FIG. 1) by means of the loudspeaker HP1.
  • SA1 acoustic test signal denoted SA1 (FIG. 1) by means of the loudspeaker HP1.
  • the first client terminal T1 can supply at the input of the loudspeaker any test audio data stream, so as to produce an acoustic test signal SA1 at the output of the
  • the acoustic test signal SA1 is preferably a signal (sound emission) inaudible to the human ear (for example at high frequencies) so as not to disturb the user UR1 during the audible and/or video conference, but can possibly be an audible signal.
  • the test acoustic signal SA1 is emitted at a frequency of at least 20 KHz. It can be a single-frequency signal or a sinusoidal signal, although other implementations are possible.
  • the acoustic test signal SA1 thus generated has a sampling frequency of at least 44.1 KHz.
  • the acoustic test signal SA1 is also emitted preferably for a short time (for example for a maximum duration of 250 ms), in order to avoid possibly disturbing the user UR1 and so as to save resources and speed up as much as possible. the acoustic test process while ensuring that this acoustic test signal SA1 is detectable by the microphone MIC1.
  • the first client terminal T1 makes an acoustic acquisition by means of the microphone MIC1 while the loudspeaker HP1 emits the acoustic test signal SA1, so as to attempt to capture this acoustic test signal SA1.
  • the first client terminal T 1 determines (B88), from a result of the acoustic acquisition B86, acoustic capacity data DTB1 characterizing the acoustic capacities of the microphone MIC1 (and more generally of the acoustic equipment of the first terminal customer T1).
  • the first client terminal T1 acquires in B86 a test audio data stream DA1 produced by the microphone MIC1 from an acoustic signal picked up by said microphone.
  • the first client terminal T 1 analyzes (B86), from the test audio data stream DA1 , an acoustic signal picked up by the microphone MIC1.
  • the first client terminal T1 can in particular compare the acoustic signal picked up on the one hand, with the test acoustic signal SA1 generated in B84 on the other hand. Based on a result of this comparison, the first client terminal T 1 evaluates whether there is correspondence between the acoustic signal picked up and the acoustic test signal SA1.
  • the acoustic capacitance data DTB1 can then be a function of a degree of correspondence between these two signals. If there is a match, this means that the microphone MIC1 (and more generally the acoustic equipment of the first client terminal T1) is functional. Otherwise, this means that the microphone MIC1 is likely to be defective, or at least that the acoustic equipment of the first client terminal T1 is not functional.
  • the first client terminal T1 can thus carry out the management step B22 (FIGS. 5-6) also according to the acoustic capacity data DTB1 obtained in B88.
  • the information IF1 restored if necessary by the first client terminal T1 during the restoration step B24 can be representative not only of the audio capacity data DTA2 received but also of the acoustic capacity data DTB1 of the first client terminal T 1.
  • the first client terminal T1 can transmit to the mediation server SV2 the acoustic capacity data DTB1 obtained in B88.
  • the mediation server SV2 can then also transmit these acoustic capacity data DTB1 to the second client terminal T2, or more generally to each second client terminal T2-T4.
  • the acoustic test (B80-B88, FIG. 7) can be carried out at various stages of the first method implemented by the first client terminal T1 (FIGS. 5-6).
  • the first client terminal T1 triggers this acoustic test on detection of the reception B2 (FIG. 5) or B46 (FIG. 6) of the digital marking code WT1 transmitted by the mediation server SV2, or at least before the step B4 for obtaining (FIG. 5) or step B50 for generating (FIG. 6) the audio data stream marked FX1.
  • the terminal T1 can reactivate the echo cancellation function F1 if necessary, in order to avoid possible disturbances of the acoustic acquisition of the microphone MIC1 during the conference. audio and/or video.
  • the first client terminal T1 is for example configured to trigger the sending B6 or B52 of the audio data stream marked FX1 only if the acoustic test B80-B88 is passed successfully, that is to say if it indicates that the microphone MIC1 is functional. Thus, if the acoustic test of the microphone MIC1 of the first client terminal T1 fails, the latter does not continue the audio test, or possibly selects the random noise emulation technique as described previously to generate in B50 (FIG. 6) the audio data stream marked FX1.
  • the first client terminal T1 carries out an acoustic test of the loudspeaker HP2 to which it is coupled (and more generally a test of the acoustic equipment of the second client terminal T2), by performing steps C100- C108 during the second process as described with reference to steps C8-C12 (FIG. 5) or to steps C40-C72 (FIG. 6).
  • This acoustic test C100-C108 is performed analogously to the acoustic test B80-B88 of the first client terminal T1 as described above. This test more generally makes it possible to test the entire acoustic chain (including the loudspeaker HP2 and the microphone MIC2) of the second client terminal T2.
  • the second client terminal T2 activates (C100) its microphone MIC2 if it is not already active, and can optionally deactivate (C102) an echo cancellation function F2 in the case where such a function is active .
  • An echo cancellation function is in fact liable to hinder the smooth running of the acoustic test of the loudspeaker HP2.
  • the cancellation, where appropriate, of an echo cancellation function F2 allows good acoustic acquisition by the microphone MIC2 of an acoustic emission (or output) from the loudspeaker HP2 coupled to the second client terminal T2.
  • the second client terminal T2 generates an acoustic test signal denoted SA2 (FIG. 1) by means of the loudspeaker HP2.
  • SA2 acoustic test signal denoted SA2 (FIG. 1) by means of the loudspeaker HP2.
  • the second client terminal T2 can supply at the input of the loudspeaker HP2 any test audio data stream, so as to produce an acoustic test signal SA2 at
  • the acoustic test signal SA2 is preferably a signal inaudible to the human ear (for example at high frequencies) so as not to disturb the user UR2 during the audible and/or video conference, but may optionally be a signal audible.
  • the test acoustic signal SA2 is emitted at a frequency of at least 20 KHz. It can be a single-frequency signal or a sine wave, although other implementations are possible.
  • the acoustic test signal SA2 thus generated has a sampling frequency of at least 44.1 KHz.
  • the acoustic test signal SA2 is also emitted preferably for a short time (for example for a maximum duration of 250 ms), in order to avoid possibly disturbing the user UR1 and so as to save resources and speed up as much as possible. the acoustic test process, while ensuring that this acoustic test signal SA2 is detectable by the microphone MIC2.
  • the second client terminal T2 makes an acoustic acquisition by means of the microphone MIC2 while the loudspeaker HP2 emits the test acoustic signal SA2, so as to attempt to pick up this acoustic signal from SA2 test.
  • the second client terminal T2 determines (C108), from a result of the acoustic acquisition C106, acoustic capacity data DTB2 characterizing the acoustic capacities of the loudspeaker HP2 (and more generally of the acoustic equipment of the second customer terminal T2).
  • the second client terminal T2 acquires at C106 a test audio data stream DA2 produced by the microphone MIC2 from an acoustic signal picked up by said microphone.
  • the second client terminal T2 analyzes (C106), from the test audio data stream DA2, an acoustic signal picked up by the microphone MIC2.
  • the second client terminal T2 can in particular compare the acoustic signal picked up on the one hand, with the test acoustic signal SA2 generated in C104 on the other hand. Based on a result of this comparison, the second client terminal T2 evaluates whether there is correspondence between the acoustic signal picked up and the acoustic test signal SA2.
  • the DTB2 acoustic capacity data can then be a function of a degree of correspondence between these two signals. If there is a match, this means that the loudspeaker HP2 (and more generally the acoustic equipment of the first client terminal T1) is functional. Otherwise, this means that the loudspeaker HP2 is likely to be defective, or at least that the acoustic equipment of the second client terminal T2 is not functional.
  • the second client terminal T1 can transmit to the mediation server SV2 the acoustic capacity data DTB2 obtained in C108.
  • the mediation server SV2 can then also transmit these acoustic capacity data DTB1 to the first client terminal T1, or more generally to each other client terminal T1, T3 and T4 participating in the audio and/or video conference.
  • the first client terminal T1 can thus carry out the management step B22 (FIGS. 5-6) also according to the acoustic capacity data DTB2 received from the mediation server SV2.
  • the information IF1 restored if necessary by the first client terminal T1 during the restoration step B24 can also be representative of the acoustic capacitance data DTB2 of the second client terminal T2.
  • the acoustic test (C100-C108, FIG. 8) can be carried out at various stages of the second method implemented by the second client terminal T2 (FIGS. 5-6). Once the acoustic test of the second client terminal T2 has been completed, the terminal T2 can reactivate the echo cancellation function F2 if necessary, in order to avoid possible disturbances of the acoustic acquisition of the microphone MIC1 during the conference. audio and/or video.
  • each client terminal participating in the audio and/or video conference can trigger an acoustic test of its own acoustic equipment (including its microphone and loudspeaker), for example during (or in response to) the establishment S2 (FIG. 6) of the communication session with the conference server SV1.
  • each client terminal sends to the mediation server SV2 acoustic capacity data DTB representative of its own acoustic capacities.
  • the acoustic capacity data obtained by each client terminal can thus be indicative of the capacity of said client terminal to: produce an acoustic emission (or output) by means of a microphone coupled to said client terminal, from an audio data stream received from the audio and/or video conference server SV1; and acoustically acquiring, by means of a loudspeaker coupled to said client terminal, an acoustic signal.
  • all or part of the first method as described above with particular reference to FIGS. 5-6 can be repeated a plurality of times by the first client terminal T1.
  • at least some of the steps B4-B22 (or even B2-B24) are repeated during the communication session, so as to check several times (for example periodically) whether said at least one second client terminal T2-T4 is capable of receiving an audio data stream FX transmitted by the first client terminal T1. It is thus possible to monitor over time the audio capacities of one or more second terminals T2-T4, in particular while the user UR1 of the client terminal T1 is speaking or while he is silent.
  • the periodic or regular reiteration of the first method can in particular make it possible to continuously or repeatedly monitor the ability of one or more second terminals to receive an audio data stream transmitted by the first client terminal T 1 .
  • the client terminal T1 uses at least two distinct digital marking codes WT1 to implement a plurality of iterations of the first method. Changing the digital marking code WT1 during several iterations of the first method can help ensure better robustness of the audio test (for example better security of the test process in the event of interception and use authorization of a digital marking code by a third party, the possibility of using several different types of marking code for more flexibility, etc.).
  • the second client terminal T2 can in particular modify its audio configuration upon receipt of audio capacity data DTA2 indicating that said second client terminal T2 is not able to receive an audio data stream emitted by the first client terminal T 1.
  • the first client terminal T 1 performs the following steps for each of a plurality of audio configurations, as long as a first audio condition is not satisfied: configuration of the first client terminal T 1 according to said audio configuration; and reiteration of at least part of the first method as previously described (steps B2-B24).
  • the second client terminal T2 can in particular modify its audio configuration upon receipt of audio capacity data DTA2 indicating that said second client terminal T2 is not able to receive a data stream audio transmitted by the first client terminal T1.
  • the second client terminal T2 performs the following steps for each of a plurality of audio configurations, as long as a second audio condition is not satisfied: configuration of the second client terminal T2 according to said audio configuration; and repeating at least part of steps C56-C72 of the second method (FIG. 6).
  • the first and/or second client terminals can thus test each possible audio configuration until a positive audio test is obtained.
  • each client terminal T1-T4 (acting as a first client terminal) can thus implement the first method as previously described with reference to FIGS. 5-8 so as to test the capacity of each other client terminal (acting as a second client terminal) to receive an audio data stream transmitted by said client terminal.
  • the mediation server SV2 can for example generate a capacity matrix comprising audio capacity data DTA associated with each client terminal, these data indicating whether an audio stream emitted by said client terminal is able to be received by each other client terminal.
  • This capacity matrix may optionally also include acoustic capacity data DTB characterizing the acoustic capacities of each client terminal. In other words, this capacity matrix can be obtained by completing the audio capacity matrix previously described with the DTB acoustic capacity data of the client terminals.
  • the mediation server SV2 can also transmit this capacity matrix to at least one (for example each) client terminal T1-T4 so that the latter manages the audio and/or video conference by adapting its operation accordingly.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présent invention vise un procédé mis en œuvre par un premier terminal client lors d'une conférence audio et/ou vidéo en coopération avec un serveur de conférence gérant des échanges de flux de données audio, le procédé comprenant : obtention d'un flux de données audio marquées par intégration d'un code de marquage numérique; envoi du flux de données audio marquées au serveur de conférence; réception de données de capacité audio représentatives de si un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio; et déclenchement à partir des données de capacité audio reçues d'au moins une action de gestion de la conférence audio et/ou vidéo, comprenant une restitution d'informations fonction des données de capacité audio reçues.

Description

Description
Titre de l'invention : Gestion d’une audioconférence audio et/ou vidéo Domaine Technique
L'invention se rapporte au domaine de l’audioconférence et de la visioconférence, et concerne plus particulièrement la capacité d’un utilisateur à être entendu ou non par un autre utilisateur lors d’audioconférence ou visioconférence.
Technique antérieure
Les systèmes de visioconférence ou audioconférence ont connu un essor important ces dernières années et cette tendance s’est encore amplifiée dans le contexte sanitaire actuel. Une audioconférence (ou conférence audio) permet à des participants de communiquer par audio de façon instantanée tandis qu’une visioconférence (ou conférence vidéo) permet non seulement de communiquer par audio mais aussi par image de façon instantanée. Autrement dit, lors d’une visioconférence, des flux vidéo sont échangés entre les terminaux des participants afin que chacun puisse voir et entendre ses interlocuteurs. Lors d’une conférence audio, des flux audio sont échangés sans qu’il n’y ait de flux image.
Les conférences de communication, de type audioconférence et vidéoconférence, sont des solutions permettant à plusieurs participants de communiquer ensemble de façon efficace au moyen de terminaux clients. Cependant, ces outils sont parfois délicats à utiliser pour les non-initiés et des problèmes techniques empêchent régulièrement les participants de profiter d’une bonne expérience utilisateur. En particulier, un problème récurrent se pose en ce qu’il n’est pas toujours possible pour un participant de savoir s’il est, ou va être, bien entendu par d’autres participants au cours d’une conférence audio ou vidéo. Cette incertitude pousse souvent les participants à demander auprès de leurs interlocuteurs s’ils sont bien entendu de tous, ce qui peut apporter de la confusion, une gêne pour les participants (perte de temps, etc.), et cette méthode n’apporte pas l’assurance que tous les participants entendent effectivement bien le locuteur en question, en particulier quand un nombre important d’utilisateurs participe à la conférence.
Ces problèmes de bonne réception audio posent un défi dans la mesure où de nombreux problèmes techniques sont susceptibles d’empêcher un participant d’être bien entendu par ses interlocuteurs (problèmes de configuration, problèmes matériels, mauvaises utilisations des outils...).
Les contraintes et limites techniques évoquées ci-dessus peuvent par conséquent dégrader l’expérience utilisateur et limiter l’intérêt de ces outils de communication pour certains utilisateurs ou dans certains contextes.
Exposé de l’invention
A cet effet, la présente invention concerne un premier procédé mis en œuvre par un premier terminal client lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre le premier terminal client et au moins un deuxième terminal client au cours d’une conférence audio et/ou vidéo.
Selon la présente demande, le premier procédé comprend : - envoi au serveur de conférence audio et/ou vidéo , d’un flux de données audio marquées par intégration d’un code attribué audit premier terminal dans un premier flux de données audio;
- réception, de données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code attribué audit premier terminal dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et
- déclenchement d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : o restitution, par une interface utilisateur du premier terminal client, d’informations fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.
Selon au moins un mode de réalisation, le premier procédé comprend une réception, depuis un serveur de médiation (SV2) du code attribué au premier terminal client.
Selon au moins un mode de réalisation, ledit code attribué audit premier terminal client est reçu en réponse à une requête audit serveur de médiation comprenant un identifiant du premier terminal client.
Selon au moins un mode de réalisation, le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone couplé au premier terminal client.
Selon au moins un mode de réalisation, les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité.
Selon au moins un mode de réalisation, le premier procédé comprend le premier flux de données audio est généré par émulation d’un bruit aléatoire.
Selon au moins un mode de réalisation, le premier procédé comprend, avant l’envoi du flux de données audio marquées au serveur conférence audio et/ou vidéo : activation du premier microphone du premier terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut-parleur couplé audit au moins un premier terminal client ; génération d’un signal acoustique de test au moyen du premier haut-parleur ; acquisition acoustique, au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination, à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations restituées par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client. Selon au moins un mode de réalisation, le premier procédé comprend : a) obtention d’un flux de données audio marquées par intégration d’un code de marquage numérique dans un premier flux de données audio par tatouage numérique; b) envoi du flux de données audio marquées au serveur de conférence audio et/ou vidéo ; c) réception, en provenance d’un serveur de médiation, de données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et d) déclenchement d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : restitution, par une interface utilisateur du premier terminal client, d’informations, fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.
Comme déjà indiqué, il n’est pas toujours aisé pour un utilisateur participant à une conférence audio et/ou vidéo de savoir s’il est, ou s’il va être, bien entendu des autres participants lorsqu’il parle ou qu’il s’apprête à parler lors d’une conférence audio et/ vidéo. Divers problèmes matériels, logiciels ou autres sont susceptibles de faire obstacle à une bonne transmission d’un flux audio depuis le terminal client du locuteur considéré vers les terminaux clients d’autres participants. L’usage, dans certains modes de réalisation de l’invention, d‘une technique de marquage numérique (dit « watermarking ») peut aider à tester de façon fiable et robuste la capacité de terminaux clients à recevoir des flux de données audio en provenance d’un terminal client donné au cours d’une conférence audio et/ou vidéo. L’invention peut aider ainsi de limiter les risques qu’un utilisateur parle sans être entendu par un autre participant à la conférence audio et/ou vidéo.
Selon au moins un mode de réalisation, l’obtention a) comprend : e) envoi à un serveur de médiation d’une requête de code de marquage numérique, ladite requête comprenant un identifiant du premier terminal client; f) réception, en réponse à ladite requête, du code de marquage numérique attribué au premier terminal client.
Selon au moins un mode de réalisation, le premier procédé comprend : détermination, lors d’un établissement de la session de communication, d’un identifiant de la conférence audio et/ou vidéo ; et insertion dans la requête de code de marquage numérique de l’identifiant de la conférence audio avant envoi au serveur de médiation, de sorte à permettre audit serveur de médiation d’enregistrer le code de marquage numérique en association avec l’identifiant du premier terminal client et l’identifiant de la conférence audio et/ou vidéo.
L’usage d’un identifiant de la conférence audio et/ou vidéo peut permettre notamment au serveur de médiation de reconnaître une requête associée à la conférence audio et/ou vidéo en cours, et ainsi d’obtenir ou générer un code (comme un code de marquage numérique par exemple) unique pour le premier terminal client. Le serveur de médiation peut en particulier superviser un test de réception de flux audio pour une pluralité de conférence audio et/ou vidéo distinctes, y compris lorsque le premier terminal client T1 participe à plusieurs conférences simultanément ou successivement sur une période donnée.
Selon au moins un mode de réalisation, le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone couplé au premier terminal client. Il est ainsi possible de réaliser un test audio tout en transmettant des sons depuis le premier terminal client vers le deuxième terminal client lors de la conférence audio et/ou vidéo.
Selon un mode de réalisation particulier, les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité. Il est ainsi possible de réaliser un test audio alors que l’utilisateur du premier terminal client est silencieux (ne parle pas) pendant la conférence en cours.
Selon au moins un mode de réalisation, l’envoi de la requête de code de marquage numérique est déclenché sur détection, au moyen du premier microphone du premier terminal client, d’une période de silence d’une durée au moins égale à une première durée, au cours de laquelle un bruit de fond d’une intensité inférieure à ladite première valeur d’intensité est détecté. Il est ainsi possible de déclencher automatiquement un test audio lorsque l’utilisateur du premier terminal client est silencieux (ne parle pas) lors de la conférence en cours.
Selon au moins un mode de réalisation, l’envoi de la requête de code de marquage numérique est déclenché sur détection que le premier microphone est désactivé pendant au moins une deuxième durée.
Selon au moins un mode de réalisation, le premier flux de données audio est généré par émulation d’un bruit aléatoire. Il est ainsi possible, au moins dans certains modes de réalisation, de réaliser un test audio de façon fiable et robuste, indépendamment de tout flux de données audio susceptibles d’être émis par le premier terminal client lors la conférence en cours.
Selon au moins un mode de réalisation, aux moins certaines des étapes a)-d) du procédé mis en œuvre sur le premier terminal client peuvent être réitérées pendant ladite session de communication, de façon à vérifier plusieurs fois (par exemple périodiquement) si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio émises par le premier terminal client. Il est ainsi possible de vérifier sur une période donnée, de façon répétée (périodiquement ou régulièrement) ou continue, si le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client lors de la conférence en cours.
Selon au moins un mode de réalisation, si les données de capacité audio reçues représentent que ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues en provenance du serveur d’audioconférence, alors les informations restituées par l’interface utilisateur indiquent que ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio émises par le premier terminal client. L’utilisateur du premier terminal client peut ainsi s’assurer qu’il est ou sera bien entendu lors de la conférence en cours.
Selon au moins un mode de réalisation, le premier terminal client envoie au serveur de médiation une notification informant de l’envoi du flux de données marquées au serveur de conférence audio et/ou vidéo. Il est ainsi possible pour le serveur de médiation d’être informé lorsqu’un test audio est initié par le premier terminal client. A partir de cette notification, le serveur de médiation peut en particulier déterminer s’il reçoit une notification depuis le deuxième terminal client, indiquant que ce dernier a détecté le code de marquage numérique.
Selon au moins un mode de réalisation, ladite au moins une action de gestion comprend : si les données de capacité audio reçues représentent que ledit au moins un deuxième terminal client n’a pas détecté le code de marquage numérique dans le flux de données audio mixées reçu en provenance du serveur d’audioconférence, changement d’une configuration audio du premier terminal client.
Il est ainsi possible par exemple pour le premier terminal client d’adapter sa configuration lorsqu’un problème de réception de flux audio est détecté, et donc améliorer les chances que l’utilisateur du premier terminal client soit entendu par le deuxième terminal client lors de la conférence.
Selon un mode de réalisation particulier, le premier procédé comprend, successivement pour chacune parmi une pluralité de configurations audio, tant qu’une première condition audio n’est pas satisfaite : configuration du premier terminal client selon ladite configuration audio; et réitération d’au moins certaines des étapes a)-d).
Selon au moins un mode de réalisation, le premier procédé comprend, avant l’envoi du flux de données audio marquées au serveur conférence audio et/ou vidéo : activation du premier microphone du premier terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut- parleur couplé audit au moins un premier terminal client ; génération d’un signal acoustique de test au moyen du premier haut-parleur ; acquisition acoustique, au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination, à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations restituées en d) par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client.
Il est ainsi possible de tester la chaîne de traitement acoustique au niveau du premier terminal client. Selon au moins un mode de réalisation, le premier procédé comprend en outre : réception, en provenance du serveur de médiation, de données de capacité acoustique représentatives de capacités acoustiques d’un deuxième haut-parleur couplé audit au moins un deuxième terminal client à produire une sortie acoustique ; les informations restituées en d) par l’interface utilisateur étant en outre représentatives des capacités acoustiques du deuxième haut-parleur du deuxième terminal client.
L’utilisateur du premier terminal client peut ainsi être informé de la capacité de la chaîne de traitement acoustique du premier terminal client à produire une émission (sortie) acoustique.
L’invention concerne également un deuxième procédé mis en œuvre par un deuxième terminal client lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre un premier terminal client et le deuxième terminal client au cours d’une conférence audio et/ou vidéo.
Selon la présente demande, le deuxième procédé comprend : réception, en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio; et envoi d’une notification comprenant un code intégré dans ledit flux de données audio reçu, en association avec un identifiant du deuxième terminal client.
Selon au moins un mode de réalisation, le deuxième procédé comprend en outre, sur une détection dudit code dans ledit flux de données audio reçu : activation (C100) d’un deuxième microphone (MIC2) couplé au deuxième terminal client ; désactivation (C102) d’une fonction d’annulation d’écho (F2) de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur (HP2) couplé audit deuxième terminal client ; génération (C104) d’un signal acoustique de test (SA2) au moyen du deuxième haut- parleur ; acquisition acoustique (C106), au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination (C108), à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques (DTB2) du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation (SV2) des capacités acoustiques du deuxième haut- parleur.
Selon au moins un mode de réalisation, le deuxième procédé comprend : g) réception, en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio marquées ; h) détection, dans le flux audio marquées, d’un code de marquage numérique intégré dans le flux de données audio marquées par tatouage numérique ; et i) envoi, à un serveur de médiation, d’une notification indiquant la détection du code de marquage numérique, ladite notification comprenant le code de marquage numérique en association avec un identifiant du deuxième terminal client.
L’envoi au serveur de médiation de ladite notification permet audit serveur de générer des données de capacité audio indiquant si le deuxième terminal client a détecté le code intégré au flux reçu.. Le serveur de médiation peut notamment transmettre ces données de capacité audio au premier terminal client afin de lui indiquer si le deuxième terminal client est apte ou non à recevoir un flux audio émis par le premier terminal client lors de la conférence.
Selon au moins un mode de réalisation, le deuxième procédé comprend en outre, en réponse à la détection h) : activation d’un deuxième microphone couplé au deuxième terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur couplé audit deuxième terminal client ; génération d’un signal acoustique de test au moyen du deuxième haut-parleur ; acquisition acoustique, au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination, à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation des capacités acoustiques du deuxième haut-parleur.
Il est ainsi possible de tester la chaîne de traitement acoustique au niveau du deuxième terminal client. L’invention vise également un troisième procédé mis en œuvre par un système, comprenant un premier terminal client et un deuxième terminal client exécutant respectivement les premier et deuxième procédés définis ci-avant, dans au moins certains de leurs modes de réalisation, et décrits dans des exemples particuliers ci-après.
Plus particulièrement, l’invention vise un troisième procédé mis en œuvre par un système client, comprenant un premier terminal client et un deuxième terminal client, lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre le premier terminal client et le deuxième terminal client au cours d’une conférence audio et/ou vidéo, dans lequel le premier terminal exécute un premier procédé tel que défini ci-avant ; dans lequel le deuxième terminal exécute un deuxième procédé tel que défini ci-avant ; les informations restituées en d) par le premier terminal client indiquant que le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client.
Selon au moins un mode de réalisation, le troisième procédé comprend en outre (par exemple en réponse à la détection h), les étapes suivantes mises en œuvre par ledit deuxième terminal client : activation d’un deuxième microphone couplé au deuxième terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur couplé audit deuxième terminal client ; génération d’un signal acoustique de test au moyen du deuxième haut-parleur ; acquisition acoustique, au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination, à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques du deuxième haut-parleur du deuxième terminal client à produire une sortie acoustique ; et envoi au serveur de médiation des capacités acoustiques du deuxième haut-parleur ; le procédé comprenant en outre l’étape suivante mise en œuvre par le premier terminal client : réception, en provenance du serveur de médiation, de données de capacité acoustique représentatives desdites capacités acoustiques du deuxième haut-parleur du deuxième terminal client ; les informations restituées en d) par le premier terminal client étant en outre représentatives des capacités acoustiques du deuxième haut-parleur du deuxième terminal client.
L’invention vise également un quatrième procédé mis en œuvre par un serveur de médiation en coopération avec une pluralité de terminaux clients (comprenant un premier terminal client et un deuxième terminal client) participant à une conférence audio et/ou vidéo au cours de laquelle des flux de données audio sont échangés via un serveur de conférence audio et/ou vidéo.
Selon la présente demande, le quatrième procédé comprend : envoi à un premier terminal client d’un code attribué au premier terminal client et enregistré, en association avec un identifiant (ID1) du premier terminal client ; sur réception, en provenance d’un deuxième terminal client, d’une notification comprenant le code attribué audit premier terminal client en association avec un identifiant du deuxième terminal client ; détermination de données de capacité audio indiquant si le deuxième terminal client est apte à recevoir un flux de données audio en provenance du premier terminal client; et envoi au premier terminal client desdites données de capacité audio.
Selon au moins un mode de réalisation, il est déterminé une absence de réception de ladite notification si aucune dite notification, indiquant que le deuxième terminal client (T2) a détecté le code attribué audit premier terminal, n’est reçue dans un premier délai à compter d’un instant de référence.
Plus précisément, selon au moins un mode de réalisation, le quatrième procédé comprend : j) envoi à un premier terminal client d’un code de marquage numérique attribué au premier terminal client et enregistré, dans des données de marquage dudit serveur de médiation, en association avec un identifiant du premier terminal client ; k) détermination, à partir des données de marquage, de si une notification indiquant qu’un deuxième terminal client a détecté le code de marquage numérique est reçue en provenance dudit deuxième terminal client, ladite notification comprenant le code de marquage numérique en association avec un identifiant du deuxième terminal client ;
L) détermination, à partir d’un résultat de la détermination k), de données de capacité audio indiquant si le deuxième terminal client est apte à recevoir un flux de données audio en provenance du premier terminal client ; et m) envoi au premier terminal client des données de capacité audio.
Le serveur de médiation est ainsi capable de superviser le test audio initié par le premier terminal client pour évaluer si le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client lors de la conférence.
Selon au moins un mode de réalisation, il est déterminé en k) une absence de réception de ladite notification si aucune dite notification, indiquant que le deuxième terminal client a détecté le code de marquage numérique, n’est reçue dans un premier délai à compter d’un instant de référence. Le serveur de médiation est ainsi en mesure de déterminer que le deuxième terminal client n’a pas détecté le code de marquage numérique si ledit serveur de médiation ne reçoit pas de notification en ce sens du deuxième terminal client. Selon un mode de réalisation particulier, le serveur de médiation exécute les étapes j) à m) pour une pluralité de deuxièmes terminaux clients, de sorte à envoyer en m) au premier terminal client des données de capacité audio de chacun de la pluralité de deuxièmes terminaux clients.
Le serveur de médiation peut ainsi superviser des tests audio initiés par le premier terminal client de sorte à évaluer si une pluralité de deuxièmes terminaux client participant à la conférence sont aptes à recevoir un flux de données audio émis par le premier terminal client.
Selon un mode particulier de réalisation, les différentes étapes des premier, deuxième procédé, troisième et quatrième procédés tels que définis ci-avant, et tels décrits ci-après dans des exemples particuliers, sont déterminées par des instructions de programmes d’ordinateurs.
En conséquence, l’invention vise aussi des programmes d’ordinateur sur des supports d’informations (ou support d’enregistrement), ces programmes étant susceptibles d’être mis en œuvre dans des terminaux ou dans des serveurs, ou plus généralement dans des ordinateurs, ces programmes comportant des instructions adaptées à la mise en œuvre respectivement des étapes des premier, deuxième, troisième et quatrième procédés. Ainsi, chacun des procédés de l’invention peut être implémenté au moyen d’une mémoire non volatile stockant des instructions de programmes d’ordinateur et d’un processeur exécutant ces instructions.
Selon un mode de réalisation, les différents procédés de l'invention sont mis en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous- programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné. Un tel composant logiciel peut être exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel peut correspondre à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
La présente invention vise également un premier terminal client (et respectivement un deuxième terminal client) configuré pour mettre en œuvre le premier procédé (et respectivement le deuxième procédé) de l’invention tel que défini ci-avant et décrit ci-après dans des exemples particuliers.
La présente invention vise également un système comprenant les premier et deuxième terminaux clients de l’invention, configuré pour mettre en œuvre le troisième procédé de l’invention.
La présente invention vise également un serveur de médiation configuré pour mettre en œuvre le quatrième procédé de l’invention tel que défini ci-avant et décrit ci-après dans des exemples particuliers. A noter que les différents modes de réalisation mentionnés ci-avant (ainsi que ceux décrits ci-après) en relation avec les différents procédés de l’invention ainsi que les avantages associés s’appliquent de façon analogue aux terminaux clients, système et serveur de médiation de l’invention.
Pour chaque étape des procédés de l’invention, le dispositif (ou entité physique) associé de l’invention (premier terminal client ; second terminal client, système, serveur de médiation) peut comprendre un module correspondant configuré pour réaliser ladite étape.
Brève description des dessins
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
[Fig. 1] La figure 1 représente schématiquement un environnement comprenant des terminaux clients et un serveur de médiation, selon un mode de réalisation particulier de l’invention ;
[Fig. 2] La figure 2 représente schématiquement un premier terminal client selon au moins un mode de réalisation de l’invention ;
[Fig. 3] La figure 3 représente schématiquement un deuxième terminal client selon au moins un mode de réalisation de l’invention ;
[Fig. 4] La figure 4 représente schématiquement un serveur de médiation selon au moins un mode de réalisation de l’invention ;
[Fig. 5] La figure 5 représente, sous forme d'un diagramme, les étapes de procédés mis en œuvre par des terminaux clients et par un serveur de médiation, selon certains modes de réalisation de l'invention ; [Fig. 6] La figure 6 représente, sous forme d'un diagramme, les étapes de procédés mis en œuvre par des terminaux clients et par un serveur de médiation, selon certains modes de réalisation de l'invention ; [Fig. 7] La figure 7 représente, sous forme d'un diagramme, les étapes d’un procédé mis en œuvre par un premier terminal client, selon au moins un mode de réalisation de l'invention ; et [Fig. 8] La figure 8 représente, sous forme d'un diagramme, les étapes d’un procédé mis en œuvre par un deuxième terminal client, selon au moins un mode de réalisation de l'invention.
Description des modes de réalisation
Comme indiqué ci-avant, la présente demande concerne la communication d’utilisateurs lors d’une audioconférence (dit aussi conférence audio) ou visioconférence (dit aussi conférence vidéo). Par définition, les conférences audio et/ou vidéo impliquent l’échange de données au moins de type audio. Ainsi, les conférences audio impliquent des échanges de flux audio tandis que les conférences vidéo impliquent des échanges de flux image et de flux audio (flux vidéo).
L’invention se propose en particulier de permettre à un utilisateur participant à une conférence audio et/ou vidéo (dit aussi plus simplement « conférence ») de vérifier qu’il est ou sera bien entendu par au moins un autre participant donné. Pour ce faire, l’invention utilise, selon ses différents modes de réalisation, un code, attribué à un premier terminal client, comme un code de marquage numérique, qui est intégré dans un flux de données audio pour déterminer si au moins un deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client.
Ainsi, selon au moins certains modes de réalisation , un premier terminal client peut être configuré pour envoyer un flux de données audio marquées à un serveur de conférence audio et/ou vidéo (dit aussi « serveur de conférence ») gérant des échanges de flux de données audio entre le premier terminal client et au moins un deuxième terminal client au cours d’une conférence audio et/ou vidéo. Ce flux de données audio marquées peut comprendre un code, comme un code de marquage numérique, intégré par exemple par tatouage numérique dans un flux de données audio. Le premier terminal client peut recevoir en outre, en provenance d’un serveur de médiation, des données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçu du serveur de conférence audio et/ou vidéo. Il est ainsi possible pour le premier terminal client de déterminer si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.
En outre, l’invention vise notamment un deuxième terminal client configuré pour traiter un flux de données audio marquées comme indiqué ci-avant, un serveur de médiation correspondant, ainsi que des procédés et programme d’ordinateur correspondants. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux figures mentionnées ci-avant.
Dans ce document, des exemples de mise en œuvre de l’invention sont décrits dans le cadre de la gestion d’une conférence audio et/ou, où seul le traitement des flux de données audio est pris en compte. On comprend toutefois que l’invention s’applique aussi bien dans le cadre d’une conférence audio que dans celui d’une conférence vidéo. De manière générale, l’invention permet notamment de tester la transmission/réception de flux de données audio dans une conférence de communication, de type audioconférence ou vidéoconférence.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc. sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des terminaux, procédé) mis en œuvre dans les modes de réalisation décrits ci-après.
La figure 1 représente schématiquement, à titre d’exemple non limitatif, un environnement comprenant un premier terminal client T1 , un deuxième terminal client T2, un serveur de conférence audio et/ou vidéo SV1 et un serveur de médiation SV2 (dit aussi serveur de contrôle). Dans cet exemple, les terminaux clients T1 et T2 sont utilisés respectivement par des utilisateurs UR1 et UR2 pour communiquer par audio au cours d’une conférence audio et/ou vidéo. Pour ce faire, le serveur de conférence SV1 gère des échanges de flux de données audio FX entre les terminaux clients participant à la conférence.
A noter que le nombre et la nature des terminaux clients participant à la session de communication au cours de la conférence peut varier selon le cas. En particulier, le nombre de deuxièmes terminaux clients au sens de l’invention, dont le premier terminal client T1 teste la réception audio, peut varier selon le cas. A titre d’exemple, des deuxièmes terminaux clients T3 et T4 peuvent aussi coopérer avec le serveur de conférence SV1 et avec le serveur de médiation SV2, bien que des mises en œuvre de l’invention soient également possible avec seulement deux terminaux clients, à savoir le premier terminal client T1 et le deuxième terminal client T2 dans cet exemple. Aussi, le principe de l’invention est décrit ci-après dans des exemples particuliers mettant en jeu principalement le terminal T1 en tant que premier terminal client et le terminaux T2 en tant que deuxième terminal client au sens de l’invention. L’invention peut toutefois s’appliquer de manière analogue à une pluralité de deuxièmes terminaux clients (T2, T3 et/ou T4 par exemple) opérant en tant que deuxièmes terminaux au sens de l’invention. A noter également que chacun des terminaux clients T1-T4 peut en outre être configuré pour agir à la fois en tant que premier terminal et en tant que deuxième terminal au sens de l’invention. On suppose que les terminaux clients sont chacun aptes à coopérer avec le serveur de conférence SV1 via un réseau de communication quelconque, tel qu’internet, ou un réseau Intranet ou un quelconque autre réseau approprié. Les terminaux clients T1-T4 peuvent être des ordinateurs (PC, ordinateurs portables, etc.), des tablettes, téléphones intelligents ou « smartphones », ou tous autres types de terminaux aptes à échanger des flux de données audio lors d’une conférence audio et/ou vidéo avec au moins un autre participant.
Le serveur de conférence SV1 est configuré pour gérer des communications audio lors d’une session de communication établie avec les terminaux clients T1-T4 lors d’une conférence audio et/ou vidéo. Pour ce faire, le serveur de conférence SV1 est apte à établir la session de communication avec chacun des terminaux clients, puis de recevoir les flux de données audio FX émis ou générés par les terminaux clients T1-T4. Le serveur de conférence SV1 traite alors ces flux de données audio afin de les redistribuer aux autres participants. Plus particulièrement, le serveur de conférence SV1 peut par exemple décoder les flux de données audio FX reçus selon des codées appropriés (ceux utilisés par les terminaux clients correspondants), réaliser un mixage de ces données audio et générer un flux de données audio mixées par un ré-encodage des données audio mixées. Ce flux de données audio mixées peut ensuite être envoyé aux différents terminaux clients afin que leurs utilisateurs puissent entendre toutes les communications audio échangées par les participants.
Comme représenté en figure 1 , les terminaux clients T1-T4 peuvent également être aptes à coopérer avec le serveur de médiation SV2 au travers d’un quelconque réseau de communication approprié. Comme décrit en détail par la suite, le serveur de médiation SV2 peut être configuré par exemple pour évaluer les capacités audio d’au moins certains des terminaux clients et pour transmettre à au moins certains aux terminaux clients des données de capacité audio DTA représentatives de capacités audio d’au moins certains des terminaux clients T1-T4. Pour ce faire, le serveur de médiation SV2 peut transmettre à d’au moins certains des terminaux clients (par exemple à chacun) un code WT, comme un code de marquage numérique, qui lui est attribué. Ces codes de marquage numérique sont destinés par exemple à être intégrés par tatouage numérique dans un flux de données audio pour réaliser des tests audio, comme décrit par la suite. A titre d’exemple, le serveur de médiation SV2 peut envoyer des codes de marquages numériques WT 1 et WT2 aux terminaux clients T 1 et T2, respectivement. Comme décrit ultérieurement, ces codes de marquage numérique peuvent être utilisés par la suite pour tester l’aptitude de terminaux clients à recevoir un flux de données audio émis par notamment du premier terminal client T1 dans cet exemple.
Selon un exemple particulier, le serveur de médiation SV2 peut également envoyer aux terminaux clients des données de capacité acoustique DTB (figure 1) représentatives des capacités acoustiques de terminaux clients, comme décrit ultérieurement. Les structures des terminaux clients et du serveur de médiation SV2 sont à présent décrites en référence à la figure 1, selon des modes de réalisation particuliers.
Ainsi, selon un exemple particulier représenté en figure 1 , le terminal client T 1 comprend un processeur 2, une mémoire volatile (RAM) 4, une mémoire non volatile 6, une interface de communication INT 1 , une interface utilisateur IU1 et une mémoire non volatile réinscriptible MR1.
La mémoire 6 est par exemple une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le terminal client T1 , et sur lequel est enregistré un premier programme d’ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG1 comporte des instructions pour l’exécution des étapes d’un premier procédé (dit aussi premier procédé de gestion) selon un mode de réalisation particulier, comme décrit plus en détail ultérieurement.
Le terminal client T1 est apte à utiliser son interface de communication INT1 pour communiquer avec le serveur de conférence SV1 et avec le serveur de médiation SV2. La nature de cette interface est fonction du type de réseau de communication utilisé.
La mémoire non volatile réinscriptible MR1 (par exemple de type flash ou EEPROM) est apte à stocker un identifiant ID1 du terminal client T1 , un code, comme un code de marquage numérique, WT 1 et des données de capacité audio DTA. Le cas échéant, la mémoire MR1 peut également être utilisée pour stocker des données de capacité acoustique DTB.
Dans cet exemple on considère qu’un premier haut-parleur HP1 et un premier microphone MIC1 sont couplés au premier terminal client T 1 de sorte à ce que l’utilisateur UR1 puisse entendre et émettre des communications audio lors d’une conférence audio et/ou vidéo. Des variantes de réalisation sans l’un au moins parmi le haut-parleur HP1 et le microphone MIC1 sont toutefois possibles. Le haut-parleur HP1 permet la génération de sons (dits signaux acoustiques) à partir de données audio tandis que le microphone MIC1 permet de générer des données audio par acquisition acoustique de sons (ou signaux acoustiques). Le haut-parleur HP1 et le microphone MIC1 constituent des moyens audio qui peuvent être utilisés par le processeur 2 au moyen d’une carte audio et/ou de tous autres moyens matériels et/ou logiciels qui sont configurés selon une configuration audio particulière.
Comme décrit par la suite dans des exemples particuliers, le haut-parleur HP1 peut être configuré pour émettre notamment un signal acoustique de test noté SA1 dont le microphone MIC1 peut faire l’acquisition acoustique.
Le processeur 2 utilise par exemple la mémoire volatile 4 pour contrôler les différents composants (mémoires, interface de communication,...) et pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du terminal client T1 , y compris pour exécuter le programme d’ordinateur PG1 lors de la mise en œuvre du premier procédé de l’invention.
Bien que d’autres mises en œuvre soient possibles, on suppose dans cet exemple que le deuxième terminal client T2 présente une structure identique à celle du premier terminal T1 , de sorte que ces deux terminaux peuvent être utilisés de manière interchangeable pour exécuter les premier et deuxième procédés au sens de l’invention. Selon un exemple particulier représenté en figure 1, le deuxième terminal client T2 comprend un processeur 10, une mémoire volatile (RAM) 12, une mémoire non volatile 14, une interface de communication INT2, une interface utilisateur IU2 et une mémoire non volatile réinscriptible MR2.
La mémoire 12 est par exemple une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le terminal client T2, et sur lequel est enregistré un deuxième programme d’ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG2 comporte des instructions pour l’exécution des étapes d’un deuxième procédé (dit aussi deuxième procédé de gestion) selon un mode de réalisation particulier, comme décrit plus en détail ultérieurement.
Le terminal client T2 est apte à utiliser son interface de communication INT2 pour communiquer avec le serveur de conférence SV1 et avec le serveur de médiation SV2. Comme déjà indiqué, la nature de cette interface est fonction du type de réseau de communication utilisé.
La mémoire non volatile réinscriptible MR2 (par exemple de type flash ou EEPROM) est apte à stocker un identifiant ID2 du terminal client T2, un code de marquage numérique WT2 et des données de capacité audio DTA. Le cas échéant, la mémoire MR2 peut également être utilisée pour stocker des données de capacité acoustique DTB.
Dans cet exemple on considère qu’un deuxième haut-parleur HP2 et un deuxième microphone MIC2 sont couplés au deuxième terminal client T2 de sorte à ce que l’utilisateur UR2 puisse entendre et émettre des communications audio lors d’une conférence audio et/ou vidéo. Des variantes de réalisation sans l’un au moins parmi le haut-parleur HP2 et le microphone MIC2 sont toutefois possibles. Le haut-parleur HP2 permet la génération signaux acoustiques à partir de données audio tandis que le microphone MIC2 permet de générer des données audio par l’acquisition acoustique de signaux acoustiques. Le haut-parleur HP2 et le microphone MIC2 constituent des moyens audio qui peuvent être utilisés par le processeur 10 au moyen d’une carte audio et/ou de tous autres moyens matériels et/ou logiciels qui sont configurés selon une configuration audio particulière.
Comme décrit par la suite dans des exemples particuliers, le haut-parleur HP2 peut être configuré pour émettre notamment un signal acoustique de test noté SA2 dont le microphone MIC2 peut faire l’acquisition acoustique.
Le processeur 10 utilise par exemple la mémoire volatile 12 pour contrôler les différents composants (mémoires, interface de communication,...) et pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du terminal client T2, y compris pour exécuter le programme d’ordinateur PG2 lors de la mise en œuvre du deuxième procédé de l’invention.
Dans cet exemple, le premier terminal client T1 et le deuxième terminal client T2 forment ensemble un système client SY1 , ce dernier pouvant éventuellement comprendre aussi un ou d’autres terminaux clients, tels que les terminaux T3 et/ou T4 par exemple. Le système client SY1 est configuré pour mettre en œuvre un troisième procédé au sens de l’invention en exécutant les instructions des programmes d’ordinateur PG1 et PG2 par les terminaux clients T1 et T2. Selon un exemple particulier représenté en figure 1, le serveur de médiation SV2 comprend un processeur 20, une mémoire volatile (RAM) 22, une mémoire non volatile 24, une interface de communication INT3 et une mémoire non volatile réinscriptible MR3.
La mémoire 24 est par exemple une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le serveur de médiation SV2, et sur lequel est enregistré un troisième programme d’ordinateur PG3 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG3 comporte des instructions pour l’exécution des étapes d’un quatrième procédé selon un mode de réalisation particulier, comme décrit plus en détail ultérieurement.
Le serveur de médiation SV2 est apte à utiliser son interface de communication INT3 pour communiquer avec les terminaux clients T 1 et T2. Comme déjà indiqué, la nature de cette interface est fonction du type de réseau de communication utilisé. Dans cet exemple, le serveur de médiation SV2 est également apte à communiquer au moyen de son interface de communication INT3 avec les terminaux clients T3 et/ou T4, bien que des mises en œuvre sans ces terminaux clients supplémentaires soient possibles comme déjà indiqué.
La mémoire non volatile réinscriptible MR3 (par exemple de type flash ou EEPROM) est apte à stocker des données de marquage DM et des données de capacité audio DTA. Les données de marquage DM comprennent au moins un code de marquage numérique WT en association avec un identifiant ID d’un terminal client respectif auquel a été attribué ledit code de marquage numérique WT. Les données de marquage DM peuvent ainsi comprendre une pluralité de couples (ID, WT), un code de marquage numérique WT distinct étant attribué à chaque terminal client.
Le processeur 20 utilise par exemple la mémoire volatile 22 pour contrôler les différents composants (mémoires, interface de communication,...) et pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du serveur de médiation SV2, y compris pour exécuter le programme d’ordinateur PG3 lors de la mise en œuvre du quatrième procédé de l’invention.
La nature et la configuration des différents éléments (composants, données, etc.) mentionnés ci-avant en relation avec les terminaux clients et le serveur de médiation SV2 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 2-8. A noter que les éléments représentés en figure 1 ne constituent que des exemples de réalisation particuliers, d’autres mises en œuvre étant possibles dans le cadre de l’invention. L’homme du métier comprend en particulier que certains éléments de l’environnement considéré ne sont décrits ici que pour faciliter la compréhension de l’invention, ces éléments n’étant pas nécessaires pour mettre en œuvre l’invention. Comme représenté en figure 2 selon un mode de réalisation particulier, le processeur 2 piloté par le programme d’ordinateur PG1 met ici en œuvre un certain nombre de modules dans le premier terminal client T1 , à savoir : un module d’obtention MD2, un module d’envoi MD4, un module de réception MD6, un module de contrôle MD8, et éventuellement aussi un module de test acoustique MD10.
Le module d’obtention MD2 est configuré pour obtenir un flux de données audio FX1 marquées par intégration d’un code de marquage numérique WT1 dans un premier flux de données audio par tatouage numérique. Comme décrit par la suite, ce flux de données audio marquées FX1 peut être obtenu de diverses manières par le premier terminal client T1. Le module d’envoi MD4 est configuré pour envoyer le flux de données audio marquées FX1 au serveur de conférence audio et/ou vidéo SV1.
Le module de réception MD6 est configuré pour recevoir, en provenance du serveur de médiation SV1 , des données de capacité audio DTA représentatives de si ledit au moins un deuxième terminal client T2 a détecté le code de marquage numérique WT 1 dans un flux de données audio FX reçu du serveur de conférence audio et/ou vidéo SV1.
Le module de contrôle MD8 est configuré pour déclencher au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio DTA reçues. Comme expliqué par la suite, la ou les actions réalisées peuvent être de diverses natures et peuvent être adaptées selon le cas. Ladite au moins une action de gestion peut comprendre, par exemple, la restitution, par l’interface utilisateur IU1 du premier terminal client T1 , d’informations qui sont fonction des données de capacité audio DTA reçues et qui indiquent si ledit au moins un deuxième terminal client T2 est apte à recevoir un flux de données audio FX du premier terminal client T 1.
Le module de test acoustique MD10 peut en outre être configuré pour réaliser un test acoustique de l’équipement audio du premier terminal client T1 , en particulier pour réaliser un test acoustique du microphone MIC1 et/ou du haut-parleur HP1.
Comme représenté en figure 3 selon un mode de réalisation particulier, le processeur 10 piloté par le programme d’ordinateur PG2 met ici en œuvre un certain nombre de modules dans le deuxième terminal client T2, à savoir : un module de réception MD20, un module de détection MD22, un module d’envoi MD24, et éventuellement aussi un module de test acoustique MD26.
Le module de réception MD20 est configuré pour recevoir, en provenance du serveur de conférence audio et/ou vidéo, un flux de données audio marquées notées FX2.
Le module de détection MD22 est configuré pour détecter, dans le flux audio marquées FX2, un code de marquage numérique WT (WT 1 par exemple), ce dernier étant intégré dans le flux de données audio FX2 par tatouage numérique.
Le module d’envoi MD24 est configuré pour envoyer, au serveur de médiation SV2, une notification indiquant la détection du code de marquage numérique WT (WT1 par exemple), ladite notification comprenant le code de marquage numérique en association avec l’identifiant ID2 du deuxième terminal client T2.
Le module de test acoustique MD26 peut en outre être configuré pour réaliser un test acoustique de l’équipement audio du deuxième terminal client T2, en particulier pour réaliser un test acoustique du microphone MIC2 et/ou du haut-parleur HP2.
Comme représenté en figure 4 selon un mode de réalisation particulier, le processeur 20 piloté par le programme d’ordinateur PG3 met ici en œuvre un certain nombre de modules dans le serveur de médiation SV2, à savoir : un module d’envoi MD40, un premier module de détermination MD42, un deuxième module de détermination MD44 et un module d’envoi MD46.
Le module d’envoi MD40 est configuré pour envoyer au premier terminal client T1 un code de marquage numérique WT1 attribué au premier terminal client T1 et enregistrer, dans des données de marquage DM du serveur de médiation SV2, en association avec l’identifiant ID1 du premier terminal client T1. Dans l’exemple considéré ici, les données de marquage DM sont stockées dans la mémoire non volatile MR3.
Le premier module de détermination MD42 est configuré pour déterminer, à partir des données de marquage DM enregistrées, si une notification indiquant que le deuxième terminal client T2 a détecté le code de marquage W1 est reçue en provenance du deuxième terminal client T2, cette notification comprenant le code de marquage numérique W1 en association avec l’identifiant ID2 du deuxième terminal client T2.
Le deuxième module de détermination MD44 est configuré pour déterminer, à partir d’un résultat de la détermination réalisée par le premier module de détermina MD42, des données de capacité audio DTA2 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX en provenance du premier terminal client T 1.
Le module d’envoi MD46 est configuré pour envoyer au premier terminal client T1 les données de capacité audio DTA2 déterminées par le deuxième module de détermination MD44.
Selon un exemple particulier, le module d’envoi MD46 est en outre configuré pour envoyer au premier terminal client T1 des données de capacité acoustique DTB2 du deuxième terminal audio T2, ces données de capacité acoustique DTB2 pouvant caractériser l’équipement acoustique du deuxième terminal client T2, et en particulier son microphone MIC2 et/ou son hautparleur HP2.
La configuration et le fonctionnement des modules MD2-MD10 du premier terminal client T1 , des modules MD20-MD26 du deuxième terminal client T2 et des modules MD40-MD46 du serveur de médiation SV2 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 5-8. A noter que les modules MD2-MD10, MD20-MD26 et MD40-MD46 tels que représentés dans les figures 2-4 ne constituent que des exemples de mise en œuvre non limitatifs de l’invention.
Un mode de réalisation particulier est à présent décrit en référence à la figure 5. Plus précisément, le premier terminal client T1 et le deuxième terminal client T2 tels que précédemment décrits en référence aux figures 1-3 mettent en œuvre respectivement un premier procédé et un deuxième procédé en exécutant les programmes d’ordinateur PG1 et PG2. Ces premier et deuxième procédés forment collectivement un troisième procédé mis en œuvre par le système SY 1 représenté en figure 1. De plus, le serveur de médiation SV2 tels que précédemment décrit en référence aux figures 1 et 4 met en œuvre un quatrième procédé en exécutant le programme d’ordinateur PG3.
Les utilisateurs UR1 et UR2 utilisent respectivement les terminaux clients T1 et T2 pour communiquer ensemble, au moins par audio, au cours d’une conférence audio et/ou vidéo. Pour ce faire, on considère qu’une session de communication est établie par les terminaux clients T1 et T2 en coopération avec le serveur de conférence audio et/ou vidéo SV1 qui gère les flux de données audio FX entre le premier terminal client T1 et le deuxième terminal client T2 au cours d’une conférence audio et/ou vidéo.
Selon un exemple particulier, au cours d’une étape D2 d’envoi (figure 5), le serveur de médiation SV2 envoie un code de marquage numérique WT1 qui est reçu par le premier terminal client T1 en B2. Ce code de marquage numérique WT 1 , qui peut se présenter sous diverses formes, est attribué au premier terminal client T1. Ce code de marquage numérique WT1 est un code (ou marqueur) qui peut être intégré par tatouage numérique (dit aussi « watermarking » en anglais) dans un flux de données audio. Au cours d’une étape B4 d’obtention, le premier terminal T 1 obtient un flux de données audio FX1 , ces données audio étant marquées par intégration du code de marquage numérique (appelées aussi « marque ») WT1 dans un flux de données audio, par exemple par tatouage numérique. La technique de tatouage numérique permet d’insérer des informations de marquage dans des données hôtes, en l’espèce des données audio, de sorte par exemple que ces informations de marquage ne soient pas perceptibles (audibles) pour un utilisateur. Pour ce faire, les bits du code de marquage numérique sont encodés dans le flux de données audio qui sert de signal porteur.
Selon un exemple particulier, le premier terminal client T 1 détermine ou génère (B4) le flux de données audio marquées FX1 à partir du code de marquage numérique WT1 reçu en B2, en intégrant par tatouage numérique le code de marquage numérique WT 1 dans un premier flux de données audio par tatouage numérique.
A noter que des variantes sont toutefois possibles selon lesquelles le premier terminal client T1 obtient en B4 le flux de données audio marquées FX1 d’une autre manière. Selon un exemple particulier, le premier terminal client T1 ne reçoit pas le code de marquage numérique WT1 depuis le serveur de médiation DV2 mais obtient ce code en B2 d’une autre manière, par exemple en consultant sa mémoire MR1 dans laquelle est préenregistré ledit code WT 1 . Le premier terminal client T 1 peut alors insérer le code de marquage numérique WT1 , par exemple par tatouage numérique, dans un flux de données audio FX pour obtenir le flux de données audio marquées FX1. Selon encore une autre variante, le flux de données audio marquées FX1 est préenregistré dans une mémoire (par exemple MR1) du premier terminal client T1 et ce dernier consulte sa mémoire pour obtenir en B4 le flux de données audio marquées FX1 , de sorte que l’étape B2 de réception n’est non plus nécessaire.
Quelle que soit la manière dont le premier terminal client T1 obtient (B4) le flux de données audio marquées FX1 , on suppose que le serveur de médiation SV2 enregistre dans sa mémoire (ici la mémoire MR2), au cours d’une étape D3 d’enregistrement (figure 5), des données de marquage DM associant l’identifiant ID1 du premier terminal client T1 avec le code de marquage numérique WT1 attribué audit premier terminal client T 1 .
Au cours d’une étape B6 d’envoi, le premier terminal client T1 envoie le flux de données audio marquées FX1 au serveur de conférence SV2. Le serveur de conférence SV2 reçoit le flux de données audio marquées FX1 au cours d’une étape A6 de réception.
Le serveur de conférence SV1 envoie ensuite (étape A8, figure 5) au deuxième terminal client T2 un deuxième flux de données audio marquées FX2 comportant le code de marquage numérique WT1 intégré par exemple par tatouage numérique. Pour ce faire, le serveur de conférence SV1 détermine au préalable le flux de données audio marquées FX2 à partir d’un traitement du flux de données audio marquées FX1 reçues en A6. Dans l’exemple considéré ici, le flux de données audio marquées FX2 comprend le flux de données audio marquées FX1. En particulier, le flux de données audio marquées FX2 peut être un flux de données audio mixées généré par le serveur de conférence SV1 en mixant (ou combinant) le flux de données audio marquées FX1 reçu en A6 avec au moins un autre flux de données audio émis par un autre terminal client, par exemple par le deuxième terminal client T2. Le serveur de médiation SV2 peut ainsi mixer les flux audio provenant des différents terminaux clients lorsque les utilisateurs parlent ou émettent des sons de sorte à redistribuer les flux audio à l’ensemble des participants.
Selon un exemple particulier, le serveur de conférence SV1 décode (à partir de codées) chaque flux de données audio qu’il reçoit en provenance des terminaux clients (y compris le flux de données audio marquées FX1), puis mixe les données audio ainsi décodées pour générer un flux de données audio mixées qui sont marquées puisqu’elles intègrent le code de marquage numérique WT 1. Le serveur de conférence SV1 génère ensuite (à partir de codées) le flux de données audio marquées FX2 en réencodant ces données audio mixées.
On considère à présent que le deuxième terminal client T2 reçoit, au cours d’une étape C8 de réception, le flux de données audio marquées FX2 provenant du serveur de conférence SV1.
Au cours d’une étape C10 de détection, le deuxième terminal client T2 détecte alors le code de marquage numérique WT1 intégré dans le flux de données audio marquées FX2, par exemple par tatouage numérique. Pour ce faire, le deuxième terminal client T2 analyse le flux de données audio entrant et vérifie si ce flux contient un code de marquage numérique (ou une marque). On suppose dans cet exemple que le deuxième terminal client T2 est capable de reconnaître un code de marquage numérique WT mais ne connaît pas le terminal client associé à chaque code de marquage numérique WT (bien que d’autres exemples soient possibles).
A noter qu’il n’est pas nécessaire que le deuxième terminal client T2 restitue le flux de données audio marquées FX2 sous forme acoustique au moyen dans cet exemple du haut-parleur HP2, bien que cela soit possible. La restitution sonore du flux audio FX2 peut toutefois être utile lorsque au moins l’un des participants à la conférence audio et/ vidéo est en train d’émettre des sons.
Au cours d’une étape C12 d’envoi, le deuxième terminal client T2 envoie au serveur de médiation SV2 une notification NF1 indiquant la détection du code de marquage numérique WT1 , cette notification NF1 comprenant le code de marquage numérique WT1 en association avec l’identifiant ID2 du deuxième terminal client T1. Le serveur de médiation SV2 reçoit la notification NF1 au cours d’une étape D12 (figure 5) de réception.
Au cours d’une étape D14 de détermination, le serveur de médiation SV2 détermine, à partir des données de marquage DM enregistrées dans sa mémoire MR3, si une notification NF1 - indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 - est reçue en provenance du deuxième terminal client T2, cette notification NF1 comprenant le code de marquage numérique WT1 en association avec l’identifiant ID2 du deuxième terminal client T2.
Comme décrit par la suite, l’exécution du quatrième procédé par le serveur de médiation SV2 peut varier à ce stade en fonction du résultat de l’étape D14 de détermination. Le résultat de cette étape D14 peut être positif (le serveur de médiation SV2 détecte la notification NF1) ou négatif (le serveur de médiation SV2 ne détecte pas la notification NF1). Pour ce faire, si le serveur de médiation SV2 reçoit en provenance du deuxième terminal client T2 une notification indiquant la détection d’un code de marquage numérique, il consulte ses données de marquage DM pour déterminer si cette notification comprend le code de marquage numérique WT1 associée à l’identifiant ID1 dans ses données de marquage DM. Dans l’affirmative, le serveur de médiation SV2 détermine que le deuxième terminal client T2, identifié par l’identifiant ID2 compris dans la notification NF1 reçue, a détecté le code de marquage numérique WT1 associé au premier terminal client T1.
Selon un exemple particulier, le serveur de médiation SV2 détermine en D14 une absence de réception de la notification NF1 en D12 si aucune dite notification, indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 , n’est reçue dans un premier délai DL1 à compter d’un instant de référence tO. Autrement dit, si le premier délai DL1 expire sans que la notification NF1 n’ait été reçue par le serveur de médiation SV2, ce dernier détecte qu’aucune notification NF1 indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 n’a été reçue. Comme décrit plus en détail ultérieurement, cet instant de référence peut varier selon le cas, et peut correspondre par exemple à un instant au cours duquel l’envoi D2 est réalisé.
Au cours d’une étape D16 de détermination, le serveur de médiation SV2 détermine ensuite, à partir d’un résultat de la détermination D14, des données de capacité audio DTA2 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX en provenance du premier terminal client T1. Autrement dit, les données de capacité audio DTA2 caractérisent la capacité du deuxième terminal client T2 à recevoir un flux de données audio FX émis par le premier terminal client T1 au cours de la conférence audio et/ou vidéo.
En effet, la détection par le deuxième terminal client T2 du code de marquage numérique WT1 indique que le deuxième terminal client T2 a été en mesure de recevoir le flux de données audio marquées FX2 comprenant le flux de données audio marquées FX1 émis en B6 par le premier terminal client T 1. En cas de détermination en D14 que la notification NF1 a été reçue, les données de capacité audio DTA2 générées en D16 indiquent par conséquent que le deuxième terminal client T2 est apte à recevoir un flux de données audio émis par le premier terminal client T 1 .
Si le deuxième terminal client T2 n’a pas détecté le code de marquage numérique WT2, cela signifie qu’il n’a pas pu recevoir le flux de données audio marquées FX2 transmis par le serveur de conférence SV1. Autrement dit, un résultat négatif de la détermination D14 signifie que le test de réception d’un flux audio depuis le premier terminal client T1 vers le deuxième terminal client T2 a échoué. Aussi, s’il est déterminé en D14 qu’aucune notification NF1 - indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 - n’a été reçue, les données de capacité audio DTA2 générées en D16 par le serveur de médiation SV2 indiquent que le deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio en provenance du premier terminal client T 1.
Au cours de cette étape D16 de détermination, le serveur de médiation SV2 peut éventuellement mettre à jour des précédentes données de capacité audio DTA2 déjà stockées dans sa mémoire MR3.
Lors d’une étape D18 d’envoi, le serveur de médiation SV2 envoie alors au premier terminal client T1 les données de capacité audio DTA2 déterminées en D16. Selon un exemple particulier, le serveur de médiation SV2 envoie (D18) également au premier terminal client T1 des données de capacité acoustique DTB représentatives de capacités acoustiques du deuxième haut-parleur HP2 couplé au deuxième terminal client T2 à produire une émission (ou sortie) acoustique. Ces données de capacité acoustique DTB peuvent être obtenues de diverses manières par le serveur de médiation SV2, des exemples de réalisation particuliers étant décrits ci-après. Le premier terminal client T 1 reçoit les données de capacité audio DTA2, et le cas échéant les données de capacité acoustique DTB2, au cours d’une étape B20 de réception. Les données reçues peuvent éventuellement être associées à l’identifiant ID2 du deuxième terminal client T2 pour permettre au premier terminal client T 1 de déterminer qu’il s’agit de données caractérisant le deuxième terminal client T2.
Lors d’une étape B22 de gestion, le premier terminal client T 1 déclenche ensuite, à partir des données de capacité DTA2 (et éventuellement des données de capacité acoustique DTB2) reçues, au moins une action de gestion de la conférence audio et/ou vidéo en cours. La ou les actions de gestion exécutées par le premier terminal client T1 peuvent varier selon le cas et consistent à adapter le fonctionnement du premier terminal client T1 en fonction de l’aptitude ou non-aptitude du deuxième terminal client T2 à recevoir un flux de données audio émis par le premier terminal client T1 (et éventuellement l’aptitude à restituer les sons correspondants) lors de la conférence audio et/ou vidéo. Selon un exemple particulier, lors de l’étape B22 de gestion, le premier terminal client T1 restitue (ou rend), au moyen de son interface utilisateur IU1 , des informations IF1 qui sont fonction des données de capacité audio DTA2 reçues (et aussi éventuellement des données de capacité acoustique DTB2 reçues), ces informations IF1 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX (et éventuellement s’il est apte à restituer les sons correspondants). Cette restitution, qui peut pendre diverses formes (restitution visuelle, auditive, etc.) peut aider, au moins dans certains modes de réalisation, l’utilisateur UR1 è déterminer s’il est, ou va être, bien entendu lorsqu’il parle ou émet des sons au cours de la conférence audio et/vidéo.
Selon un exemple particulier, lors de l’étape B22 de gestion, le premier terminal client T1 modifie au moins un paramètre de fonctionnement ou une configuration audio selon laquelle il fonctionne pour échanger des flux de données audio en coopération avec le serveur de conférence SV1 au cours de la conférence.
Selon un exemple particulier, lors de l’étape B22 de gestion, le premier terminal client T1 réalise un basculement depuis la conférence audio et/ou vidéo en cours vers une deuxième conférence audio et/ou vidéo (conférence de secours ou de remplacement) dans laquelle coopèrent également au moins les terminaux T1 et T2 pour s’échanger des flux audio. Le premier terminal T1 peut par exemple coopérer avec au moins le deuxième terminal client T2 dans plusieurs conférences simultanément, ou encore dans plusieurs conférences successives sur une période donnée. Dans ces deux cas, un basculement vers une nouvelle conférence peut permettre au premier terminal client T1 de résoudre un problème de réception audio identifié à partir des données DTA2 (et éventuellement DTB2) reçues en B20 (figure 5).
Selon un exemple particulier, le serveur de conférence SV1 peut envoyer le flux de données audio mixées FX2 à une pluralité de deuxièmes terminaux clients, par exemple à T2, T3 et T4. Dans ce cas, les terminaux clients T3 et T4 peuvent traiter le flux de données audio marquées FX2 en exécutant les étapes C8-C12 de la même manière que le deuxième terminal client T2. Le serveur de médiation SV2 peut exécuter alors par exemple les étapes D12, D14 et D16 pour au moins un (par exemple chacun) des deuxièmes terminaux clients T2-T4 de sorte à générer en D16 des données de capacité audio DTA2, DTA3 et/ou DTA4 indiquant respectivement si ledit deuxième terminal client a détecté le code de marquage numérique WT1 dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo SV1. Le serveur de médiation SV2 peut ainsi envoyer en D18, au premier terminal client T1 , les données de capacité audio DTA2, DTA3 et/ou DTA4 (ainsi qu’éventuellement des données de capacité acoustique DTB2, DTB3 et DTB4 associées respectivement aux terminaux T2, T3 et T4). De cette manière, la ou les actions de gestion exécutées en B22 par le premier terminal client T1 peuvent être fonction des différentes données reçues.
Comme déjà indiqué, il n’est pas toujours aisé pour un utilisateur participant à une conférence audio et/ou vidéo de savoir s’il est, ou s’il va être, bien entendu des autres participants lorsqu’il parle ou qu’il s’apprête à parler lors d’une conférence audio et/ vidéo. Divers problèmes matériels, logiciels ou autres sont susceptibles de faire obstacle à une bonne transmission d’un flux audio depuis le terminal client du locuteur considéré vers les terminaux clients d’autres participants. L’usage dans au moins certains modes de réalisation de l’invention de la technique de marquage numérique (dit « watermarking ») peut aider à tester de façon fiable et robuste la capacité de terminaux clients à recevoir des flux de données audio en provenance d’un terminal client donné au cours d’une conférence audio et/ou vidéo. L’invention permet donc de limiter les risques qu’un utilisateur parle sans être entendu par un autre participant à la conférence audio et/ou vidéo.
Comme décrit ci-avant, l’invention implique l’envoi par un premier terminal client d’un flux de données audio intégrant un code de marquage numérique. Un deuxième terminal tiers ne peut détecter le code de marquage que s’il a la capacité de recevoir et traiter correctement le flux de données audio provenant du premier terminal client. Si le deuxième terminal client détecte le code de marquage numérique, il en informe alors le serveur de médiation SV2 qui met à jour ses données de capacité audio, afin qu’elles indiquent que le deuxième terminal client est capable de recevoir les flux de données audio émis par le premier terminal.
La technique de marquage numérique peut impliquer l’usage d’un flux de données audio pour porter le code de marquage numérique. Ce code, qui peut être inaudible pour un utilisateur du deuxième terminal client, sert à marquer le flux de données audio de façon fiable et sécurisée pour vérifier que la transmission du flux audio depuis le premier terminal client vers le deuxième terminal client est opérationnelle.
Comme indiqué ci-avant, le serveur de conférence SV1 est par exemple en charge de la gestion des échanges de flux de données audio entre le premier terminal client T1 et les deuxièmes terminaux clients T2-T4. En particulier, le serveur de conférence SV1 peut être configuré pour traiter tous les flux de données audio émis par les terminaux clients de sorte à produire un flux de données audio mixées FX2 qui est distribué à l’ensemble des terminaux clients (ou au moins au deuxième terminal client T2). Le traitement réalisé par le serveur de conférence SV1 peut comprendre en particulier un décodage des flux de données audio FX reçus (dont le flux FX1 ) et un mixage de ces flux de sorte à produire un flux de données audio mixées qui est ré-encodé avant envoi aux terminaux clients. La technique de marquage par tatouage numérique peut offrir, au moins dans certains modes de réalisation, une bonne robustesse dans la mesure où le code de marquage numérique WT1 présent dans le flux de données audio marquées FX1 reçu (A6, figure 5) en provenance du premier terminal client T 1 résiste par nature aux différents traitements de décodage, mixage encodage etc. réalisés par le serveur de médiation SV1. Ainsi, le flux de données audio mixées FX2 envoyé en A8 au deuxième terminal client T2 comprend le même code de marquage numérique WT 1 que celui présent dans le flux de données audio marquées FX1 reçu en A6 en provenance du premier terminal client T 1.
Des exemples particuliers de mise en œuvre des procédés décrits ci-avant en référence à la figure 5 sont à présent décrits en relation avec les figures 6-8. Pour ce faire, le premier terminal client T1 et le deuxième terminal client T2 (figures 1-3) exécutent respectivement les programmes d’ordinateur PG1 et PG2 pour mettre en œuvre un premier procédé et un deuxième procédé. Comme déjà décrit, ces premier et deuxième procédés forment collectivement un troisième procédé mis en œuvre par le système SY1 représenté en figure 1. De plus, le serveur de médiation SV2 (figures 1 et 4) met en œuvre un quatrième procédé en exécutant le programme d’ordinateur PG3.
On suppose à nouveau que les utilisateurs UR1 et UR2 utilisant respectivement les terminaux clients T1 et T2 souhaitent communiquer ensemble, au moins par audio, au cours d’une conférence audio et/ou vidéo. Pour ce faire, au cours d’une étape S2 d’établissement de session, les terminaux clients T1 et T2 établissent chacune une session de communication en coopération avec le serveur de conférence SV1 gérant des échanges de flux de données audio entre le premier terminal client T1 et le deuxième terminal client T2.
A noter que dans les exemples de réalisation qui suivent, le premier terminal client T 1 teste la réception audio d’un seul deuxième terminal client T2, bien que d’autres exemples soient possibles où la réception audio d’au moins deux deuxième terminaux client T2 est testée. Dans ce cas, chaque deuxième terminal client exécute le deuxième procédé de la même manière que le deuxième terminal client T2.
Lors de l’établissement S2 des sessions de communication (ou après), un identifiant unique ID est attribué à chaque terminal client participant à la conférence audio et/ou vidéo. Ainsi, lors d’étapes B40 et C40 d’obtention, les premier et deuxième terminaux clients obtiennent respectivement leur identifiant respectif ID1 et ID2. La manière dont ces terminaux obtiennent leur identifiant unique peut varier selon le cas. Selon un exemple particulier, c’est le serveur de conférence SV1 qui transmet aux terminaux clients T1 et T2 leur identifiant respectif. Selon un autre exemple, ce sont les utilisateurs UR1 et UR2 qui définissent respectivement les identifiants ID1 et ID2 (ou ceux-ci sont défini par défaut par leur terminal client).
Comme déjà indiqué, le premier terminal client T1 peut obtenir (B4, figure 5) le flux de données audio marquées FX1 de diverses manières selon l’implémentation considérée. Dans cet exemple, le premier terminal client T1 envoie (B42, figure 6) au serveur de médiation SV2 une requête RQ1 de code de marquage numérique (ou requête de demande de code), cette requête RQ1 comprenant l’identifiant ID1 du premier terminal client T1. Le serveur de médiation SV2 reçoit cette requête RQ1 au cours d’une étape D42 de réception.
Le serveur de médiation SV2 obtient (D44) ensuite un code de marquage numérique WT1 attribué au premier terminal client T1. Pour ce faire, le serveur de médiation SV2 peut déterminer ou générer le code de marquage numérique WT 1 d’une quelconque manière appropriée. Ce code de marquage WT 1 peut prendre diverses formes et peut par exemple être une série de bits. Le serveur de médiation SV2 envoie (D46) ensuite le code de marquage numérique WT 1 au premier terminal client T 1. En réponse à la requête RQ1 , le premier terminal client T1 reçoit ainsi en B46 le code de marquage numérique WT 1 qui lui est attribué. Selon un exemple particulier, un code de marquage numérique WT distinct est attribué par le serveur de médiation SV2 à chaque deuxième terminal client T2-T4.
Lors d’une étape D48 d’enregistrement, le serveur de médiation SV2 enregistre, dans des données de marquage DM, le code de marquage numérique WT1 en association avec l’identifiant ID1 du premier terminal client T1 . A noter que cette étape D48 d’enregistrement peut être réalisée à divers moments, par exemple avant ou après l’étape D46 d’envoi, voire même avant l’étape D4 de réception de la requête RQ1 (dans ce dernier cas, le serveur de médiation SV2 a défini l’association ID1/WT 1 avant la réception de la requête RQ1).
Selon un exemple particulier, le premier terminal client T1 détermine, lors de l’établissement S2 de la session de communication (ou tout du moins avant l’envoi B42 de la requête RQ1 ), un identifiant IDC de la conférence audio. Le premier terminal client T1 peut alors insérer dans la requête RQ1 cet identifiant IDC de la conférence audio et/ou vidéo avant l’envoi B42 au serveur de médiation SV2, de sorte à permettre par exemple au serveur de médiation SV2 d’enregistrer le code de marquage numérique WT 1 en association avec l’identifiant ID1 du premier terminal client T 1 et l’identifiant IDC de la conférence audio et/ou vidéo.
L’identifiant IDC de la conférence permet au serveur de médiation SV2 de reconnaître les requêtes associées à la conférence audio et/ou vidéo en cours, de générer un code de marquage numérique WT unique pour au moins un terminal client (voire pour chacun d’entre eux) participant à ladite conférence. De cette manière, le serveur de médiation SV2 peut par exemple superviser le test de réception de flux audio pour une pluralité de conférences audio et/ vidéo distinctes, y compris lorsque le premier terminal client T1 participe à plusieurs conférences simultanément ou successivement sur une période donnée.
Selon des variantes, le serveur de médiation SV2 réalise les étapes D44, D46 et D48 sans que cela soit sollicité par le premier terminal client T1 , c’est-à-dire indépendamment d’une quelconque requête RQ1 émise par le premier terminal client T 1.
Par ailleurs, comme déjà indiqué, le premier terminal client T1 peut obtenir le flux de données audio marquées FX1 de diverses manières. Selon l’exemple représenté en figure 6, le premier terminal client T1 génère ou détermine (B50) un flux de données audio marquées FX1 en intégrant (ou insérant) par tatouage numérique le code de marquage numérique WT 1 dans un premier flux de données audio FXO qui sert de flux porteur. Ce premier flux de données audio FXO peut être un flux de données audio de test, c’est-à-dire un flux dont les données audio sont destinées uniquement à tester la réception audio du deuxième terminal client T2 et qui n’ont pas vocation à être restituées par le deuxième terminal client T2 à son utilisateur UR2.
Selon un exemple particulier, le premier terminal client T 1 génère le premier flux de données audio FXO par émulation d’un bruit aléatoire. Dans cet exemple, cette émulation peut être réalisée tandis que le microphone MIC1 du premier terminal client T 1 est désactivé. Il est ainsi possible de produire un signal porteur pour le code de marquage numérique WT 1 , même si aucun signal acoustique n’est acquis par le microphone MIC1 (par exemple lorsqu’une fonction sourdine, ou « mute » est activée). Selon un exemple particulier, le premier terminal client T 1 génère le premier flux de données audio FXO à partir de données audio utiles, c’est-à-dire à partir de données audio émises par le premier terminal client T1 au cours de la conférence audio et/ou vidéo et destinées à être restituées par le deuxième terminal client T2 à l’utilisateur UR2. Ainsi, le premier flux de données audio FXO peut par exemple être généré à partir de signaux acoustiques (ou sons) acquis par le premier microphone MIC1 couplé au premier terminal client T1. Cette variante permet de tester la réception audio du deuxième terminal client T2 alors que le premier terminal client T1 est en train de capter des sons (par exemple pendant que l’utilisateur UR1 est en train de parler lors de la conférence audio et/ou vidéo).
Selon un exemple particulier, les signaux acoustiques à partir desquels est généré le premier flux de données audio FXO représentent un (ou résultent d’un) bruit de fond acquis par le premier microphone MIC1 , l’intensité de ce bruit de fond étant inférieure à une première valeur d’intensité 11. Le flux de données audio marquées FX1 peut alors être généré en B50 à partir de ce bruit de fond, par exemple lorsque l’utilisateur UR1 du premier terminal client T1 ne parle pas. Cette valeur 11 peut être adaptée par l’homme du métier selon le cas.
Selon un exemple particulier, le premier terminal client T1 déclenche l’envoi B40 de la requête RQ1 de code de marquage numérique sur détection, au moyen de son microphone MIC1 , d’une période de silence d’une durée au moins égale à une première durée D1 , au cours de laquelle un bruit de fond d’une intensité inférieure à ladite première valeur d’intensité 11 est détecté. Une période de silence est par exemple détectée lorsqu’une fonction sourdine (dite « mute ») est activée, cette fonction ayant pour effet de désactiver le microphone MIC1 (blocage de l’acquisition acoustique). Ainsi, le terminal client T1 ne demande un code de marquage numérique WT1 que si l’utilisateur UR1 ne parle pas lors de la conférence audio et/ou vidéo. Il est ainsi possible par exemple d’assister l’utilisateur UR1 lors de la conférence en lui indiquant à l’avance s’il va être bien entendu par le deuxième terminal client T2 dans le cas où il décide de parler. Cette variante peut aider à économiser les ressources de traitement et de réseau en ne réalisant un test de réception audio que pour prédire l’aptitude ou inaptitude du deuxième terminal client T2 à recevoir un flux de données audio avant même que le premier terminal client T1 n’émettre un flux de données audio.
Lors d’une étape B52 d’envoi, le premier terminal client T1 envoie ensuite le flux de données audio marquées FX1 au serveur de conférence SV1. Comme décrit par la suite, cet envoi B52 cause un envoi par le serveur de conférence SV1 , au deuxième terminal client T2, d’un flux de données audio marquées FX2 comprenant le flux de données audio marquées FX1. Le serveur de conférence SV1 reçoit le flux de données audio marquées FX1 au cours d’une étape A52 de réception.
Selon un exemple particulier, le premier terminal client T1 envoie également en B53 une notification NF2 informant de l’envoi B52 du flux de données audio marquées FX1 au serveur de conférence SV1 pour réaliser un test audio. Cette notification NF2, pouvant comprendre l’identifiant ID1 du premier terminal client T1 , est alors reçue au cours d’une étape D53 de réception. Comme décrit par la suite, la réception D53 de la notification NF2 peut marquer le cas échéant un instant de référence tO utilisé par la suite par le serveur de médiation SV2 lors du quatrième procédé.
Le serveur de conférence SV1 réalise ensuite un traitement (A54) à partir du flux de données audio marquées FX1 reçu en A52, et éventuellement à partir d’au moins un autre flux de données audio FX émis par un terminal client autre que le premier terminal client T1 , de sorte à produire un flux de données audio marquées FX2 comprenant le code de marquage numérique WT1. Dans cet exemple, on considère que le serveur de conférence SV1 décode chaque flux de données audio reçu (dont le flux FX1), mixe ou combine les données audio décodées et encode les données audio mixées de sorte à obtenir un flux de données audio marquées FX2 comprenant le code de marquage numérique WT1. Lors d’une étape A56 d’envoi, le serveur de médiation SV1 envoie le flux de données audio marquées FX2 au deuxième terminal client T2. Le deuxième terminal client T2 reçoit le flux de données audio marquées FX2 en C56 et détecte dans ce flux FX2 le code de marquage numérique WT1 en C58, de façon identique respectivement aux étapes C8 et C10 précédemment décrites (figure 5).
Comme déjà indiqué, le deuxième terminal client T2 peut restituer le flux de données audio marquées FX2 sous forme acoustique au moyen dans cet exemple du haut-parleur HP2, bien que des variantes soient possibles sans une telle restitution sonore. Si le deuxième terminal client T2 génère des signaux acoustiques à partir du flux audio FX2, alors le code de marquage numérique WT2 peut ne pas être perceptible pour l’utilisateur UR2 (le code WT2 n’est pas converti en son), de sorte que cela ne gêne pas l’écoute au cours de la conférence.
Lors d’une étape C60 d’envoi, le deuxième terminal client T2 envoie (de façon identique à l’envoi C12, figure 5) une notification NF1 indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 , cette notification NF1 comprenant le code de marquage numérique WT1 en association avec l’identifiant ID2 du deuxième terminal client T2.
Le serveur de médiation SV2 reçoit la notification NF1 au cours d’une étape D62 de réception.
De façon identique à l’étape D14 (figure 5), le serveur de médiation SV2 détermine (D64) alors s’il a reçu une notification NF1 indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1. Comme déjà décrit, le serveur de médiation SV2 peut à cette fin consulter ses données de marquage DM et déterminer en D64 si la notification NF1 reçue comprend le code de marquage numérique WT1 associé à l’identifiant ID1 du premier terminal client T1 dans les données de marquage DM. Le deuxième terminal client T2 n’a donc pas besoin de connaître à quel autre terminal client est associé le code de marquage numérique WT1.
Dans certains modes de réalisation, comme dans cet exemple particulier, le serveur de médiation SV2 utilise un instant de référence tO pour déterminer en D64 si ladite notification NF1 est reçue dans un premier délai DL1 à compter de cet instant de référence tO. Cet instant de référence tO peut, par exemple, correspondre à la réception D53 de la notification NF2 envoyée le cas échéant par le premier terminal client T1 pour prévenir qu’un test audio est réalisé. Il est ainsi possible pour le serveur de médiation SV2 d’être informé lorsque (par exemple à chaque fois) que le premier terminal client T1 effectue un test audio. De multiples tests audio peuvent ainsi être réalisés au cours du temps par le premier terminal client T1 pour tester si l’utilisateur UR1 est, ou va être, bien entendu par le deuxième terminal client T2.
Selon une variante, le serveur de médiation SV2 est configuré pour connaître à l’avance un instant de référence tO au cours duquel le premier terminal client T1 réalise l’envoi B52 du flux de données audio marquées FX1. Selon une variante, le serveur de médiation SV2 utilise en tant qu’instant de référence tO un instant au cours duquel est réalisée l’une quelconque des étapes D42, D44, D46 et D48.
Le serveur de médiation SV2 détermine ainsi que le résultat de la détermination D64 est positif s’il détecte que la notification NF1 émise par le deuxième terminal client T2 est reçue avant expiration d’un premier délai DL1 à compter de cet instant de référence tO. Dans le cas contraire, le serveur de médiation SV2 détermine que le résultat de la détermination D64 est négatif.
Comme déjà décrit en référence à l’étape D16 (figure 5), le serveur de médiation SV2 peut déterminer (D66) ensuite, à partir d’un résultat de la détermination D64, des données de capacité audio DTA2 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX en provenance du premier terminal client T1. Plus précisément, si le résultat de la détermination D64 est positif, le quatrième procédé se poursuit à l’étape D66a, sinon le quatrième procédé se poursuit à l’étape D66b.
Lors de l’étape D66a, le serveur de médiation SV2 détermine, à partir du résultat positif de la détermination D64, des données de capacité audio DTA2 indiquant que le deuxième terminal client T2 est apte à recevoir un flux de données audio en provenance du premier terminal client T 1.
Lors de l’étape D66b, le serveur de médiation SV2 détermine, à partir du résultat négatif de la détermination D64, des données de capacité audio DTA2 indiquant que le deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio en provenance du premier terminal client T 1.
Le serveur de médiation SV2 envoie (D68) ensuite les données de capacité audio DTA2 au premier terminal client T1 comme déjà décrit en référence à l’étape D18 (figure 5). Le premier terminal client T 1 reçoit ainsi en B68 les données de capacité audio DTA2 envoyées par le serveur de médiation SV2. Le premier terminal client T1 peut alors réaliser les étapes D22 et D24 de façon identique aux étapes B20 et B22 comme précédemment décrit en référence à la figure 5.
Selon un exemple particulier, en cas de résultat négatif de la détermination D64 (pas de réception par le serveur de médiation SV2 de la notification NF1 ), le serveur de médiation SV2 peut en outre envoyer (D70) les données de capacité audio DTA2 au deuxième terminal T2 pour lui indiquer que son test de réception audio depuis le terminal client T1 vers le deuxième terminal client T2 a échoué. Le deuxième terminal client T2 reçoit alors les données de capacités audio DTA2 lors d’une étape C70 de réception. En réponse aux données de capacité audio DTA2, le deuxième terminal client T2 peut ainsi réaliser au moins une action de gestion, telle que par exemple restituer (C72a) au moyen de son interface utilisateur IU2 des informations IF2 indiquant l’échec du test de réception audio et/ou modifier (C72b) une configuration audio du deuxième terminal client T2 en vue si possible de résoudre le problème de réception audio. Ce changement de configuration audio peut comprendre par exemple une reconfiguration d’un équipement audio quelconque du deuxième terminal client T2. Un changement de configuration audio peut comprendre par exemple un changement d’une entrée audio utilisée par le deuxième terminal T2 pour recevoir des flux de données audio au cours de la conférence audio et/ou vidéo.
Selon un exemple particulier, le serveur de médiation SV2 exécute le quatrième procédé selon les étapes D2-D18 (figure 5) ou D42-D70 (figure 6) pour une pluralité de deuxièmes terminaux clients, par exemple en coopération avec chacun parmi les terminaux T2, T3 et T4, de sorte à envoyer en D68 au premier terminal client T1 des données de capacité audio DTA2, DTA3 et DTA4 caractérisant respectivement les deuxièmes terminaux clients T2, T3 et T4. En particulier, le serveur de médiation SV2 peut générer, et transmettre en D68 au premier terminal client T 1 , une matrice de capacité audio indiquant pour chaque deuxième terminal client T2-T4 s’il a détecté le code de marquage numérique WT 1 et donc s’il est apte à recevoir un flux de données audio FX émis par le premier terminal client T 1 au cours de la conférence audio et/ou vidéo.
Le premier terminal client T1 peut ainsi réaliser l’étape B22 (figures 5-6) en prenant en compte les données de capacité audio DTA2, DTA3 et DTA4. En particulier, le premier terminal client T1 peut restituer des informations IF1 indiquant si au moins un (par exemple chacun) des deuxièmes terminaux clients T2, T3 et T4 est apte à recevoir un flux de données audio émis par le premier terminal client T 1 durant de la conférence audio et/ou vidéo en cours. De cette manière, l’utilisateur UR1 peut savoir aisément si il est, ou sera, entendu par chacun des participants à la conférence audio et/ou vidéo. Comme déjà décrit précédemment, l’invention permet de tester la capacité d’un ou plusieurs deuxièmes terminaux clients à recevoir un flux de données audio émis par le premier terminal client lors d’une conférence audio et/ou vidéo. L’invention permet donc de limiter les risques que l’utilisateur UR1 ne parle sans être entendu par un autre participant à la conférence audio et/ou vidéo.
Toutefois, même si par exemple le deuxième terminal client T2 est effectivement capable de recevoir un flux de données audio FX émis par le premier terminal client T 1 , des problèmes liés aux équipements acoustiques du premier terminal client et/ou du deuxième terminal client peuvent faire obstacle dans la chaîne de transmission de communications audio depuis le microphone MIC1 du premier terminal client T 1 jusqu’au haut-parleur HP2 du deuxième terminal client T2. Dans ce cas, l’utilisateur UR1 n’a pas la garantie que l’utilisateur UR2 peut ou pourra l’entendre même si le deuxième terminal client T2 est capable de recevoir un flux de données audio émis par le premier terminal client T 1.
Aussi, selon un exemple, l’invention peut aussi comprendre un test acoustique d’au moins l’un parmi le premier terminal client T1 et le ou les deuxièmes terminaux clients T2-T4, afin de compléter les données de capacité audio DTA2 générées par le serveur de médiation SV2 (étapes D16 et D66, figures 5-6) avec des données de capacité acoustique DTB.
Selon un exemple représenté en figure 7, le premier terminal client T1 réalise un test acoustique du microphone MIC1 auquel il est couplé (et plus généralement un test de l’équipement acoustique du premier terminal client T1 ), en exécutant les étapes B80-B88 au cours du premier procédé tel que décrit en référence aux étapes B2-B24 (figure 5) ou aux étapes B40-B68 (figure 6). Ce test permet plus généralement de tester l’ensemble de la chaîne acoustique (incluant le haut-parleur HP1 et le microphone MIC1 ) du premier terminal client T 1 .
Plus particulièrement, le premier terminal client T 1 active (B80) son microphone MIC1 s’il n’est pas déjà actif, et peut éventuellement désactiver (B82) une fonction F1 d’annulation d’écho dans le cas où une telle fonction est active. Une fonction d’annulation d’écho est en effet susceptible de faire obstacle au bon déroulement du test acoustique du microphone MIC1. En particulier, l’annulation le cas échéant d’une fonction F1 d’annulation d’écho permet une bonne acquisition acoustique par le microphone MIC1 d’une émission (ou sortie) acoustique du haut-parleur HP1 couplé au premier terminal client T 1 . Lors d’une étape B84 de génération, le premier terminal client T1 génère un signal acoustique de test noté SA1 (figure 1) au moyen du haut-parleur HP1 . Pour cela, le premier terminal client T1 peut fournir en entrée du haut-parleur un quelconque flux de données audio de test, de sorte à produire un signal acoustique de test SA1 en sortie du haut-parleur HP1.
Le signal acoustique de test SA1 est de préférence un signal (émission sonore) inaudible à l’oreille humaine (par exemple dans les hautes fréquences) afin de ne pas gêner l’utilisateur UR1 lors de la conférence audible et/ou vidéo, mais peut éventuellement être un signal audible. Selon un exemple particulier, le signal acoustique de test SA1 est émis à une fréquence d’au moins 20 KHz. Il peut s’agir d’un signal mono-fréquence ou d’un signal sinusoïdal, bien que d’autres implémentations soient possibles. A titre d’exemple, le signal acoustique de test SA1 ainsi généré présente une fréquence d’échantillonnage d’au moins 44,1 KHz.
Le signal acoustique de test SA1 est également émis de préférence pendant un temps court (par exemple pendant une durée maximum de 250 ms), afin d’éviter de déranger éventuellement l’utilisateur UR1 et de sorte à économiser les ressources et accélérer autant que possible le processus de test acoustique tout en s’assurant que ce signal acoustique de test SA1 est détectable par le microphone MIC1.
Au cours d’une étape B86 d’acquisition d’acoustique, le premier terminal client T1 fait une acquisition acoustique au moyen du microphone MIC1 tandis que le haut-parleur HP1 émet le signal acoustique de test SA1 , de sorte à tenter de capter ce signal acoustique de test SA1. Le premier terminal client T 1 détermine (B88) alors, à partir d’un résultat de l’acquisition acoustique B86, des données de capacité acoustique DTB1 caractérisant des capacités acoustiques du microphone MIC1 (et plus généralement de l’équipement acoustique du premier terminal client T 1 ).
Plus particulièrement, selon un exemple, le premier terminal client T1 acquière en B86 un flux de données audio de test DA1 produit par le microphone MIC1 à partir d’un signal acoustique capté par ledit microphone. Le premier terminal client T 1 analyse (B86) ensuite, à partir du flux de données audio de test DA1 , un signal acoustique capté par le microphone MIC1. Le premier terminal client T1 peut en particulier comparer le signal acoustique capté d’une part, avec le signal acoustique de test SA1 généré en B84 d’autre part. A partir d’un résultat de cette comparaison, le premier terminal client T 1 évalue s’il y a correspondance entre le signal acoustique capté et le signal acoustique de test SA1. Les données de capacité acoustique DTB1 peuvent alors être fonction d’un degré de correspondance entre ces deux signaux. S’il y a correspondance, cela signifie que le microphone MIC1 (et plus généralement l’équipement acoustique du premier terminal client T1) est fonctionnel. Dans le cas contraire, cela signifie que le microphone MIC1 est susceptible d’être défectueux, ou tout du moins que l’équipement acoustique du premier terminal client T1 n’est pas fonctionnel.
Le premier terminal client T1 peut ainsi réaliser l’étape B22 de gestion (figures 5-6) en fonction également des données de capacité acoustique DTB1 obtenues en B88. Comme déjà indiqué, les informations IF1 restituées le cas échéant par le premier terminal client T1 lors de l’étape B24 de restitution peuvent être représentatives non seulement des données de capacité audio DTA2 reçues mais également des données de capacité acoustiques DTB1 du premier terminal client T 1. Selon un exemple, lors de l’étape B22 de gestion, le premier terminal client T1 peut transmettre au serveur de médiation SV2 les données de capacité acoustique DTB1 obtenues en B88. Le serveur de médiation SV2 peut alors transmettre également ces données de capacité acoustique DTB1 au deuxième terminal client T2, ou plus généralement à chaque deuxième terminal client T2-T4.
Le test acoustique (B80-B88, figure 7) peut être réalisé à divers stades du premier procédé mis en œuvre par le premier terminal client T1 (figures 5-6). Selon un exemple particulier, le premier terminal client T1 déclenche ce test acoustique sur détection de la réception B2 (figure 5) ou B46 (figure 6) du code de marquage numérique WT1 transmis par le serveur de médiation SV2, ou tout du moins avant l’étape B4 d’obtention (figure 5) ou l’étape B50 de génération (figure 6) du flux de données audio marquées FX1.
Une fois le test acoustique du premier terminal client T1 achevé, le terminal T1 peut réactiver le cas échéant la fonction F1 d’annulation d’écho, afin d’éviter d’éventuelles perturbations de l’acquisition acoustique du microphone MIC1 lors de la conférence audio et/ou vidéo.
Le premier terminal client T1 est par exemple configuré pour déclencher l’envoi B6 ou B52 du flux de données audio marquées FX1 que si le test acoustique B80-B88 est passé avec succès, c’est-à-dire s’il indique que le microphone MIC1 est fonctionnel. Ainsi, si le test acoustique du microphone MIC1 du premier terminal client T1 échoue, ce dernier ne poursuit pas le test audio, ou éventuellement sélectionne la technique d’émulation d’un bruit aléatoire telle que décrite précédemment pour générer en B50 (figure 6) le flux de données audio marquées FX1. Il est ainsi possible d’économiser les ressources des terminaux clients T 1 et T2, du réseau ainsi que celles du serveur de médiation SV2 en évitant d’exécuter inutilement un test audio à partir du premier terminal client T1 alors que même que son microphone MIC1 est susceptible d’être défectueux. Le recours à la technique de l’émulation peut aider en outre de s’assurer que le test audio est réalisé correctement alors même que le microphone MIC1 est susceptible d’être défectueux.
Selon un exemple représenté en figure 8, le premier terminal client T1 réalise un test acoustique du haut-parleur HP2 auquel il est couplé (et plus généralement un test de l’équipement acoustique du deuxième terminal client T2), en exécutant les étapes C100-C108 au cours du deuxième procédé tel que décrit en référence aux étapes C8-C12 (figure 5) ou aux étapes C40-C72 (figure 6). Ce test acoustique C100-C108 s’effectue de façon analogue au test acoustique B80-B88 du premier terminal client T1 tel que décrit précédemment. Ce test permet plus généralement de tester l’ensemble de la chaîne acoustique (incluant le haut-parleur HP2 et le microphone MIC2) du deuxième terminal client T2.
Plus particulièrement, le deuxième terminal client T2 active (C100) son microphone MIC2 s’il n’est pas déjà actif, et peut éventuellement désactiver (C102) une fonction F2 d’annulation d’écho dans le cas où une telle fonction est active. Une fonction d’annulation d’écho est en effet susceptible de faire obstacle au bon déroulement du test acoustique du haut-parleur HP2. En particulier, l’annulation le cas échéant d’une fonction F2 d’annulation d’écho permet une bonne acquisition acoustique par le microphone MIC2 d’une émission (ou sortie) acoustique du haut-parleur HP2 couplé au deuxième terminal client T2. Lors d’une étape C104 de génération, le deuxième terminal client T2 génère un signal acoustique de test noté SA2 (figure 1) au moyen du haut-parleur HP2. Pour cela, le deuxième terminal client T2 peut fournir en entrée du haut-parleur HP2 un quelconque flux de données audio de test, de sorte à produire un signal acoustique de test SA2 en sortie du haut-parleur HP2.
Le signal acoustique de test SA2 est de préférence un signal inaudible à l’oreille humaine (par exemple dans les hautes fréquences) afin de ne pas gêner l’utilisateur UR2 lors de la conférence audible et/ou vidéo, mais peut éventuellement être un signal audible. Selon un exemple particulier, le si signal acoustique de test SA2 est émis à une fréquence d’au moins 20 KHz. Il peut s’agir d’un signal monofréquence ou d’un signal sinusoïdal, bien que d’autres implémentations soient possibles. A titre d’exemple, le signal acoustique de test SA2 ainsi généré présente une fréquence d’échantillonnage d’au moins 44,1 KHz.
Le signal acoustique de test SA2 est également émis de préférence pendant un temps court (par exemple pendant une durée maximum de 250 ms), afin d’éviter de déranger éventuellement l’utilisateur UR1 et de sorte à économiser les ressources et accélérer autant que possible le processus de test acoustique, tout en s’assurant que ce signal acoustique de test SA2 est détectable par le microphone MIC2.
Lors d’une étape C106 d’acquisition acoustique, le deuxième terminal client T2 fait une acquisition acoustique au moyen du microphone MIC2 tandis que le haut-parleur HP2 émet le signal acoustique de test SA2, de sorte à tenter de capter ce signal acoustique de test SA2. Le deuxième terminal client T2 détermine (C108) alors, à partir d’un résultat de l’acquisition acoustique C106, des données de capacité acoustique DTB2 caractérisant des capacités acoustiques du haut-parleur HP2 (et plus généralement de l’équipement acoustique du deuxième terminal client T2).
Plus particulièrement, selon un exemple, le deuxième terminal client T2 acquière en C106 un flux de données audio de test DA2 produit par le microphone MIC2 à partir d’un signal acoustique capté par ledit microphone. Le deuxième terminal client T2 analyse (C106) ensuite, à partir du flux de données audio de test DA2, un signal acoustique capté par le microphone MIC2. Le deuxième terminal client T2 peut en particulier comparer le signal acoustique capté d’une part, avec le signal acoustique de test SA2 généré en C104 d’autre part. A partir d’un résultat de cette comparaison, le deuxième terminal client T2 évalue s’il y a correspondance entre le signal acoustique capté et le signal acoustique de test SA2. Les données de capacité acoustique DTB2 peuvent alors être fonction d’un degré de correspondance entre ces deux signaux. S’il y a correspondance, cela signifie que le haut-parleur HP2 (et plus généralement l’équipement acoustique du premier terminal client T1 ) est fonctionnel. Dans le cas contraire, cela signifie que le haut-parleur HP2 est susceptible d’être défectueux, ou tout du moins que l’équipement acoustique du deuxième terminal client T2 n’est pas fonctionnel.
Selon un exemple, le deuxième terminal client T1 peut transmettre au serveur de médiation SV2 les données de capacité acoustique DTB2 obtenues en C108. Le serveur de médiation SV2 peut alors transmettre également ces données de capacité acoustique DTB1 au premier terminal client T1 , ou plus généralement à chaque autre terminal client T1 , T3 et T4 participant à la conférence audio et/ou vidéo. Le premier terminal client T1 peut ainsi réaliser l’étape B22 de gestion (figures 5-6) en fonction également des données de capacité acoustique DTB2 reçues du serveur de médiation SV2. Comme déjà indiqué, les informations IF1 restituées le cas échéant par le premier terminal client T1 lors de l’étape B24 de restitution peuvent être représentatives également des données de capacité acoustiques DTB2 du deuxième terminal client T2.
Le test acoustique (C100-C108, figure 8) peut être réalisé à divers stades du deuxième procédé mis en œuvre par le deuxième terminal client T2 (figures 5-6). Une fois le test acoustique du deuxième terminal client T2 achevé, le terminal T2 peut réactiver le cas échéant la fonction F2 d’annulation d’écho, afin d’éviter d’éventuelles perturbations de l’acquisition acoustique du microphone MIC1 lors de la conférence audio et/ou vidéo.
Selon un exemple, chaque terminal client participant à la conférence audio et/ou vidéo peut déclencher un test acoustique de son propre équipement acoustique (dont son microphone et haut-parleur), par exemple lors de (ou en réponse à) l’établissement S2 (figure 6) de la session de communication auprès du serveur de conférence SV1. Dans ce cas, chaque terminal client envoie au serveur de médiation SV2 des données de capacités acoustiques DTB représentatives de ses propres capacités acoustiques. Les données de capacité acoustique obtenues par chaque terminal client peuvent ainsi être indicatives de la capacité dudit terminal client à : produire une émission (ou sortie) acoustique au moyen d’un microphone couplé audit terminal client, à partir d’un flux de données audio reçu en provenance du serveur de conférence audio et/ou vidéo SV1 ; et faire l’acquisition acoustique, au moyen d’un haut-parleur couplé audit terminal client, d’un signal acoustique.
Par ailleurs, tout ou partie du premier procédé tel que décrit ci-avant en référence notamment aux figures 5-6 peut être réitéré une pluralité de fois par le premier terminal client T1. Selon un exemple particulier, aux moins certaines des étapes B4-B22 (voire B2-B24) sont réitérées pendant la session de communication, de façon à vérifier plusieurs fois (par exemple périodiquement) si ledit au moins un deuxième terminal client T2-T4 est apte à recevoir un flux de données audio FX émis par le premier terminal client T1. Il est ainsi possible de monitorer au cours du temps les capacités audio d’un ou plusieurs deuxièmes terminaux T2-T4, notamment pendant que l’utilisateur UR1 du terminal client T1 parle ou qu’il est silencieux. La réitération périodique ou régulière du premier procédé peut permettre en particulier de surveiller de façon continue ou répétée la capacité d’un ou plusieurs deuxième terminaux à recevoir un flux de données audio émis par le premier terminal client T 1 .
A noter qu’il est possible de réitérer plusieurs fois le premier procédé de l’invention tout en utilisant le même code de marquage numérique WT1 , voire même en utilisant le même flux de données audio marquées FX1 (dans le cas par exemple d’un signal porteur émulé). On peut ainsi réaliser une pluralité de test audio tout en économisant les ressources nécessaires. En variante, le terminal client T1 utilise au moins deux codes de marquage numérique WT1 distincts pour mettre en œuvre une pluralité d’itérations du premier procédé. Le changement du code de marquage numérique WT1 au cours de plusieurs itérations du premier procédé peut aider à permettre d’assurer une meilleure robustesse du test audio (par exemple une meilleure sécurité du processus de test en cas d’interception et utilisation non autorisée d’un code de marquage numérique par un tiers, une possibilité d’utiliser plusieurs types de code de marquage différents pour plus de flexibilité, etc.).
Comme déjà indiqué en référence à la figure 5, le deuxième terminal client T2 peut notamment modifier sa configuration audio sur réception de données de capacité audio DTA2 indiquant que ledit deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio émis par le premier terminal client T 1. Selon un exemple particulier, le premier terminal client T 1 réalise les étapes suivantes pour chacune parmi une pluralité de configurations audio, tant qu’une première condition audio n’est pas satisfaite : configuration du premier terminal client T 1 selon ladite configuration audio; et réitération d’au moins un partie du premier procédé tel que précédemment décrit (étapes B2-B24).
De même, comme déjà indiqué en référence à la figure 6, le deuxième terminal client T2 peut notamment modifier sa configuration audio sur réception de données de capacité audio DTA2 indiquant que ledit deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio émis par le premier terminal client T1. Selon un exemple particulier, le deuxième terminal client T2 réalise les étapes suivantes pour chacune parmi une pluralité de configurations audio, tant qu’une deuxième condition audio n’est pas satisfaite : configuration du deuxième terminal client T2 selon ladite configuration audio; et réitération d’au moins une partie des étapes C56-C72 du deuxième procédé (figure 6).
Les premier et/ou deuxième terminaux clients peuvent ainsi tester chaque configuration audio possible jusqu’à obtenir un test audio positif.
Selon un exemple particulier, chaque terminal client T1-T4 (agissant en tant que premier terminal client) peut ainsi mettre en œuvre le premier procédé tel que précédemment décrit en référence aux figures 5-8 de sorte à tester la capacité de chaque autre terminal client (agissant en tant que deuxième terminal client) à recevoir un flux de données audio émis par ledit terminal client. Le serveur de médiation SV2 peut par exemple générer une matrice de capacité comprenant des données de capacité audio DTA associées à chaque terminal client, ces données indiquant si un flux audio émis par ledit terminal client est apte à être reçu par chaque autre terminal client. Cette matrice de capacité peut éventuellement aussi comprendre des données de capacité acoustique DTB caractérisant des capacités acoustiques de chaque terminal client. Autrement dit, cette matrice de capacité peut être obtenue en complétant la matrice de capacité audio précédemment décrite avec les données de capacité acoustique DTB des terminaux clients.
Le serveur de médiation SV2 peut en outre transmettre cette matrice de capacité à au moins un (par exemple chaque) terminal client T1-T4 afin que celui-ci gère la conférence audio et/ou vidéo en adaptant son fonctionnement en conséquence.
A noter d’autre part que l’ordre dans lequel s’enchaînent les étapes des différents procédés décrits ci- avant ne constitue que des exemples de réalisation non limitatifs, des variantes étant possibles.
Un homme du métier comprend que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l’invention. En particulier, l’homme du métier peut envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci- avant, afin de répondre à un besoin bien particulier conformément aux revendications présentées ci- après.

Claims

Revendications
[Revendication 1] Procédé mis en œuvre par un premier terminal client (T1) lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo (SV1) gérant des échanges de flux de données audio (FX) entre le premier terminal client et au moins un deuxième terminal client (T2-T4) au cours d’une conférence audio et/ou vidéo, le procédé comprenant : envoi (B6) au serveur de conférence audio et/ou vidéo , d’un flux de données audio (FX1 ) marquées par intégration d’un code attribué audit premier terminal dans un premier flux de données audio; réception (B8), de données de capacité audio (DTA) représentatives de si ledit au moins un deuxième terminal client a détecté le code attribué audit premier terminal dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et - déclenchement (B22) d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : o restitution, par une interface utilisateur du premier terminal client, d’informations (IF1), fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.
[Revendication 2] Procédé selon la revendication 1 , dans lequel le procédé comprend une réception (B46), depuis un serveur de médiation (SV2) du code attribué au premier terminal client.
[Revendication 3] Procédé selon la revendication 2, dans lequel ledit code attribué audit premier terminal client est reçu en réponse à une requête audit serveur de médiation comprenant un identifiant du premier terminal client.
[Revendication 4] Procédé selon l’une des revendications 1 à 3, dans lequel le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone (MIC1 ) couplé au premier terminal client.
[Revendication 5] Procédé selon la revendication 4, dans lequel les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité.
[Revendication 6] Procédé l’une des revendications 1 à 3, dans lequel le premier flux de données audio est généré par émulation d’un bruit aléatoire.
[Revendication 7] Procédé selon l’une quelconque des revendications 1 à 6, comprenant, avant l’envoi du flux de données audio marquées (FX1) au serveur conférence audio et/ou vidéo (SV1 ) : activation (B80) du premier microphone (MIC1 ) du premier terminal client ; désactivation (B82) d’une fonction d’annulation d’écho (F1) de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut-parleur couplé audit au moins un premier terminal client ; génération (B84) d’un signal acoustique de test (SA1) au moyen du premier haut-parleur (HP1) ; acquisition acoustique (B86), au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination (B88), à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques (DTB1) caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations (IF1) restituées par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client.
[Revendication 8] Procédé mis en œuvre par un deuxième terminal client (T2) lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo (SV1) gérant des échanges de flux de données audio (FX) entre un premier terminal client (T1) et le deuxième terminal client (T2) au cours d’une conférence audio et/ou vidéo, le procédé comprenant :
- réception (C8), en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio (FX2) ;et
- envoi (C12) d’une notification (NF1) comprenant un code (WT1) intégré dans ledit flux de données audio reçu, en association avec un identifiant (ID2) du deuxième terminal client.
[Revendication 9] Procédé selon la revendication 8, comprenant en outre, sur une détection dudit code dans ledit flux de données audio reçu : activation (C100) d’un deuxième microphone (MIC2) couplé au deuxième terminal client ; désactivation (C102) d’une fonction d’annulation d’écho (F2) de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur (HP2) couplé audit deuxième terminal client ; génération (C104) d’un signal acoustique de test (SA2) au moyen du deuxième haut- parleur ; acquisition acoustique (C106), au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination (C108), à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques (DTB2) du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation (SV2) des capacités acoustiques du deuxième haut- parleur.
[Revendication 10] Procédé de médiation mis en œuvre par un serveur de médiation (SV2) en coopération avec une pluralité de terminaux clients (T1-T4) participant à une conférence audio et/ou vidéo au cours de laquelle des flux de données audio (FX) sont échangés via un serveur de conférence audio et/ou vidéo (SV1), le procédé comprenant :
- envoi (D2) à un premier terminal client (T 1 ) d’un code (WT 1 ) attribué au premier terminal client et enregistré, en association avec un identifiant (ID1) du premier terminal client ;
- sur réception, en provenance d’un deuxième terminal client, d’une notification (NF1) comprenant le code attribué audit premier terminal client en association avec un identifiant (ID2) du deuxième terminal client : o détermination (D16) de données de capacité audio (DTA2) indiquant si le deuxième terminal client (T2) est apte à recevoir un flux de données audio en provenance du premier terminal client ; et o envoi au premier terminal client (T 1 ) desdites données de capacité audio (DTA2).
[Revendication 11] Procédé selon la revendication 10, dans lequel il est déterminé (D14 ; D64) une absence de réception de ladite notification (NF1) si aucune dite notification, indiquant que le deuxième terminal client (T2) a détecté le code (WT 1 ) attribué audit premier terminal, n’est reçue dans un premier délai à compter d’un instant de référence.
[Revendication 12] Terminal client comprenant au moins un processeur configuré pour mettre en œuvre le procédé selon au moins l’une des revendications 1 à 7 et/ou le procédé selon au moins l’une des revendications 8 à 9.
[Revendication 13] Système comprenant au moins un premier terminal client et au moins un deuxième terminal client, ledit premier terminal comprenant au moins un premier processeur configuré pour mettre en œuvre le procédé selon au moins l’une des revendications 1 à 7 et ledit second terminal comprenant au moins un second processeur configuré pour mettre en œuvre le procédé selon au moins l’une des revendications 8 à 9, lesdites informations restituées en par le premier terminal client indiquant que le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client.
[Revendication 14] Serveur de médiation comprenant au moins un processeur configuré pour mettre en œuvre le procédé selon au moins l’une des revendications 10 à 11.
EP22737648.0A 2021-06-23 2022-06-20 Gestion d'une audioconference audio et/ou video Pending EP4360298A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2106700A FR3124675A1 (fr) 2021-06-23 2021-06-23 Gestion d’une audioconférence audio et/ou vidéo
PCT/FR2022/051191 WO2022269181A1 (fr) 2021-06-23 2022-06-20 Gestion d'une audioconference audio et/ou video

Publications (1)

Publication Number Publication Date
EP4360298A1 true EP4360298A1 (fr) 2024-05-01

Family

ID=76807901

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22737648.0A Pending EP4360298A1 (fr) 2021-06-23 2022-06-20 Gestion d'une audioconference audio et/ou video

Country Status (4)

Country Link
US (1) US20240297937A1 (fr)
EP (1) EP4360298A1 (fr)
FR (1) FR3124675A1 (fr)
WO (1) WO2022269181A1 (fr)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2247082B1 (fr) * 2009-04-30 2013-11-20 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Dispositif de télécommunication, système de télécommunication et procédé de télécommunication de signaux vocaux
US8351589B2 (en) * 2009-06-16 2013-01-08 Microsoft Corporation Spatial audio for audio conferencing
US8407287B2 (en) * 2009-07-14 2013-03-26 Radvision Ltd. Systems, methods, and media for identifying and associating user devices with media cues
US9659571B2 (en) * 2011-05-11 2017-05-23 Robert Bosch Gmbh System and method for emitting and especially controlling an audio signal in an environment using an objective intelligibility measure
US10291495B2 (en) * 2016-08-11 2019-05-14 Thales Avionics, Inc. Analyzing passenger connectivity experiences while using vehicle cabin networks
US10462536B2 (en) * 2017-06-16 2019-10-29 M/S. Amagi Media Labs Pvt. Ltd System for low-latency detection of known audio video content using audio fingerprinting and audio watermarking
US10811018B2 (en) * 2018-12-04 2020-10-20 Saudi Arabian Oil Company System and method for using a unidirectional watermark for information leak identification
CN113516991B (zh) * 2020-08-18 2026-04-03 腾讯科技（深圳）有限公司 基于群组会话的音频播放、设备管理方法及装置

Also Published As

Publication number Publication date
FR3124675A1 (fr) 2022-12-30
WO2022269181A1 (fr) 2022-12-29
US20240297937A1 (en) 2024-09-05

Similar Documents

Publication Publication Date Title
EP1649677B1 (fr) Procedes et dispositifs d'evaluation de delais de transmission et de traitement d'un signal de parole recu dans un terminal relie a un reseau de paquets
US11095997B2 (en) Undesirable noise detection and management
FR2995122A1 (fr) Dispositif et procede pour fournir un signal audio de reference a une unite de traitement acoustique
US20250080644A1 (en) Authenticating A Call Recording Using Audio Scores
US11488612B2 (en) Audio fingerprinting for meeting services
US11417340B2 (en) Fault detection and management in a real-time communication
EP2882161A1 (fr) Procédé et dispositf d' établissement d'une communication
EP4360298A1 (fr) Gestion d'une audioconference audio et/ou video
US12542821B2 (en) Call quality analysis, notification and improvement
EP1859600B1 (fr) Procédé amélioré de transmission de données et d'informations de service qui leur sont associeés
EP2273759B1 (fr) Réplication optimisée dans un réseau pair-à-pair
EP1985093A1 (fr) Procédé et dispositif de gestion d'au moins un groupe d'utilisateurs, produit programme d'ordinateur correspondant
EP3809154B1 (fr) Procede de regroupement d'equipements par espaces sonores
WO2008035009A1 (fr) Procede de communication entre plusieurs terminaux
EP4016279B1 (fr) Procede de vote et dispositif mettant en oeuvre ledit procede
EP4016938B1 (fr) Procédé de synchronisation et système mettant en oeuvre ledit procédé
CA3217956A1 (fr) Procede de traitement de flux de donnees d'une session de conference par un serveur de session
CN115914673A (zh) 一种基于流媒体服务的合规检测方法及装置
FR3101725A1 (fr) Procédé de détection de la position de participants à une réunion à l’aide des terminaux personnels des participants, programme d’ordinateur correspondant.
WO2017103480A1 (fr) Système et procédé de réalisation d'un tour de table lors d'une réunion à distance
EP2351342A1 (fr) Qualite de transmission dans un systeme de communication
WO2007028533A1 (fr) Procédé de transmission d'informations à pérennité améliorée
EP4546174A1 (fr) Procede d'obtention d'un modele d'identification, programme d'ordinateur et procede d'identification associes
WO2025003195A1 (fr) Classification d'un jeu de données multi-activités dans un réseau de télécommunications
EP4016280A1 (fr) Procede de lecture synchronisee par des dispositifs de reproduction contrôles par un contrôleur, dispositif de reproduction et contrôleur mettant en uvre ledit procede

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240116

AK Designated contracting states

Kind code of ref document: A1

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

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