Je recherche une approche standardisée pour diffuser des images JPG sur le réseau. Également souhaitable serait une interface de programmation C ++, qui peut être facilement intégrée au logiciel existant.
Je travaille sur un programme GPGPU qui traite des signaux numérisés et les compresse aux images JPG. La taille des images peut être définie par un utilisateur, typiquement les images sont de 1024 x 2048 ou 2048 x 4096 pixels. J'ai écrit mon "propre" protocole, qui envoie d'abord un en-tête (taille d'image en octets, la largeur, la hauteur et le canal correspondant), puis les données JPG elles-mêmes via TCP. Après cela, le récepteur envoie une confirmation que toutes les données sont reçues et affichées correctement, de sorte que l'image suivante puisse être envoyée. Jusqu'ici tout va bien, malheureusement, mon approche atteint seulement 12 FPS, ce qui ne satisfait pas aux exigences du projet.
Je suis sûr qu'il y a de meilleures approches qui ont des taux de trame plus élevés. Quelle approche des services de diffusion en streaming tels que Netflix et Amzon prennent-ils pour les vidéos UHD? Bien sûr, j'ai beaucoup googlé, mais je n'ai pas pu trouver de résultats satisfaisants.
3 Réponses :
existe-t-il une méthode standardisée pour envoyer des images JPG sur le réseau avec TCP / IP?
Il existe plusieurs protocoles Internet couramment utilisés pour transférer des fichiers sur TCP. Le protocole le plus couramment utilisé est peut-être http. Un autre, plus âgé est FTP.
Quelle approche des services de diffusion en streaming tels que Netflix et Amzon prend des vidéos UHD?
Premièrement, ils n'utilisent pas du tout JPEG. Ils utilisent du codec de compression vidéo (telle que MPEG), qui ne compresse pas uniquement les données spatialement, mais également temporellement (des cadres successives ont tendance à contenir des données similaires). Un exemple de protocole qu'ils pourraient utiliser pour diffuser les données est le tiret, qui fonctionne sur http.
Je n'ai pas à l'esprit une bibliothèque spécifique qui fait déjà ces choses bien, mais certains articles à garder à l'esprit:
Vous avez mentionné FPS, il semble que vous essayiez de diffuser une vidéo et non seulement de copier les images de manière rapide. Je ne suis pas tout à fait sûr de ce que vous essayez de faire. Pouvez-vous élaborer sur les signaux numérisés et pourquoi ils doivent être à JPEG? Ne peuvent-ils pas être dans un autre format, converti ultérieurement en JPEG à l'extrémité de réception?
Pour clarifier, je veux réellement envoyer des images et non des vidéos. Les signaux analogiques proviennent d'un capteur radar et sont échantillonnés par un numériseur (~ 4x200mb / s). Les données capturées sont transférées par RDMA via PCIe vers un GPU. Sur ce GPU, un algorithme radar est exécuté sur les données. Les données traitées (flottes) sont ensuite mappées sur les pixels de BMP24. J'ai supposé qu'il serait utile de la compresser avant d'envoyer les données sur le réseau. Un GPU convient à une telle compression et j'aimerais utiliser l'avantage. Quel format préféreriez-vous? Pensez-vous que le décodage des JPGS est un goulot d'étranglement (pas sur le GPU)?
@ One3Three7: Le GPU devrait pouvoir encoder une vidéo. J'avais demandé à quel point vous pouviez décoder rapidement et vous avez déjà dit que vous vous attendiez à plus de 100 fps la lecture, alors j'ai éliminé cela comme un goulot d'étranglement possible.
@jhx, alors il y avait un malentendu de ma part, je faisais référence à la transformation et à l'encodage des données, de ne pas rendu et décodage. Je vais vérifier comment le décodage et le rendu rapides prend.
@ One3Three7: Notez que 1 Go / s tel que utilisé dans l'exemple de ma réponse est normalement capable de gérer une vidéo de qualité HD à 60 fps. Les formats de flux offrent donc une bien meilleure compression, c'est-à-dire permettre de livrer davantage de cadres par seconde. Le seul tampon requis consiste à gérer une gigue de réseau occasionnelle (peut-être 10 secondes de tampon si vous êtes en particulier sur le point de ne pas voir la gestère).
Ce n'est pas une réponse directe à votre question, mais une suggestion que vous devrez probablement changer comment vous envoyez votre film.
Voici un calcul: Supposons que vous puissiez obtenir un débit de 1 Go de votre réseau. Si chaque fichier 2048x4096 comprime à environ 10 Mo (80 Mo), alors:
1000000000 ÷ (80 × 1000000) et égaux; 12.5
Donc, vous pouvez envoyer environ 12 cadres une seconde. Cela signifie que si vous avez un flux continu de JPGS que vous souhaitez afficher, si vous souhaitez des tarifs de trame plus rapides, vous avez besoin d'un réseau plus rapide.
Si votre flux est un film de longueur fixe, vous pouvez tamponner les données et démarrer le film une fois que suffisamment de données sont tamponnées pour permettre la lecture à la vitesse de trame souhaitée plus tôt que d'attendre le téléchargement de l'ensemble du film. Si vous souhaitez une lecture à 24 images une seconde, vous devrez alors tamponner au moins 2/3 rds du film avant d'être la lecture, car la lecture est deux fois plus rapide que votre vitesse de téléchargement.
Comme indiqué dans une autre réponse, vous devez utiliser un codec en continu afin que vous puissiez également profiter de la compression entre des cadres successifs, plutôt que de simplement compresser le cadre actuel seul.
En résumé, votre taux de lecture sera limité par le nombre de cadres que vous pouvez transférer par seconde si le flux ne se termine jamais (par exemple, un flux en direct).
Si vous avez un film de longueur fixe, la mémoire tampon peut être utilisée pour masquer les goulots d'étranglement du débit et de la latence.
En général Netflix ou d'autres fournisseurs, ce que le flux consiste à utiliser HTTP fondamentalement, mais ils tamponnent le contenu, par exemple tampon les 5 premières minutes du film et pendant que vous regardez le film, continuez le téléchargement et le tampon du système.
Vous recherchez une image par virement image ou un flux vidéo? Ce sont deux choses différentes.
Vous affirmez que votre approche actuelle
"atteint seulement 12 fps" . Avez-vous profilé pour trouver le goulot d'étranglement? Est-ce l'utilisation du processeur lors de la génération de la bande passante JPEG ou de réseau lors du transfert de ces JPEG? Ou autre chose?Je cherche une image par virement d'image. Malheureusement, il n'est pas possible de pré-tamponner certaines des images, car elles doivent être affichées en temps réel. Je ne l'ai pas profilée exactement, mais je suis à peu près sûr que la cause du cou de la bouteille est la confirmation du côté du récepteur. Si je saute la confirmation, l'émetteur envoie si vite que les images ne sont plus affichées correctement au récepteur. Cependant, je préférerais une procédure normalisée, car je suis sûr que ce problème a été résolu de manière intensive par des experts pendant une longue période.
À quelle vitesse êtes-vous capable de rendant les JPGS s'ils sont simplement lus à partir d'un fichier localement sur votre machine? Les vidéos ont leurs propres formats, par exemple, MPEG-4. Les formats vidéo tirent parti du fait que la trame suivante ne peut avoir que des différences mineures de la trame précédente. La compression peut donc être beaucoup plus élevée.
@JXH Eh bien, cela dépend et varie des signaux d'entrée analogiques et des tailles d'images. Étant donné que j'utilise le GPU pour le traitement et la compression, 150 à 250 fps sont possibles.
@ One3Three7 Pourquoi avez-vous même besoin de la confirmation si vous affichez simplement les données? Lorsque vous dites 12 FPS est trop bas, cela ressemble à une visualisation en direct. Cela, d'autre part, se pencherait vers la diffusion vidéo en streaming, car il est optimisé pour un affichage fluide de la photo sur des réseaux de bande passante variable.
@Timo en effet, c'est une visualisation en direct. Je ne connais pas la vidéo ou le traitement de l'image, c'est la raison pour laquelle j'ai demandé. Alors, quelle serait votre approche de transférer ces images ou vidéo, pour permettre une visualisation en temps réel?