Hello.
My goal is to share incoming video stream received in WebRTC session over RTSP for further processing. Idea is to start RTSP server which uses "udpsrc" and dynamically update client pipeline with "udpsink" whenever "pad-added" signal comes. Implementation is based on usage of signalling server (https://github.com/centricular/gstwebrtc-demos/blob/master/signalling/simple-server.py) with WebRTC server (https://github.com/centricular/gstwebrtc-demos/blob/master/sendrecv/gst/webrtc-sendrecv.c). WebRTC client mostly uses same code as server with appropriate changes for offer/answer parts. Changes related to video stream processing are (both client/server use H264 configuration): A) Client runs RTSP server before pipeline start static void start_rtsp_server(void) { GstRTSPServer *server; GstRTSPMountPoints *mounts; GstRTSPMediaFactory *factory; server = gst_rtsp_server_new(); mounts = gst_rtsp_server_get_mount_points(server); factory = gst_rtsp_media_factory_new(); gst_rtsp_media_factory_set_shared(factory, TRUE); gst_rtsp_media_factory_set_launch( factory, "( udpsrc port=5000 " "caps=\"application/x-rtp, media=(string)video, payload=(int)96, " "clock-rate=(int)90000, encoding-name=(string)H264\" " "! rtpjitterbuffer latency=10 name=pay0 )"); gst_rtsp_mount_points_add_factory(mounts, mount_point, factory); g_object_unref(mounts); g_signal_connect(server, "client-connected", G_CALLBACK(rtsp_client_connected), NULL); gst_rtsp_server_attach(server, NULL); } B) Client pipeline uses fakesrc: pipeline = gst_parse_launch ("webrtcbin name=sendrecv " STUN_SERVER "fakesrc ! videoconvert ! queue ! x264enc ! rtph264pay ! " "queue ! " RTP_CAPS_H264 "96 ! sendrecv. ", &error); C) "Pad-added" signal on client causes pipeline update with UDP forwarding: static void on_incoming_stream(GstElement * webrtc, GstPad * new_pad, GstElement * pipe) { GstElement *out = NULL; GstPad *sink = NULL; GstCaps *caps; GstStructure *s; const gchar *encoding_name; g_print("Received new pad '%s' from '%s':\n", GST_PAD_NAME(new_pad), GST_ELEMENT_NAME(webrtc)); if (GST_PAD_DIRECTION (new_pad) != GST_PAD_SRC) return; caps = gst_pad_get_current_caps(new_pad); if (!caps) caps = gst_pad_query_caps (new_pad, NULL); GST_ERROR_OBJECT (new_pad, "caps %" GST_PTR_FORMAT, caps); g_assert (gst_caps_is_fixed (caps)); s = gst_caps_get_structure (caps, 0); encoding_name = gst_structure_get_string (s, "encoding-name"); g_print("Stream encoding is %s \n", encoding_name); if (g_strcmp0 (encoding_name, "H264") == 0) { out = gst_parse_bin_from_description ("udpsink host=127.0.0.1 port=5000", TRUE, NULL); } else { g_critical("Unknown encoding name %s", encoding_name); g_assert_not_reached (); } gboolean res_add = gst_bin_add(GST_BIN(pipe), out); if (!res_add) { g_critical("Could not add bin to pipe\n"); } gboolean res_sync = gst_element_sync_state_with_parent(out); if (!res_sync) { g_critical("Element's state could not be synced to the parent's state\n"); } sink = out->sinkpads->data; GstPadLinkReturn res_link = gst_pad_link(new_pad, sink); if (res_link != GST_PAD_LINK_OK) { g_critical("Could not link: %s \n", gst_pad_link_get_name(res_link)); } gst_caps_unref(caps); g_print("Pipeline is configured"); } Test scenario is - run signalling server locally - run webrtc client with local signalling server - run webrtc server with local signalling server and client peer id - run "vlc rtsp://127.0.0.1:8554/<mount_point>" Test works almost perfectly on Ubuntu 18.04, but on Windows 10 results are different: - some hosts have no problem and VLC shows video - some establish WebRTC connection and start streaming (traffic is seen with TCPView tool) but nothing is forwarded so VLC is failed to show video Considered workaround (didn't help much): - to disable Windows firewall - different Windows 10 builds (RS1, RS3, RS4). Problem is reproducible quite well (almost 100%) on Windows 10 in VirtualBox. I did check separately video stream UDP forwarding with gst-launch on the hosts having problem - it works. Does someone has any clues on what the problem may be related to? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Okay, eventually I've found workaround for this issue. In order to have
stable test results compatibility mode with Windows 7 was enabled for client binary. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |