Je continue les tests avec gstreamer.
Le streaming udp de windows à windows fonctionne comme suit :
UDP coté client :
gst-launch-0.10.exe udpsrc port=1234 ! theoradec ! ffmpegcolorspace ! directdrawsink
UDP coté serveur :
gst-launch-0.10.exe dshowvideosrc ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink host=127.0.0.1 port=1234
Remarque : on peut noter, en comparant les lignes de commandes Linux et Windows que le autovideosink n’est pas supporté sous Windows. Il est remplacé par le directdrawsink.
J’ai poursuivi les tests de streaming, cette fois entre deux machines ayant un OS différent.
=========
Premier test (Protocole UDP, Theora) :
=========
Client Linux, streaming UDP :
gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink
Serveur Windows, streaming UDP :
gst-launch-0.10.exe dshowvideosrc ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink host=192.168.X.X port=1234
Dans le cas d’un streaming UDP, il faut lancer le client, ensuite le serveur.
=========
Second test (Protocole UDP, Theora) :
=========
Client Windows, streaming UDP :
gst-launch-0.10.exe udpsrc port=1234 ! theoradec ! ffmpegcolorspace ! directdrawsink
Serveur Linux, streaming UDP :
gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink host=192.168.X.X port=1234
Il se peut que le flux ne soit pas reçu et provoque une erreur du type :
ERROR: from element /GstPipeline:pipeline0/GstTheoraDec:theoradec0: Could not decode stream.
Dans ce cas, il faut lancer le client (qui s’est fermé suite à l’erreur) et relancer le serveur, normalement tout devrait fonctionner.
=========
Troisième test (Protocole RTP/RTCP, Theora) :
=========
Serveur Linux, streaming RTP/RTCP :
gst-launch -v v4l2src ! videoscale method=1 ! video/x-raw-yuv !
theoraenc ! rtptheorapay ! .send_rtp_sink gstrtpsession name=session
.send_rtp_src ! udpsink port=5000 host=192.168.X.X
session.send_rtcp_src ! udpsink port=5001 host=192.168.X.X
Client Windows, streaming RTP/RTCP :
gst-launch-0.10.exe udpsrc port=5000 caps ="application/x-rtp, ... seqnum-base=(guint)61692" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtptheoradepay ! theoradec ! ffmpegcolorspace ! directdrawsink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink
Remarques :
– il faut passer l’option -v du côté serveur pour récupérer la dernière occurence du type « application/x-rtp, … seqnum-base=(guint)61692 » pour pouvoir ensuite spécifier le caps au niveau du client.
– il faut bien sûr lancer le serveur PUIS le client, cette fois.
=========
Quatrième test (Protocole RTP/RTCP, Theora) :
=========
Serveur Windows, streaming RTP/RTCP :
gst-launch-0.10.exe -v dshowvideosrc ! videoscale ! video/x-raw-yuv ! theoraenc ! rtptheorapay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=192.168.29.96 session.send_rtcp_src ! udpsink port=5001 host=192.168.29.96 > info.txt
Client Linux , streaming RTP/RTCP :
gst-launch udpsrc port=5000 caps="application/x-rtp ... seqnum-base=(guint)6699" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtptheoradepay ! theoradec ! xvimagesink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink
Remarques :
– les mêmes qu’au troisième test
– on peut penser à rediriger les informations produites dans un fichier texte avec » > info.txt » pour ne pas encombrer la console. Si le fichier n’existe pas, il sera créé automatiquement, sinon il sera écrasé.
=========
Cinquième test (Protocole RTP/RTCP, H.264) :
=========
Serveur Windows, streaming RTP/RTCP :
gst-launch-0.10.exe -v dshowvideosrc ! videoscale method=1 ! video/x-raw-yuv ! x264enc byte-stream=true bitrate=300 vbv-buf-capacity=300 me=0 subme=3 ! rtph264pay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=192.168.X.X session.send_rtcp_src ! udpsink port=5001 host=192.168.X.X > info.txt
Client Linux, streaming RTP/RTCP :
gst-launch udpsrc port=5000 caps="application/x-rtp ... seqnum-base=(guint)30502" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtph264depay ! ffdec_h264 ! xvimagesink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink
Remarques :
– les mêmes qu’au test précédent
=========
Sixième test (Protocole RTP/RTCP, H.264) :
=========
Alors là ça ne marche pas. J’y reviendrai plus tard, car je ne comprends pas pourquoi.
Serveur Linux, streaming RTP/RTCP :
gst-launch -v v4l2src ! videoscale method=1 ! video/x-raw-yuv ! x264enc byte-stream=true bitrate=300 vbv-buf-capacity=300 me=0 subme=3 ! rtph264pay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=192.168.X.X session.send_rtcp_src ! udpsink port=5001 host=192.168.X.X
Client Windows, streaming RTP/RTCP :
gst-launch-0.10.exe udpsrc port=5000 caps="application/x-rtp ... seqnum-base=(guint)899" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtph264depay ! ffdec_h264 ! directdrawsink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink
J’obtiens l’erreur suivante :
** (gst-launch-0.10:580): CRITICAL **: file ..\..\gst\gstobject.c: line 348: assertion `((GObject *) object)->ref_count > 0′ failed
** (gst-launch-0.10:580): CRITICAL **: file ..\..\gst\gstobject.c: line 348: assertion `((GObject *) object)->ref_count > 0′ failed
J’avais déjà obtenu cette erreur sur le serveur lorsque la webcam n’était pas branchée. Mais là, c’est différent, c’est sur le client qu’elle apparaît.
=========
Septième et huitième test (ProtocoleUDP, H.264) :
=========
Alors là, dans les deux cas, le streaming ne fonctionne pas :
Client Windows, streaming UDP :
gst-launch-0.10.exe udpsrc port=1234 ! ffdec_h264 ! ffmpegcolorspace ! directdrawsink
Serveur Linux, streaming UDP :
gst-launch v4l2src ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! x264enc ! udpsink host=192.168.X.X port=1234
On obtient l’erreur suivante :
GstPipeline:pipeline0/ffdec_h264:ffdec_h2640: ffdec_h264: input format was not set before data start