<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi Justin<div> </div><div>Most browsers have REMB congestion control built in. In REMB, the video receiver sends an estimate of the available bandwidth back to the sender. It does this by using the RTCP channel.</div><div> </div><div>I’m not familiar with Kurento's WebRTC implementation but I’m pretty sure it uses GstRtpBin underneath, so you should be able to receive REMB estimates. First look for the REMB requests in your initial SDP offering:</div><div> </div><div><pre class="newpage" style="margin-top: 0px; margin-bottom: 0px; break-before: page;"> a=rtcp-fb:<payload type> goog-remb</pre><pre class="newpage" style="margin-top: 0px; margin-bottom: 0px; break-before: page;"> </pre><pre class="newpage" style="margin-top: 0px; margin-bottom: 0px; break-before: page;">Then you can read the incoming RTCP messages from the rtpbin. There’s a signal you can connect to. Filter the REMB statistics and you’ll have an estimate of the available bandwidth which you can use to configure your encoder's bitrate. </pre><pre class="newpage" style="margin-top: 0px; margin-bottom: 0px; break-before: page;"> </pre><pre class="newpage" style="margin-top: 0px; margin-bottom: 0px; break-before: page;">I’d say an application would be easier. If you’d like to do it via plain cmdline you’ll need to modify, at least, the rtpbin and the encoder to communicate via messages.</pre><div> </div>Are you testing with gst-launch? If so, that would explain why it closes on poor network conditions. gst-launch listens to the pipeline bus and shuts down if an error is received. Your application may decide to react different. For example, pause waiting for the network to improve.</div><div> <div id="AppleMailSignature" dir="ltr">Michael</div><div id="AppleMailSignature" dir="ltr">RidgeRun</div><div dir="ltr"> On Feb 12, 2019, at 9:10 PM, justin via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> wrote: </div><blockquote type="cite"><div dir="ltr">hello there ! I am currently building a project where we aim to: "Live stream a drone video over 4G network in real time (~500 ms Latency) and broadcast to a website". The process is as follow: *Gstreamer*[HDMI video feed -> H264 encode -> RTP -> UDP sink] ---> *Kurento*[rtp -> webRTC] --> browser We successfully live streamed over WAN via ethernet and achieved required latency. The result was good. However when testing with 4G dongle (for real testing scenario), we are facing the issues with UDP streams being halted due to poor network condition depending on the location. My question is: Is there a way to dynamically change the target bitrate of omxh264encoder by checking the bandwidth of the sender? Would this require writing a c++ application rather than a commandline pipeline? This is my current pipeline: '!', 'video/x-raw,width=1920,height=1080,framerate=30/1', '!', 'videoconvert', '!', 'omxh264enc control-rate=1, bitrate=800000', '!', 'rtph264pay','config-interval=1','pt=96', '!', 'udpsink',ipStr,portStr,'-v']; Another question: It seems that Gstreamer stops streaming completely if the network condition is too poor. Is there a way for Gstreamer to simply pause and wait when the network is bad, and continue streaming when the signal gets better? Thanks guys ! -- Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/">http://gstreamer-devel.966125.n4.nabble.com/</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></div></blockquote></div></div></body></html>