Temps de latence pour les radios en ligne

Voilà: étant en Belgique, depuis l'arrêt des Grandes Ondes, je ne capte que très difficilement RTL sur la radio (j'habite pas loin de la frontière mais les plans de fréquences ne prennent pas en compte les émetteurs transfrontaliers).

Je me replie donc sur l'application RTL installée sur mon GSM.

Et bien que cette application annonce qu'elle permet d'écouter les programmes "en direct" j'ai remarqué, en comparant à la radio, un temps de latence de près de 2 minutes

Et déjà, à l'époque où il y avait les Grandes Ondes, j'avais constaté un "retard" d'une dizaine de secondes, si non plus, de la FM par rapport aux GO. De même, lorsqu'il y avait un match à la TV, annoncé "en direct", j'entendais souvent l'annonce d'un but sur la radio en Grandes Ondes avant de le voir à la télé.

Auriez une explication à ce décalage?

Bonjour,

Tout ce que j'écris ici est a vérifier, et amender par les pros des domaines respectifs.

Énormément de liaisons Internet entre radio et émetteurs sont à base de serveur de streaming. Il y a des tampons souvent de plusieurs secondes. En audio on a beaucoup utilisé des serveur de type Icecast souvent en TCP/IP avec une grande robustesse sur les liens. Ces liens sont très peu couteux. C'est très amusant en RDS en limite de deux émetteurs on se déplace... dans le temps au fil du relief. Lors d'un lien vidéo Via Youtube il n'y a une bonne trentaine de secondes voir une minute entre source et client.

Avec l'évolution des codecs, des bandes passantes Internet (fibre), et le besoin d'interaction, une tendance serait a la migration vers des protocoles UDP avec faible latence. Le Covid à forcé la révolution culturelle des Radios vers des solution IP plus en direct pour les intervenants studios. Durant les premières semaines de confinement COVID on a vu par exemple Radio France partir de très loin avec de gros pains techniques puis corriger le tir petit a petit. Je ne sais pas si ces technos sont utilisées en aval pour le lien tête de réseau/émetteurs.

Des applications d'un autre genre, coté opérateurs de diffusion historiques sont plus synchrone avec souvent un récepteur GPS pour synchroniser parfaitement les flux. FM synchrone sur autoroute. Radio en RDS. Ce qui ne veut pas forcément dire que c'est du direct parfait.

Parfois, le décalage est stratégique, sur un direct sensible il permet de censurer.

Même en audio, au niveau de la captation et du mixage, avec DANTE on à sur ce réseau IP quelques ms de latence. ça à tendance à retarder la survenue du larsen. Et ça ne représente que quelques mètres parcourus par le son. Mais ce n'est pas toujorus simple à gérer.

Même le HDMI pose soucis et l'électronique des TV. Par exemple des caméras sur un chef d'orchestre pour qu'un choeur situé en fond de salle ou à l'extérieur de la salle joue la partition pose aussi des soucis de timing. Ici on connaissait des régisseurs d'opéra qui lorsqu'ils voyaient des TV cathodique dans la rue les ramassaient.

Comme me le disait des chercheurs de la BBC, avec le numérique, la synchro, c'est une cause perdue.

RaDiMaN a écrit:

Parfois, le décalage est stratégique, sur un direct sensible il permet de censurer.

J'avais un peu pensé à ça, j''ai en effet entendu parler de certaines émissions TV étaient en "faux" direct, avec un décalage de quelques minutes afin de pouvoir couper la diffusion en cas de "dérapage" avant que ça ne passe à l'antenne. Maintenant, dans ce cas, pourquoi ne pas faire pareil pour ce qui passe par les ondes?

Un autre truc auquel je pensais, c'est qu'il serait possible que le programme commence au moment où l'on a ouvert l'application et le décalage viendrait des pubs spécifiques à l'app qui passent au début. Avec RTL et Europe 1, il y a souvent, à l'ouverture, une pub spécifique au réseau GSM, enfin à la localisation.

Sinon, oui, les histoires de mémoire tampon pour assurer la continuité est très plausible, mais les 2 minutes, ça me semble long...

