C’est que tu as plusieurs choses qui peuvent influer sur ta capacité de transfert. Déjà, du sans-fils est sensible a l’état de l’environnement, peut importe la technologie. Après, tu as ton système, il y a t-il des application (comme apt en schédule) qui peut utiliser la bande réseau ? Est-ce qu’un service, mis à part la vidéo, utilise la bande passante ?
Ce qui te donne dans les ~2.5Mo/s down et ~1.5Mo/s en up
En plus, ton service peut limité volontairement certains type d’envoie.
Si le compte utilisé est seul utilisateur du compte, et qui ne passe pas par un autre appareil (pont mobile) alors ce sera tes vitesses max théorique.
Mais ton format est quand même faible, mais en h264. Je n’utilise pas ce format dans mes projets de stream, mais j’utilise des RPi Zero et il est plus simple de gérer du MJpeg. Faudrait savoir le débit généré. Avec du MJpeg je peut gérer 8 streams in/out facilement sur du 100MBps (~15Mo/s*), mais je préfère le 1Gbps (~150Mo/s*).
Alors tu devrais arriver à stream, mais idéalement, tu dois permettre une tolérance du débit varié (VBR et non CBR) et avoir un flux inférieur ~15% de la limite d’envoie (marge d’erreur et buffering)
En effectuant un codec copy du stream vidéo, tu exige de maintenir le format de la source (hardware), ce qui dans certain cas de figure est trop « rigide » pour bien maintenir le stream, ou change, de manière automatique, certaines valeurs pour s’ajuster.
En voulant s’ajuster, FFMpeg peut générer des effets non désiré, comme l’ajout de temps dans le stream et par effet augmentation du latency.
FFMpeg pour s’ajuster à un frame rate en direct peut avoir de « drole » de comportement. Il peut sembler bien travailler mais découper les frames de manière a ne pas refléter le temps réel (~5%) ou simplement garder l’ensemble des frames pour doubler le temps. au lieu de couper 60 en 2 pour 30fps, il prendra le 60 fps pour en faire 30 frames en 2 secondes.
Je parle de cela car ton problème est causé par un goulot d’étranglement; trop de données tente de passer par le même canal, l’effet d’entonnoir ( = > - - ).
Dans ton cas, ont peut déjà dire que ce n’est pas le CPU, l’erreur serait autre. Mais soit au niveau réseau, soit au niveau du disque.
Mais ton projet n’inclus aucune écriture sur disque, de plus, il vient d’un service « WebRTC ».
Ce service, ne connaissant pas ta configuration et les système impliqués, peut servir de 2 choses;
- Communication de contrôle par interface Web : Contrôle ou « api » du service
- Service de diffusion en protocole Web : Diffusion du stream
Si ce service, enregistre sur le disque le stream reçu, il peut;
- Soit avoir un disque plein ou limité par un quota
- Soit qu’il n’a pas les autorisations d’écriture conforme à son privilège
Après si c’est un problème réseau, qui est plus probable, tu dois déterminer si le problème est du;
- Au capacité du serveur : Il ne peut gérer l’ensemble du flux reçu par manque de ressources (RAM, conflit de charge, mauvaise config logiciel,…)
- Au capacité matériel : Limitation de la bande passante (cité plus haut)
Alors de la l’importance de connaitre la vitesse du flux réel émit par FFMpeg. Tu as déjà une bonne idée avec le KBps du stream quand tu te connect dessus.
* Valeur défini par calcul simpliste d’évaluation moyenne
** Selon la capacité de la source
