[F4HTU]

Bonjour à tous,

Je soumets un petit problème auquel je ne trouve pas de solution pour le moment.
Je vous explique le contexte :
Nous avons équipé plusieurs relais ATV de la région d'une voie de réception DVBS grâce à des récepteurs "PRO" SCOPUS ProView 2960 et 2962.
Ils reçoivent très bien les émissions en provenance d'émetteurs de type Minimod. Par contre quand nous utilisons un Pluto ou un LimeSDR rien ne va plus. Ils verrouillent bien la fréquence, le FEC mais ne lance pas le décodage car ne trouve pas le byte de start 0x47 dans le TS.
Le démodulateur reste bloqué à : No Sync-0x47 Detected

Logiciel utilisé : DATVExpress - Lime SDR / OBS - Pluto soft Evariste

J'ai épluché à peu près tous les forums et posts qui traite de cela, Amsat..... Mais pas de réponse concrète à cette question. C'est un peu dommage car plusieurs Oms pourraient maintenant accéder aux relais en DVBS et être réémis de la même façon mais nous somme bloqués à cause de cela.
J'ai épluché toute la doc de ces récepteurs, aucune façon de désactiver cette détection. Sans le byte de sync il reste sur un écran noir alors que le reste est OK. Un peu décevant alors que le DVBS/DVBS2 est bien démocratisé maintenant.

Pourquoi ses récepteurs et pas des FTA me diraient vous ? Ils peuvent changer de "service, ID, PID" sans redémarrage. Ils prennent les services suivants qui est présent à l'entrée. Il suffit d'avoir la bonne fréquence et le récepteur scanne le reste ! Vraiment pratique pour des relais .

Si quelqu'un à déja rencontré le problème ? Ça nous avancerait vraiment beaucoup.

Cordiales 73
Romain F4HTU

[F6DZP]

Bonjour,

ça m'étonnerait qu'il n'y ait pas les octets 47h, car le TS ne serait alors pas conforme et je ne pense pas qu'il serait recevable par quoi que ce soit.
je n'ai pas analysé le TS fait avec le Pluto dernièrement, mais quand je l'avais fait, c'était avec des soft pro qui n'auraient pas passé cela sous silence.
D'autre part, dans un Minitioune le chip décodeur DVB S/S2 a absolument besoin de cet octet sinon une des leds TS reste rouge et il n'y a aucun TS à la sortie, rien à décoder.
Vraiment il me semble impossible qu'il n'y ait pas ces octets. Analysez le flux TS d'un Pluto reçu par Minitioune et envoyé par UDP dans un analyseur, vous trouverez ces octets.
En plus, j'en ai absolument besoin dans mon soft pour aligner les paquets UDP, donc vraiment, je ne vois pas il y aurait une absence.
Bref, si il n'y avait pas régulièrement cet octet d'entête dans des paquets, Minitioune ne pourrait rien afficher, les Leds TS seraient rouges, malgré un bon verrouillage, la détection du FEc et toutes les Leds de gauche vertes.

Mais je n'ai jamais utilisé autre chose que du H264 ou H265 pour le codage audio et de l'AAC pour le codage audio avec les softs d'Evariste F5OEO.
Vu l'ancienneté du récepteur que vous utilisez, il ne doit accepter que du Mpeg2 pour la vidéo et du Mpeg-audio ou AC3 pour le son, vous avez du vous paramétrer dans ce mode
Comme personne utilise les soft d’Évariste dans ce mode "antique" et très peu rentable coté bande passante, peut-être que dans ce mode il y a des bugs non vus car jamais utilisé de cette façon par personne...

(le soft DATV-Express lui, n'a jamais été bien conforme et pose souvent de gros problèmes donc lui n'est pas à utiliser avec des récepteurs pro. c'est normal qu'il ne soit pas bien digéré)

Je pense aussi à une autre possibilité: la raison indiqué par ce message est erronée et que la raison du problème est autre.
Par exemple un codage inconnu par l'appareil ( comme le H264 pour la vidéo ou l'AAC pour l'audio...)
Il se retrouve alors comme un canard qui a trouvé une fourchette et ne sait pas quoi en faire, ni quoi en dire...
.
Mais je peux avoir faux... Seul le développeur du soft d'encodage du TS pourra en dire plus.

Jean-Pierre F6DZP