Streaming RTP/RTSP: sync/timestamp problèmes
Je vais avoir quelques difficultés streaming H. 264 vidéo sur RTSP. L'objectif est de live-stream de l'image de la caméra à un RTSP client (idéalement un plugin dans le navigateur à la fin). Ce travail a été assez bien pour l'instant, sauf pour un seul problème: la vidéo de latence au démarrage, bégayer toutes les quelques secondes, et a une ~4-seconde de retard. Ce qui est mauvais.
Notre installation à encoder en x264 (w/zerolatency & ultrarapide) et emballé dans des RTSP/RTP avec démultiplexeur de ffmpeg 0.6.5. Pour les tests, je suis en recevant le flux avec un pipeline GStreamer avec tps-lancement lors de la connexion à un serveur RTSP. Cependant, j'ai été capable de reproduire la même question lors de la diffusion de droites à partir d'un autre GStreamer exemple avec juste RTP.
L'envoi de la machine:
gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=10.89.6.3
De la réception de la machine:
gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink
Vous pouvez également exécuter ces deux sur la même machine, il suffit de changer l'hôte à l'adresse 127.0.0.1 sur l'expéditeur. Sur l'extrémité de réception, vous devriez remarquer le bégaiement et généralement les moins performants vidéo, ainsi que les avertissements répétés sur la console:
WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2875): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.
Généralement suggéré par "solution" que j'ai vu partout sur l'Internet est d'utiliser sync=false avec xvimagesink:
gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink sync=false
La vidéo sera de retour avec une latence quasi-nulle, même lorsqu'il est testé avec notre logiciel de la caméra. Ceci est utile pour les tests, mais n'est pas très utile pour le déploiement, car il ne fonctionnera pas avec Totem, VLC, ou leur navigateur plugin intègre.
Je voudrais essayer de résoudre le problème à la source; je suis à soupçonner qu'il y a une sorte de timestamp infos manquantes sur le H. 264 flux en x264 ou peut-être sur le RTP charges. Est-il possible de modifier le source tps pipeline de sorte que je ne pas besoin d'utiliser sync=false sur le récepteur?
Si ce n'est pas possible, comment puis-je dire à leurs clients (via SDP ou autre) que le flux ne doit pas être synchronisées? En fin de compte, nous aimerions intégrer ceci dans le navigateur à l'aide d'un plugin VLC de toutes sortes, donc une solution qui fonctionne, il y serait encore mieux.
OriginalL'auteur Jacob Peddicord | 2012-07-09
Vous devez vous connecter pour publier un commentaire.
Vous pouvez ajouter des "sync=false" à la source de la tps pipeline. Sur Ubuntu 12.04 qui semble enlever le lag et les messages d'erreur.
Voici la commande que j'ai utilisé sur la source:
et voici ce que j'ai utilisé sur le récepteur:
Malheureusement, je n'ai aucune idée de pourquoi cela fonctionne ou même composant le "sync=false" propriété appartient à (sur la source de pipeline).
OriginalL'auteur ctrlc-root
En tant que root.ctrlc affiché, vous pouvez utiliser sync=FALSE. Cependant, vous remarquerez peut-être une énorme augmentation de l'utilisation du PROCESSEUR sur la fin de l'expéditeur. La raison en est que la synchronisation=FALSE indique l'évier juste à pousser les tampons dès qu'il les reçoit. L'évier qui motive l'ensemble du pipeline. Par conséquent, la synchronisation=FAUX, le pipeline pour encoder de la vidéo et de le pousser à UDP aussi vite que possible; il utilise 100% du CPU.
Ce que vous avez besoin est la gstrtpjitterbuffer. Il s'occupe aussi de l'horodatage, qui sont brisés ici.
Exemple de l'expéditeur:
Exemple récepteur:
gstrtpjitterbufferlorsque nous utilisons gst-launch-0.10 -vgstrtpbin name=rtpbin latency=40 udpsrc caps=".." port=50000, pouvez-vous s'il vous plaît partager le récepteur de la partie lors de l'utilisation gstrtpbin utilisé?Le gsrtpbin comprend un gstrtpjitterbuffer déjà. Comme pour la ligne de commande, je vais essayer de revenir à vous. Actuellement je ne peux pas l'essayer, car je n'ai pas de GStreamer 0.10 installé ici. (BTW, vous devriez vraiment passer à 1.0 , c'est fortement recommandé.)
Merci pour le tuyau pour
gstrtpjitterbufferet pour l'explication desink=false. Pourriez-vous nous expliquer comment est le tuyau de conduit autrement (quandsync=true)?Pourquoi les horodatages cassé ici?
OriginalL'auteur dv_
Je ne sais pas combien est-ce vrai, mais quand je lance mon pipeline sans connecter le chargeur de batterie pour mon ordinateur portable, elle a utilisé pour me jeter le même avertissement, et quand j'ai branché l'alimentation, de la confiance en moi, cela a fonctionné. Je pense que c'est peut-être à cause de la vieille pile CMOS, qui ne fonctionne pas comme il devrait l'être. comme il est responsable de la génération d'horloge.
OriginalL'auteur Sravan U