Je suppose (et j'espère) que la radio et les Tv "en ligne" sont diffusés en multicast. Dans ce cas TCP-IP ne peut pas âtre utilisé et c'est de l'UDP. De toute façon corriger plus tard ne servirait à rien. Le dernier bond est probablement en unicast (mais ça ne change rien). Ce sont en fait les routeurs intermédiaires qui diffusent en fonction des demandes d'abonnement IP sur l'adresse multicast. Un récepteur ne sélectionne pas une fréquence (comme en radio) mais une adresse multicaste (IP).

Enfin moi j'ai conçu un grand réseau de caméras de surveillance (3000 caméras) qui fonctionnait sur ce principe. Sinon, il faudrait que le serveur (moi il n'y en avait pas) gère chaque connexion, une par une. Ca amène un peu de latence à la connexion et quand on veut faire cycler des images (qui viennent un peu de n'importe où) devant les opérateurs, il faut préparer l'image d'après par anticipation de façon que tous les cycles apparaissent synchrones de devant un même opérateur; sinon il tomberait fou.

La radio synchrone sur autoroute est faite pour que tous les metteurs émettent exactement sur la même fréquence. Evidemment ça crée des zones de silence dans les zones où les signaux arrivent en opposition de phase. Pour atténuer le phénomène les émetteurs font localement tourner, de façon aléatoire, leur phase à faible vitesse ainsi l'évanouissement est peu perceptible.

@capitaine haddock :
Si tu tentes un stream via Youtube, la latence est très longue. Il m'est arrivé un jour récent de stopper le stream source sur le serveur OBS, puis d'aller à pied sans trop me presser dans le hall de l'immeuble pour fermer un PC qui diffusait le direct. Arrivé au TV le revoyais la fin du Live et j'ai même du attendre encore.

Un collègue qui savait que j'étais à la réalisation, était étonné de voir sortir le public et de me voir attendre la fin du "direct". Nous avons alors constaté qu'il y avait de très longues secondes de latence.

Il peut également y avoir des machines de transcodage en travers du chemin, ce qui est sauf erreur de ma part le cas pour Youtube afin d'adresser toutes sortes de terminaux (H264, HEVC, VP8, VP9, etc...) Avec donc des tampons de chaque coté d'elles.

@F1AMM :
Par curiosité je viens de mettre un Wireshark sur un flux OTT d'un diffuseur qui a pignon sur rue. Et ça arrive en TCP. L'IP source est proche donc vraisemblablement le flux est "proxyfié" au plus près du client Internet pour pas boucher le réseau backbone.

On peut se demander l'intérêt de passer en tcp, sauf à vouloir absolument avoir des tampons pour augmenter la latence. De la vidéo en TCP je crois que je n'en ai jamais faite; ça a toujours été de l'UDP (unicast ou multicast). Ca n'a pas beaucoup d'importance pour l'utilisateur final de perdre quelques trames. En plus tcp risque de s'auto limiter en débit en laissant passer d'autre flux udp. C'est le risque avec tcp.

les motivations pour mode connecté pourraient également être le ciblage publicitaire, la mesure en temps réel de l'audience, de satisfaire les exigences des "talibans du copyright" (crypto, watermarking), les interactions,  ... Bref les joies de notre bas monde actuel.
Et on revient ici à la différence entre la radio-diffusion versus la consommation en mode connecté, une grande question...

Je ne suis pas (plus) spécialiste du domaine qui évolue trop rapidement pour moi.

Si c'est OTT, c'est à dire : un service en ligne où la vidéo sur demande [...] est disponibles, ça ne peut être qu'en mode connecté. Ca doit consommer un maxi de puissance au niveau du serveur ce genre de truc.

Après vérification, cette latence de 2 minutes serait propre à RTL. J'ai comparé hier soir Europe 1 à RTL, réception FM vs écoute via leurs applications "officielles" respectives (Android) et pour Europe 1, c'est pratiquement synchrone, alors que pour RTL, sur les grosses têtes, on entend le gong sur la FM alors que sur l'app Ruquier vient juste de poser la question...

Il faudra que je compare l'application à l'écoute en ligne sur leur site...

Au debut de la TNT, j'avais fait le test,2 télés cote a cote, une qui réceptionnait en analogique, l'autre via la TNT.
La TNT avait 4 a 5 secondes de retard, le temps de coder a l'emission et le décodage a la reception prend du temps.

Bonsoir et 73
J'avais déjà constaté un léger décalage entre les stations GO (quand elles existaient encore) et leur version FM
si on écoutait sur 2 récepteurs(GO et FM) la même station , cela donnait un effet de réverbération.
Je m'expliquais ça comme ça : les studios de la station (RTL, E1, RMC ou FI) étaient reliés aux émetteurs GO par câble spécial et le temps de transit du signal BF était quasi nul de même le temps de transit en l’émetteur GO et le récepteur.

Pour la FM , il y a une petite différence qui change tout : si le transit du signal VHF entre l’émetteur et le RX est toujours quasi nul il n'en est pas de même pour la liaison BF  studio-->émetteur FM. Louer une 40 aine ou une centaine de câbles spéciaux  entre le studio et les TX FM serait hors de prix.
la solution : la  liaison passe par un satellite géostationnaire (36 000 KM d'altitude) , celui-ci arrosant l'ensemble des émetteur FM . Il faut donc un peu plus 0,1s au signal pour monter au sat et autant pour redescendre soit 0.2s de décalage par rapport aux GO