ericssonresearch / scream

SCReAM - Mobile optimised congestion control algorithm

SCReAM

This project includes an implementation of SCReAM, a mobile optimised congestion control algorithm for realtime interactive media.

News

• 2024-05-03 :
  • isslowencoder option renamed to -emulatecubic as it behaves similar to TCP Cubic with a more moderate CWND growth close to the last known max value. The -emulatecubic option reduces bitrate variations at steady state but comes with the drawback that SCReAM can have problems to compete with Prague CC
• 2024-04-25 :
  • Improved stability at very low bitrates
  • Added isslowencoder option for the case that rate increase should be more moderate. This comes with the risk that SCReAM is starved by e.g TCP Prague.
• 2024-04-19 :
  • Log item RTP queue delay modified to make it possible to add network queue delay and RTP queue delay to see the actual extra delay for transmitted RTP packets.
  • SCReAM BW test tool (SCReAMv2 only): Added openWindow option
• 2024-04-17 :
  • ScreamV2Tx : openWindow option did not function properly, fixed. Reaction to sudden drop in throughput improved.
  • RtpQueue : code after return statement fixed.
• 2024-04-03 :
  • Multicam scream_sender.cpp : multiplicativeIncreaseFactor was erroneously set to 1.0, replaced with a much more correct value 0.05.
  • ScreamV2Tx : targetBitrate and RTP queue delay added to extra detailed log (-log option).
• 2024-03-27 :
  • Stability issue at very low RTTs fixed.
• 2024-03-22 :
  • Added method setIsSlowEncoder to increase robustness when video encoders react slowly to updated target bitrates.
• 2024-03-11 :
  • Added support for IPv6 in SCReAM BW test application.
  • Added counter for Not-ECT, ECT(0), ECT(1) and CE in summary printout.
• 2024-02-21 :
  • Added averaging to transmit and rtp rate logs.
• 2024-01-24 :
  • Robustness to sudden jumps in sender or receiver clocks improved.
• 2024-01-19 :
  • Stream prioritization refined.
  • SCReAM RFC8298 update. First draft available RFC8298-bis
  • SCReAM V2 is made default for gstreamer application.
• 2024-01-10 :
  • SCReAM V2 is made default for BW test and multicam application.
• 2023-12-07 :
  • General : Added CE marking percentage to statistics, added function to get statistics items. RTCP format error fixed.
  • SCReAM V2 : Delay based CC modified for more stable bitrate. Frame size histogram added to handle large frame size variation better
• 2023-11-12 : SCReAM V2 update. Conditional packet pacing is changed to always pacing when packet pacing is enabled. This removes an odd on/off effect in the packet pacing. Packet pacing implementation is updated to allow for micro burst intervals down to 0.2ms
• 2023-11-03 : SCReAM V2 update. The delay based part of SCReAM V2 is modified such that a virtual L4S alpha is computed when L4S is either disabled or inactive. The virtal L4S alpha is calculated based on the estimated queue delay. The resulting algorithm now abandoned most the LEDBAT style approach that was outlined in RFC8298. Some additional previous voodoo magic is removed in the process.
• 2023-09-20 : SCReAM V2. Version 2 is a major rewrite of the complete algorithm with the goal to make the algorithm more stable, especially when used with L4S. Support for V2 is in the BW test algorithm application and the multicam code. SCReAM V2 is enabled by adding -DV2 in the CMAKE_CXX_FLAGS in CMakeLists.txt
  The main changes are:
  • The congestion window serves mainly as a hand brake to avoid that excessive amounts of data is injected to the network when link thorughput drops dramatically. The congestion window is otherwise seldom a limiting factor in more normal working conditions
  • The packet pacing headroom is made large, as a default, the pacing rate is 50% larger than the nominal target rate. The congestion down-scale is adapted to this to still achieve high link ultilization
  • The rate control algorith is greatly simplified, with a minimal amount of voodoo magic that is difficult to explain
  • The fast increase mode is replaced with a multiplicative increase that sets in fully a configurable time after congestion
  • The final algorithm closely follows the 2 CE marks per RTT rule when used with L4S.

What is SCReAM

SCReAM (Self-Clocked Rate Adaptation for Multimedia) is a congestion control algorithm devised mainly for Video. Congestion control for WebRTC media is currently being standardized in the IETF RMCAT WG, the scope of the working group is to define requirements for congestion control and also to standardize a few candidate solutions. SCReAM is a congestion control candidate solution for WebRTC developed at Ericsson Research and optimized for good performance in wireless access.

The algorithm is an IETF experimental standard [1], a Sigcomm paper [2] and [3] explains the rationale behind the design of the algorithm in more detail. Because SCReAM as most other congestion control algorithms are continously improved over time, the current implementation available here has deviated from what is described in the papers and IETF RFC. The most important new development is addition of L4S support. In addition the algorithm has been modified to become more stable.

As mentioned above, SCReAM was originally devised for WebRTC but did not make it into being incorporated into that platform. Instead, SCReAM has found use as congestion control for remote controlled vehicles, cloud gaming demos and benchmarking of 5G networks with and without L4S support.

What is L4S ?

L4S is short for Low Latency Low Loss Scalable thorughput, L4S is specified in [4]. A network node that is L4S capable can remark packets that have the ECT(1) code point set to CE. The marking threshold is set very low (milliseconds).

A sender that is L4S capable sets the ECT(1) code point on outgoing packets. If CE packets are detected, then the sender should reduce the transmission rate in proportion to the amount of packets that are marked. A document that highlights how L4S improves performance for low latency applications is found in https://github.com/EricssonResearch/scream/blob/master/L4S-Results.pdf

In steady state, 2 packets per RTT should be marked. The expected rate then becomes
rate = (2.0/pMark) * MSS * 8/RTT [bps]
How SCReAM (V2) manages this is illustrated in the figure below
Figure 1 : SCReAM V2 bitrate as function of packet marking probability. RTT = 25ms, MSS=1360B. Dotted is theoretical, blue is actual

The more nitty gritty details

Unlike many other congestion control algorithms that are rate based i.e. they estimate the network throughput and adjust the media bitrate accordingly, SCReAM is self-clocked which essentially means that the algorithm does not send in more data into a network than what actually exits the network.

To achieve this, SCReAM implements a feedback protocol over RTCP that acknowledges received RTP packets. A congestion window is determined from the feedback, this congestion window determines how many RTP packets that can be in flight i.e. transmitted by not yet acknowledged, an RTP queue is maintained at the sender side to temporarily store the RTP packets pending transmission, this RTP queue is mostly empty but can temporarily become larger when the link throughput decreases. The congestion window is frequently adjusted for minimal e2e delay while still maintaining as high link utilization as possible. The use of self-clocking in SCReAM which is also the main principle in TCP has proven to work particularly well in wireless scenarios where the link throughput may change rapidly. This enables a congestion control which is robust to channel jitter, introduced by e.g. radio resource scheduling while still being able to respond promptly to reduced link throughput. SCReAM is optimized in house in a state of the art LTE system simulator for optimal performance in deployments where the LTE radio conditions are limiting. In addition, SCReAM is also optimized for good performance in simple bottleneck case such as those given in home gateway deployments. SCReAM is verified in simulator and in a testbed to operate in a rate range from a couple of 100kbps up to well over 100Mbps. The fact that SCReAM maintains a RTP queue on the sender side opens up for further optimizations to congestion, for instance it is possible to discard the contents of the RTP queue and replace with an I frame in order to refresh the video quickly at congestion.

SCReAM performance and behavior

SCReAM has been evaluated in a number of experiments over the years. Some of these are exemplified below.

A comparison against GCC (Google Congestion Control) is shown in [5]. Final presentations are found in [6] and [7]. A short video exemplifies the use of SCReAM in a small vehicle, remote controlled over a public LTE network. [8] explains the rationale behind the use of SCReAM in remote controlled applications over LTE/5G.

ECN (Explicit Congestion Notification)

SCReAM supports "classic" ECN, i.e. that the sending rate is reduced as a result of one or more ECN marked RTP packets in one RTT, similar to the guidelines in RFC3168. .

In addition SCReAM also supports L4S, i.e that the sending rate is reduced proportional to the fraction of the RTP packets that are ECN-CE marked. This enables lower network queue delay.

Below is shown two simulation examples with a simple 50Mbps bottleneck that changes to 25Mbps between 50 and 70s, the min RTT is 25ms. The video trace is from a video encoder.

L4S gives a somewhat lower media rate, the reason is that a larger headroom is added to ensure the low delay, considering the varying output rate of the video encoder. This is self-adjusting by inherent design because the larger frames hit the L4S enabled queue more and thus causes more marking. The average bitrate would increase if the frame size variations are smaller.

Figure 2 : SCReAM V2 without L4S support

Figure 3 : SCReAM with L4S support. L4S ramp-marker (Th_low=2ms, Th_high=10ms)

---

Below are a few older examples that show how SCReAM performs

The two videos below show a simple test with a simple 3Mbps bottleneck (CoDel AQM, ECN cabable). The first video is with ECN disabled in the sender, the other is with ECN enabled. SCReAM is here used with a Panasonic WV-SBV111M IP camera. One may argue that one can disable CoDel to avoid the packet losses, unfortunately one then lose the positive properties with CoDel, mentioned earlier.

Without ECN

With ECN

The green areas that occur due to packet loss is an artifact in the conversion of the RTP dump.

Real life test

A real life test of SCReAM is performed with the following setup in a car:

• Sony Camcorder placed on dashboard, HDMI output used
• Antrica ANT-35000A video encoder with 1000-8000kbps encoding range and 1080p50 mode
• Laptop with a SCReAM sender running
• Sony Xperia phone in WiFi tethering mode

A SCReAM receiver that logged the performance and stored the received RTP packets was running in an office. The video traffic was thus transmitted in LTE uplink.The video was played out to file with GStreamer, the jitter buffer was disabled to allow for the visibility of the delay jitter artifacts,

Below is a graph that shows the bitrate, the congestion window and the queue delay.

Figure 5 : Trace from live drive test

The graph shows that SCReAM manages high bitrate video streaming with low e2e delay despite demanding conditions both in terms of variable throughput and in a changing output bitrate from the video encoder. Packet losses occur relatively frequently, the exact reason is unknown but seem to be related to handover events, normally packet loss should not occure in LTE-UL, however this seems to be the case with the used cellphone. The delay increases between 1730 and 1800s, the reason here is that the available throughput was lower than the lowest possible coder bitrate. An encoder with a wider rate range would be able to make it possible to keep the delay low also in this case.

A video from the experiment is found at the link below. The artifacts and overall video quality can be correlated aginst the graph above.

Link to video : SCReAM live demo

SCReAM is also implemented in a remote controlled car prototype. The two videos below show how it works in different situations

• Boliden Kankberg mine
• Winter wonderland

SCReAM has been successfully be used on more recent experiments, examples will be added later.

Build

The SCReAM code comes in two (three) applications

• Windows based test application : This application implements a simple bottleneck and does only local simulation. Open the scream.sln application in Visual studio and build.
• Linux based BW test application : Makes in possible to benchmark the throughput live networks and test beds. The tool models a video encoder. See https://github.com/EricssonResearch/scream/blob/master/SCReAM-description.pptx for further instructions.
• multicam version : See ./multicam/README.md for details.
• gstreamer plugin : See ./gstscream/README.md for details.

The code

The main SCReAM algorithm components are found in the C++ classes:

• ScreamTx : SCReAM sender algorithm

  • ScreamV1Tx : Older version
  • ScreamV2Tx, ScreamV2Stream : Version

• ScreamRx : SCReAM receiver algorithm

• RtpQueue : Rudimentary RTP packet queue

A few support classes for experimental use are implemented in:

• VideoEnc : A very simple model of a Video encoder

• NetQueue : Simple delay and bandwidth limitation

For more information on how to use the code in multimedia clients or in experimental platforms, please see https://github.com/EricssonResearch/scream/blob/master/SCReAM-description.pptx

Feedback format

The feedback format is according to [9]. The feedback interval depends heavily on the media bitrate.

Build SCReAM BW test application

The SCReAM BW test application runs on e.g Ubuntu 16.04 and later. The build steps are:

cmake .
make

You need git, cmake, make and g++ installed

To enable SCReAM V2, change SET(CMAKE_CXX_FLAGS "-fPIC -fpermissive -pthread") to SET(CMAKE_CXX_FLAGS "-fPIC -fpermissive -pthread -DV2") in CMakeLists.txt

References

[1] https://tools.ietf.org/html/rfc8298

[2] Sigcomm paper http://dl.acm.org/citation.cfm?id=2631976

[3] Sigcomm presentation http://conferences.sigcomm.org/sigcomm/2014/doc/slides/150.pdf

[4] https://tools.ietf.org/html/rfc9331

[5] IETF RMCAT presentation, comparison against Google Congestion Control (GCC) http://www.ietf.org/proceedings/90/slides/slides-90-rmcat-3.pdf

[6] IETF RMCAT presentation (final for WGLC) : https://www.ietf.org/proceedings/96/slides/slides-96-rmcat-0.pdf

[7] IETF RMCAT presention , SCReAM for remote controlled vehicles over 4G/5G : https://datatracker.ietf.org/meeting/100/materials/slides-100-rmcat-scream-experiments

[8] Adaptive Video with SCReAM over LTE for Remote-Operated Working Machines : https://www.hindawi.com/journals/wcmc/2018/3142496/

[9] https://tools.ietf.org/html/rfc8888

scream's Issues

LTE Simulation (Question)

Hi

It seems like that, every RMCAT contestant must pass the provided test cases. It seems that scream must have passed all of them, but I could not find any document about the LTE test cases results, although there are some practical results there. Are there any open documents about it?

Unable to set an initial bitrate

Initial bitrate is automatically set to minBitrate and there is no way to change them independently. In Google's implementation you can set the 3 bitrate values (min/max/start)

QUESTION: Real-World Projects

Hi everyone (contributors),

I am learning about congestion control algorithms in the industry and found your paper and GitHub implementation, and I was wondering if you have real-world projects that use SCReAM and where I can find more information, because I am really interested in understanding how it behaves in real-life use cases.

Kind regards,
Pedro

Compile error

Hello,
There is a compile error at gst-gscreamrx/gst-plugin/src/gstscreamrx.cpp (line no. 378)

function argument number mismatch error:

bool isFb = filter->screamRx->createStandardizedFeedback(time_ntp, buf , rtcpSize);

The createStandardizedFeedback function is defined as
bool ScreamRx::createStandardizedFeedback(uint32_t time_ntp, bool isMark, unsigned char *buf, int &size)

With best regards,

SeunbgHo Jung

Same file names in multiple directories with similar content

Hello Ingemar,

in multiple directories, we find files with the same filename. Sometimes, they have same content, sometimes, the content differs (see below).

This version of the files shall we use?

With best regards,

Christian

scream/code/gscream/gst-gscreamrx/gst-plugin/src$ diff ScreamRx.cpp ../../../../ScreamRx.cpp 
284c284
<     buf[1] = 205;
---
>     buf[1] = 207;


scream/code/gscream/gst-gscreamrx/gst-plugin/src$ diff -w ScreamRx.h ../../../../ScreamRx.h
30c30
< extern "C" {
---
> 
144c144
< }
---
> 


scream/code/gscream/gst-gscreamrx/gst-plugin/src$ diff -w ScreamTx.h ../../../../ScreamTx.h
6a7
> extern "C" {
50a52,53
> // Max video rampup scale as fraction of the current target bitrate
> static const float kRampUpScale = 0.2f; 
141a145
> 		float rampUpScale = kRampUpScale,
334a339
> 			float rampUpScale,
357a363
> 		float rampUpScale;
659a666
> }



scream/code/gscream/gst-gscreamrx/gst-plugin/src$ diff ScreamTx0.h ScreamTx.h 
7d6
< extern "C" {
661d659
< }


diff -w RtpQueue.cpp ../../../../RtpQueue.cpp 
.... many differences ....

diff -w RtpQueue.h ../../../../RtpQueue.h
.... many differences ....

scream/code/gscream/gst-gscreamtx/gst-plugin/src$ diff -w ScreamRx.cpp ../../../../ScreamRx.cpp 
284c284
<     buf[1] = 205;
---
>     buf[1] = 207;

Implementation Status of the RFC especially media rate control

Hi,

if I compare the RFC8298 media rate control algorithm with the implementation, I didn't find features like "Force a slight reduction in bitrate if RTP queue builds up".
And I didn't find the dependency through the rate_transmit and rate_ack.

If this is already implemented, can you please point me to the code. Thanks.

Usage of getTargetBitrate

Hello,

I am looking how to use StreamTx::getTargetBitrate to apply the bitrate for x264 encoder.
Wanted to know whether that is the intended way?

The app is running in docker and the network interface QoS is set using tc qdisc add dev eth0 root netem delay 200ms rate 4mbit

getTargetBitrate()*rateScale(=0.5) gives values that are large and I end up using getTargetBitrate()*rateScale(=0.5)/100
672010 ends up as 3360kbps for the encoder. If this makes sense...

 summary  45.7  Transmit rate =  1525kbps, PLR =  0.04%( 0.11%), RTT = 0.218s, Queue delay = 0.022s
getTargetBitrate: 676392
 summary  45.7  Transmit rate =  1525kbps, PLR =  0.04%( 0.11%), RTT = 0.218s, Queue delay = 0.022s
 summary  45.7  Transmit rate =  1525kbps, PLR =  0.04%( 0.11%), RTT = 0.218s, Queue delay = 0.022s
 summary  45.7  Transmit rate =  1529kbps, PLR =  0.04%( 0.12%), RTT = 0.218s, Queue delay = 0.024s
 summary  45.7  Transmit rate =  1529kbps, PLR =  0.04%( 0.12%), RTT = 0.218s, Queue delay = 0.024s
 summary  45.8  Transmit rate =  1529kbps, PLR =  0.04%( 0.12%), RTT = 0.218s, Queue delay = 0.024s
 summary  45.8  Transmit rate =  1526kbps, PLR =  0.04%( 0.12%), RTT = 0.218s, Queue delay = 0.025s
 summary  45.8  Transmit rate =  1526kbps, PLR =  0.04%( 0.12%), RTT = 0.218s, Queue delay = 0.025s
 summary  45.8  Transmit rate =  1523kbps, PLR =  0.04%( 0.13%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.8  Transmit rate =  1523kbps, PLR =  0.04%( 0.13%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.8  Transmit rate =  1523kbps, PLR =  0.04%( 0.13%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.9  Transmit rate =  1523kbps, PLR =  0.04%( 0.13%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.9  Transmit rate =  1521kbps, PLR =  0.04%( 0.14%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.9  Transmit rate =  1521kbps, PLR =  0.04%( 0.14%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.9  Transmit rate =  1521kbps, PLR =  0.04%( 0.14%), RTT = 0.218s, Queue delay = 0.026s
 summary  45.9  Transmit rate =  1517kbps, PLR =  0.04%( 0.14%), RTT = 0.219s, Queue delay = 0.026s
 summary  45.9  Transmit rate =  1517kbps, PLR =  0.04%( 0.14%), RTT = 0.219s, Queue delay = 0.026s
 summary  46.0  Transmit rate =  1514kbps, PLR =  0.04%( 0.13%), RTT = 0.219s, Queue delay = 0.025s
 summary  46.0  Transmit rate =  1508kbps, PLR =  0.04%( 0.13%), RTT = 0.219s, Queue delay = 0.025s
 summary  46.0  Transmit rate =  1508kbps, PLR =  0.04%( 0.13%), RTT = 0.219s, Queue delay = 0.025s
 summary  46.0  Transmit rate =  1508kbps, PLR =  0.04%( 0.13%), RTT = 0.219s, Queue delay = 0.025s
 summary  46.1  Transmit rate =  1504kbps, PLR =  0.23%( 0.13%), RTT = 0.219s, Queue delay = 0.025s
getTargetBitrate: 672010

StreamTx initialization (basically from scream_sender.cpp):

    _screamTx = new ScreamTx(scaleFactor, scaleFactor,
        delayTarget,
        false,
        1.0f, dscale,
        (initRate * 100) / 8,
        packetPacingHeadroom,
        20,
        ect == 1,
        false,
        enableClockDriftCompensation);

    _screamTx->setCwndMinLow(5000);

    _screamTx->registerNewStream(this,
        SSRC,
        1.0f,
        minRate * 1000,
        initRate * 1000,
        maxRate * 1000,
        rateIncrease * 1000, rateScale,
        0.2f, txQueueSizeFactor, queueDelayGuard, scaleFactor, scaleFactor);

where

int initRate = 1000;
int minRate = 800;
int maxRate = 200000;
int rateIncrease = 10000;
float rateScale = 0.5f;
float dscale = 10.0f;
bool enableClockDriftCompensation = false;
float burstTime = -1.0;
float burstSleep = -1.0;
bool isBurst = false;
float burstStartTime = -1.0;
float burstSleepTime = -1.0;
bool pushTraffic = false;
float packetPacingHeadroom = 1.25f;
float txQueueSizeFactor = 0.1f;
float queueDelayGuard = 0.05f;

float scaleFactor = 0.9f;
float delayTarget = 0.06f;

Thanks for making an interesting algorithm available.

Help needed: Use with Audio only in wireless environment

Hi,

I try to use scream with audio only with the OPUS Codec.
My setup consists of MESH wireless network.
But as I saw the distribution of the bandwidth between the clients is very unfair.
So some clients use the max bitrate and some only the min bitrate.

Do you have an idea how to tune the parameter for a better fairness and an overall better result?
Thanks for your help!

build on Windows

I checkout the source code from master and offen the .sln file in visual studio community 2017. I build the source code. But there is many errors, e. g. sys/socket.h, sys/time.h netinet/in.h, pthread.h no such file or drectory. sys/time.h etc seems for Linux. I corrected these errors and install vcpkg, Then there are also other errors.

Does the gstreamer plugin subtract the RTP overhead?

As I read in your presentation, it's necessary to subtract the RTP overhead from the given bitrate, before set it to the encoder.
From my understanding of the plugin code, this doesn't happen.

gscreamrx / RTCP feedback problem ?

Hello!
i'm assuming this is possibly a dumb "user error" issue...
but i'm having trouble figuring out what's happening here. I have a video that i'm trying to stream from one ubuntu18.04 box to another.. and was seeing lots of "RTP queue discarded for SSRC" messages showing up at the sender. I take it this means RTCP feedback is received, but something like either IP addresses are not properly set, or ports are blocked (as i read in another thread here).
Of course the video is very laggy and poor quality. I can run these pipes without gscreamtx/rx and it works well.

(to make testing simpler... i actually ran the two pipes colocated on a single machine as you can see below):

Here's my sender:
gst-launch-1.0 rtpbin name=rtpbin ! filesrc location=tears_of_steel_1080p.mov ! decodebin ! x264enc name=video tune=zerolatency ! rtph264pay ! gscreamtx media-src=0 ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink host=135.112.62.140 port=5000 rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0

Here's my receiver:
gst-launch-1.0 rtpbin name=rtpbin udpsrc port=5000 ! gscreamrx ! application/x-rtp,media=video,clock-rate=90000,encoding-name=H264 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! avdec_h264 ! videoconvert ! xvimagesink sync=false async=false udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=127.0.0.1 sync=false async=false

the receiver on start shows this error:

*************INIT*************

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...

(gst-launch-1.0:5129): GLib-GObject-CRITICAL **: 11:09:07.354: g_object_set: assertion 'G_IS_OBJECT (object)' failed
SINK EVENT 


  ENABLE CALLBACK  

Setting pipeline to PLAYING ...

once i set GST_DEBUG=4, i can see this on startup:

0:00:00.414568983  5470 0x55d3473aa190 INFO        GST_ELEMENT_PADS gstelement.c:917:gst_element_get_static_pad: no such pad 'sink' in element "udpsrc0"
Pipeline is live and does not need PREROLL ...
0:00:00.414617433  5470 0x55d3473aa190 INFO           GST_PARENTAGE gstbin.c:4466:gst_bin_get_by_name: [pipeline0]: looking up child element rtpbin

(gst-launch-1.0:5470): GLib-GObject-CRITICAL **: 11:14:20.982: g_object_set: assertion 'G_IS_OBJECT (object)' failed
Setting pipeline to PLAYING ...
0:00:00.415221686  5470 0x55d347051200 INFO               GST_EVENT gstevent.c:1388:gst_event_new_latency: creating latency event 0:00:00.000000000
0:00:00.415279838  5470 0x55d347051200 INFO                     bin gstbin.c:2781:gst_bin_do_latency_func:<pipeline0> configured latency of 0:00:00.000000000

Any ideas here?
This is a problem with udpsrc setup?" for the rtpbin?

thanks so much!
-pete

Running SCReAM BW test applications in gstscream not work on Linux

I run ./scripts/receiver_bw.sh or ./scripts/receiver_bw.sh . There is a error:scream/scream/gstscream$ ./scripts/receiver_bw.sh
scream_receiver: no process found
./scripts/receiver_bw.sh: line 7: ../target/debug//scream_receiver: No such file or directory.

---

I changed the last line from ../target/debug/scream_receiver to ./target/debu/scream_receiver in receiver_bw.sh and sender_bw.sh. It run but with errors.The following are the information/error for receiver_bw and sender_bw at running.

---

./scripts/receiver_bw.sh
scream_receiver: no process found
RECVPIPELINE=rtpbin latency=10 name=rtpbin udpsrc port=30112 address=127.0.0.1 ! screamrx name=screamrx screamrx.src ! fakesink rtpbin.send_rtcp_src_0 ! funnel name=f ! udpsink host=127.0.0.2 port=30112 sync=false async=false screamrx.rtcp_src ! f.
thread 'main' panicked at 'called Result::unwrap() on an Err value: Error { domain: gst_parse_error, code: 1, message: "no element "screamrx"" }', src/receiver.rs:33:44
stack backtrace:
0: 0x5630529785ca - std::backtrace_rs::backtrace::libunwind::trace::h79937bc171ada62c
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x5630529785ca - std::backtrace_rs::backtrace::trace_unsynchronized::h2292bca8571cb919
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x5630529785ca - std::sys_common::backtrace::_print_fmt::h9c461f248e4ae90d
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:65:5
3: 0x5630529785ca - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he9fe6bf1a39182e1
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:44:22
4: 0x563052992e9e - core::fmt::write::h032658c119c720d7
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/fmt/mod.rs:1208:17
5: 0x563052976395 - std::io::Write::write_fmt::h299fc90dfae41c0d
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/io/mod.rs:1682:15
6: 0x563052978395 - std::sys_common::backtrace::_print::heb70d25df9937e3f
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:47:5
7: 0x563052978395 - std::sys_common::backtrace::print::had745c0a76b8b521
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:34:9
8: 0x563052979a1f - std::panicking::default_hook::{{closure}}::h1ea782cdfa2fd097
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:267:22
9: 0x56305297975b - std::panicking::default_hook::h1cc3af63455a163c
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:286:9
10: 0x56305297a12c - std::panicking::rust_panic_with_hook::h5cafdc4b3bfd5528
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:688:13
11: 0x563052979ec9 - std::panicking::begin_panic_handler::{{closure}}::hf31c60f40775892c
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:579:13
12: 0x563052978a7c - std::sys_common::backtrace::__rust_end_short_backtrace::h28a5c7be595826cd
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:137:18
13: 0x563052979bd2 - rust_begin_unwind
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
14: 0x5630528796d3 - core::panicking::panic_fmt::h8fa27a0b37dd98b7
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
15: 0x563052879aa3 - core::result::unwrap_failed::h62abf61e411aaa08
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/result.rs:1791:5
16: 0x56305287a138 - core::result::Result<T,E>::unwrap::h9474b07eed4007e8
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/result.rs:1113:23
17: 0x56305287b5cd - scream_receiver::start::h14417ac5a526b054
at /home/jens/projects/scream/scream/gstscream/src/receiver.rs:33:20
18: 0x56305287b3d0 - scream_receiver::main::hd25da661dfae5371
at /home/jens/projects/scream/scream/gstscream/src/receiver.rs:27:5
19: 0x56305287fdab - core::ops::function::FnOnce::call_once::he5e3d79f35dcf7fb
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
20: 0x56305287bb8e - std::sys_common::backtrace::__rust_begin_short_backtrace::h2f1709f5e29ffc64
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:121:18
21: 0x56305287bc01 - std::rt::lang_start::{{closure}}::h271c45bdd1ca2522
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:166:18
22: 0x5630529733ec - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::hfa1c3687c9a20bb8
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:606:13
23: 0x5630529733ec - std::panicking::try::do_call::h0497133ebe1341e5
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:483:40
24: 0x5630529733ec - std::panicking::try::h6c3de05c7ca5d07f
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:447:19
25: 0x5630529733ec - std::panic::catch_unwind::h969058ecb5334b30
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panic.rs:137:14
26: 0x5630529733ec - std::rt::lang_start_internal::{{closure}}::h0de6d98cafb42a58
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:148:48
27: 0x5630529733ec - std::panicking::try::do_call::h77301dcf43953993
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:483:40
28: 0x5630529733ec - std::panicking::try::h45b05523a2fe135a
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:447:19
29: 0x5630529733ec - std::panic::catch_unwind::hd95cea544b2b9bd2
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panic.rs:137:14
30: 0x5630529733ec - std::rt::lang_start_internal::hd16e6ff7bf05a444
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:148:20
31: 0x56305287bbda - std::rt::lang_start::hd3f45e4c7f7026be
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:165:17
32: 0x56305287ba9e - main
33: 0x7fe999c5bd0a - __libc_start_main
34: 0x563052879bea - _start
35: 0x0 -

---

./scripts/sender_bw.sh
scream_sender: no process found
thread 'main' panicked at 'called Result::unwrap() on an Err value: NotPresent', src/receiver.rs:31:48
stack backtrace:
0: 0x55cd4ad155ca - std::backtrace_rs::backtrace::libunwind::trace::h79937bc171ada62c
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x55cd4ad155ca - std::backtrace_rs::backtrace::trace_unsynchronized::h2292bca8571cb919
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x55cd4ad155ca - std::sys_common::backtrace::_print_fmt::h9c461f248e4ae90d
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:65:5
3: 0x55cd4ad155ca - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he9fe6bf1a39182e1
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:44:22
4: 0x55cd4ad2fe9e - core::fmt::write::h032658c119c720d7
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/fmt/mod.rs:1208:17
5: 0x55cd4ad13395 - std::io::Write::write_fmt::h299fc90dfae41c0d
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/io/mod.rs:1682:15
6: 0x55cd4ad15395 - std::sys_common::backtrace::_print::heb70d25df9937e3f
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:47:5
7: 0x55cd4ad15395 - std::sys_common::backtrace::print::had745c0a76b8b521
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:34:9
8: 0x55cd4ad16a1f - std::panicking::default_hook::{{closure}}::h1ea782cdfa2fd097
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:267:22
9: 0x55cd4ad1675b - std::panicking::default_hook::h1cc3af63455a163c
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:286:9
10: 0x55cd4ad1712c - std::panicking::rust_panic_with_hook::h5cafdc4b3bfd5528
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:688:13
11: 0x55cd4ad16ec9 - std::panicking::begin_panic_handler::{{closure}}::hf31c60f40775892c
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:579:13
12: 0x55cd4ad15a7c - std::sys_common::backtrace::__rust_end_short_backtrace::h28a5c7be595826cd
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:137:18
13: 0x55cd4ad16bd2 - rust_begin_unwind
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
14: 0x55cd4ac166d3 - core::panicking::panic_fmt::h8fa27a0b37dd98b7
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
15: 0x55cd4ac16aa3 - core::result::unwrap_failed::h62abf61e411aaa08
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/result.rs:1791:5
16: 0x55cd4ac170a4 - core::result::Result<T,E>::unwrap::h850aa9912a25744f
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/result.rs:1113:23
17: 0x55cd4ac184c8 - scream_receiver::start::h14417ac5a526b054
at /home/jens/projects/scream/scream/gstscream/src/receiver.rs:31:23
18: 0x55cd4ac183d0 - scream_receiver::main::hd25da661dfae5371
at /home/jens/projects/scream/scream/gstscream/src/receiver.rs:27:5
19: 0x55cd4ac1cdab - core::ops::function::FnOnce::call_once::he5e3d79f35dcf7fb
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
20: 0x55cd4ac18b8e - std::sys_common::backtrace::__rust_begin_short_backtrace::h2f1709f5e29ffc64
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/sys_common/backtrace.rs:121:18
21: 0x55cd4ac18c01 - std::rt::lang_start::{{closure}}::h271c45bdd1ca2522
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:166:18
22: 0x55cd4ad103ec - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::hfa1c3687c9a20bb8
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:606:13
23: 0x55cd4ad103ec - std::panicking::try::do_call::h0497133ebe1341e5
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:483:40
24: 0x55cd4ad103ec - std::panicking::try::h6c3de05c7ca5d07f
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:447:19
25: 0x55cd4ad103ec - std::panic::catch_unwind::h969058ecb5334b30
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panic.rs:137:14
26: 0x55cd4ad103ec - std::rt::lang_start_internal::{{closure}}::h0de6d98cafb42a58
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:148:48
27: 0x55cd4ad103ec - std::panicking::try::do_call::h77301dcf43953993
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:483:40
28: 0x55cd4ad103ec - std::panicking::try::h45b05523a2fe135a
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:447:19
29: 0x55cd4ad103ec - std::panic::catch_unwind::hd95cea544b2b9bd2
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panic.rs:137:14
30: 0x55cd4ad103ec - std::rt::lang_start_internal::hd16e6ff7bf05a444
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:148:20
31: 0x55cd4ac18bda - std::rt::lang_start::hd3f45e4c7f7026be
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/rt.rs:165:17
32: 0x55cd4ac18a9e - main
33: 0x7f3fc4750d0a - __libc_start_main
34: 0x55cd4ac16bea - _start
35: 0x0 -

RTCP CC Feedback payload type value?

In mentioned version 2 of avtcore-cc-feedback draft the PT in feed back is mentioned as 205.

But in code gstreamer plugin code is creating the feedback as 205 which was proper. But the streamRX file outside the gstreamer module creating feedback with PT 207.

https://github.com/EricssonResearch/scream/blob/master/code/ScreamRx.cpp

Are the files present outside the gstreamer module uptodate? Can we use the files outside the gstreamer to integrate in the application?

SDP param for SCReAM

Hi All,
Is there any defined SDP attribute to communicate the SCReAM support. Form this rfc4585 RFC I can see defined sdp for Generic nack.

Rate adaptation seemingly unstable

Hello,

I've been working with SCReAM a bit more lately, and I've encountered an issue where when using the GStreamer elements over a constrained network link, the rate adaptation seems unstable. I'm trying to simulate what happens when during a stream, the network capacity drops below the value configured as the maximum bit rate for the SCReAM sender. The sender is configured with a maximum bit rate of 10Mbit/s, using the settings -initrate 2500 -minrate 500 -maxrate 10000 -nosummary. The full GStreamer sending pipeline is below:

export SENDPIPELINE="videotestsrc is-live=true pattern=\"smpte\" horizontal-speed=10 ! video/x-raw,format=I420,width=1920,height=1080,framerate=25/1 ! x264enc name=video threads=4 speed-preset=ultrafast tune=fastdecode+zerolatency ! queue ! rtph264pay ssrc=1 ! queue max-size-buffers=2 max-size-bytes=0 max-size-time=0 ! screamtx name=screamtx params=\" -initrate 2500 -minrate 500 -maxrate 10000 -nosummary\" ! udpsink host=10.0.0.168 port=5000 sync=true rtpbin name=r udpsrc port=6001 address=10.0.0.194 ! queue ! screamtx.rtcp_sink screamtx.rtcp_src ! r.recv_rtcp_sink_0 "

I'm using the netem tool to constrain the bandwidth of the link to include 40ms of latency at each end (i.e. 80ms RTT), and limiting the sending rate of both machines to 8Mbit/s:

sudo tc qdisc add dev enp0s31f6 root netem delay 40ms rate 8Mbit limit 40

This is a graph of the actual transmission rate (green) and the target encoder bit rate (blue) looks like with the network restriction applied for a full five minutes:

I think it's safe to say that the target bit rate selected is quite erratic, and it doesn't seem to match up with the graphs shown in README.md, where the line does seem to wobble a bit but it stays tightly bound around one point. I've also run the scream_bw_test_tx/rx application and I get results like this, which show a still unstable target encoder bitrate but it's a lot more closely grouped.

Using iperf3 in UDP mode, I see that the actual performance of the network is fairly stable, sending 10Mbit/s of traffic results in a pretty uniform 7.77Mbit/s of actual throughput.

I suppose my real question is - is this expected behaviour? The huge swings in target bit rate cause a lot of decoding artifacts in the video stream, and I see a lot of packet loss as it keeps bouncing off the limit. If this is not expected behaviour, can you tell me how best to optimise my sending pipeline to suit?

Is scream_01.cpp a valid test program?

I was wondering, whether scream_01.cpp is valid code. It uses an old API.

SCReAM at Media Server

Hi All,

Can we adapt SCReAM congestion algorithm at Mediaserver server or it is only for Mobile platform.

Today at Mediaserver we are supporting single half duplex audio call with 3000(Max) receivers(listeners). From audio processing Thread, we are posting RTP payload and List(Listeners list) to Sender thread. In Sender thread simply write RTP content into listeners UDP socket.

It is difficult to maintain the separate RTP queue for each listener. Is it possible to take the SCReAM algorithm without RTPqueue?

Example for GStreamer WebRTC

The examples for the GStreamer plugin show a direct rtp connection - would this also work with the GStreamer WebRTC implementation?

req_url (Embedded_Ace_Get_Task.cgi) -- 403 Forbidden

Looking to use this webscraper to pull data from a Sierra Wireless RV55 for LTE network testing. I can login successfully with this script but attempting to use the req_url provided generates a 403 forbidden every time:

Output below is just print statements added to the original script in this repo.

login_url: http://192.168.13.31:9191/xml/Connect.xml
login response text: <rows status='0' message='OK' ></rows
request url: http://192.168.13.31:9191/cgi-bin/Embedded_Ace_Get_Task.cgi
request text: <html><head><title>403 Forbidden</title></head><body><h1>Forbidden</h1></body></html>

I know this was originally written for the RV50X but it looks like both models are using AirLinkOS and the URLs all seem to line up. With the network console up in Chrome DevTools I can verify the req_url you have specified in this repo is the same http://192.168.13.31:9191/cgi-bin/Embedded_Ace_Get_Task.cgi

Is there something more to making this work that's not included in the repo? It almost seems like maybe the CSRF token or the other cookie value included in the payload may be it but I thought I'd see if there's something special I need before I can make this work.

Latest version is overshooting

I upgraded the scream version to latest version and now it is overshooting. I always test this connecting a desktop client to an iphone client and simulating different bandwidth constraints in the iphone device with Network Link Conditioner.

With previous version (1-2 months ago old) it is never overshooting (even if estimation can be sometimes 100kbps below the configured bandwidth).

With the new version (today) it overshoots many times (f.e. simulating 200 kbps I'm getting 350-400 kbps constantly now).

I'm rolling back to the previous version but I'm reporting it just in case it helps.

PD. Maybe there is a new API or I should be using the new version in a different way, but I don't think it is the case.

Compilation issue

I was following the instructions at https://github.com/EricssonResearch/scream/tree/master/code/gscream and came across a compilation issue:
The ScreamRx.h header in scream/code/gscream/gst-gscreamrx/gst-plugin/src needs to be changed to a symbolic link pointing to ../../../../ScreamRx.h similar to the .cpp file. (the header is out of sync with the source file) and autogen.sh fails to compile.

Estimation is very low under small constant packet loss

When simulating small packet loss (1%) but constant I get very low bandwidth estimations (close to the minimum configured). Is that expected?

I simulate the packet loss using Network Link Conditioner in an iOS device.

Comparing congestion control algorithms

Is there any work in progress to compare different congestion control algorithms under same conditions?

It would be great to have tools/framework to simulate different network conditions and test scream, gcc, sprout....

Something like https://github.com/EricssonResearch/scream/blob/master/code/scream_01.cpp test but with different recorded network scenarios and being able to run it against other algorithms.

I would be interested in collaborate on this kind of tool / framework.

RtpQueue is full with newCc after 65536 seconds (max uint32_t in ntp domain)

Hi,

ScreamTx rust plugin constantly logs "RtpQueue is full" after running for 65536 seconds (65536 * 65536 in ntp domain = 4294967296 = max uint32_t). For sure it is not ok to keep ntp domain time in a uint32_t variable type.
It happens when no receiver is connected.
After this point, the receiver will not be able to receive any RTP packet.
BTW, is there a way to reset screamtx without recreating the pipeline or re-inserting a new instance of screamtx?
I have attached 2 logs when this happened:
repro_queue_full1.zip
repro_queue_full2.zip

GStreamer plugins build fails

Hi,
I'm trying to build the GScream plugins on an x86_64 machine running Ubuntu 18.04. My GST_PLUGIN_PATH points to /usr/lib/x86_64-linux-gnu/gstreamer-1.0/

I follow the instructions on the readme page of gscream. I ran the autogen.sh script first and then make. Unfortunately, make fails with the below error:

vortex@vortex:~/code/scream/code/gscream/gst-gscreamtx/gst-plugin$ make
make  all-recursive
make[1]: Entering directory '/home/vortex/code/scream/code/gscream/gst-gscreamtx/gst-plugin'
Making all in src
make[2]: Entering directory '/home/vortex/code/scream/code/gscream/gst-gscreamtx/gst-plugin/src'
/bin/bash ../libtool  --tag=CXX --tag=disable-static  --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/     -g -O2 -MT libgstgscreamtx_la-gstgscreamtx.lo -MD -MP -MF .deps/libgstgscreamtx_la-gstgscreamtx.Tpo -c -o libgstgscreamtx_la-gstgscreamtx.lo `test -f 'gstgscreamtx.cpp' || echo './'`gstgscreamtx.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/ -g -O2 -MT libgstgscreamtx_la-gstgscreamtx.lo -MD -MP -MF .deps/libgstgscreamtx_la-gstgscreamtx.Tpo -c gstgscreamtx.cpp  -fPIC -DPIC -o .libs/libgstgscreamtx_la-gstgscreamtx.o
In file included from gstgscreamtx.h:51:0,
                 from gstgscreamtx.cpp:53:
ScreamTx.h:1:1: error: expected unqualified-id before ‘.’ token
 ../../../../ScreamTx.h
 ^
In file included from gstgscreamtx.cpp:54:0:
ScreamTx.h:1:1: error: expected unqualified-id before ‘.’ token
 ../../../../ScreamTx.h
 ^
gstgscreamtx.cpp:89:29: error: variable or field ‘gst_g_scream_tx_class_init’ declared void
 gst_g_scream_tx_class_init (GstgScreamTxClass * klass)
                             ^~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:89:29: error: ‘GstgScreamTxClass’ was not declared in this scope
gstgscreamtx.cpp:89:29: note: suggested alternative: ‘GstStreamClass’
 gst_g_scream_tx_class_init (GstgScreamTxClass * klass)
                             ^~~~~~~~~~~~~~~~~
                             GstStreamClass
gstgscreamtx.cpp:89:49: error: ‘klass’ was not declared in this scope
 gst_g_scream_tx_class_init (GstgScreamTxClass * klass)
                                                 ^~~~~
gstgscreamtx.cpp:89:49: note: suggested alternative: ‘class’
 gst_g_scream_tx_class_init (GstgScreamTxClass * klass)
                                                 ^~~~~
                                                 class
gstgscreamtx.cpp:128:23: error: variable or field ‘gst_g_scream_tx_init’ declared void
 gst_g_scream_tx_init (GstgScreamTx * filter)
                       ^~~~~~~~~~~~
gstgscreamtx.cpp:128:23: error: ‘GstgScreamTx’ was not declared in this scope
gstgscreamtx.cpp:128:23: note: suggested alternative: ‘GstStream’
 gst_g_scream_tx_init (GstgScreamTx * filter)
                       ^~~~~~~~~~~~
                       GstStream
gstgscreamtx.cpp:128:38: error: ‘filter’ was not declared in this scope
 gst_g_scream_tx_init (GstgScreamTx * filter)
                                      ^~~~~~
gstgscreamtx.cpp:128:38: note: suggested alternative: ‘fcvt_r’
 gst_g_scream_tx_init (GstgScreamTx * filter)
                                      ^~~~~~
                                      fcvt_r
gstgscreamtx.cpp: In function ‘void gst_g_scream_tx_set_property(GObject*, guint, const GValue*, GParamSpec*)’:
gstgscreamtx.cpp:167:3: error: ‘GstgScreamTx’ was not declared in this scope
   GstgScreamTx *filter = GST_GSCREAMTX (object);
   ^~~~~~~~~~~~
gstgscreamtx.cpp:167:3: note: suggested alternative: ‘GstStream’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
   ^~~~~~~~~~~~
   GstStream
gstgscreamtx.cpp:167:17: error: ‘filter’ was not declared in this scope
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                 ^~~~~~
gstgscreamtx.cpp:167:17: note: suggested alternative: ‘fcvt_r’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                 ^~~~~~
                 fcvt_r
In file included from /usr/include/glib-2.0/gobject/gobject.h:24:0,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/gstreamer-1.0/gst/gstenumtypes.h:7,
                 from /usr/include/gstreamer-1.0/gst/gst.h:31,
                 from gstgscreamtx.cpp:51:
/usr/include/glib-2.0/gobject/gtype.h:2224:10: error: expected primary-expression before ‘)’ token
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
          ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:167:26: note: in expansion of macro ‘GST_GSCREAMTX’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                          ^~~~~~~~~~~~~
/usr/include/glib-2.0/gobject/gtype.h:2224:12: error: expected ‘)’ before ‘g_type_check_instance_cast’
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
            ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:167:26: note: in expansion of macro ‘GST_GSCREAMTX’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                          ^~~~~~~~~~~~~
gstgscreamtx.cpp:167:48: error: expected ‘)’ before ‘;’ token
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                                                ^
gstgscreamtx.cpp:167:48: error: expected ‘)’ before ‘;’ token
gstgscreamtx.cpp: In function ‘void gst_g_scream_tx_get_property(GObject*, guint, GValue*, GParamSpec*)’:
gstgscreamtx.cpp:186:3: error: ‘GstgScreamTx’ was not declared in this scope
   GstgScreamTx *filter = GST_GSCREAMTX (object);
   ^~~~~~~~~~~~
gstgscreamtx.cpp:186:3: note: suggested alternative: ‘GstStream’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
   ^~~~~~~~~~~~
   GstStream
gstgscreamtx.cpp:186:17: error: ‘filter’ was not declared in this scope
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                 ^~~~~~
gstgscreamtx.cpp:186:17: note: suggested alternative: ‘fcvt_r’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                 ^~~~~~
                 fcvt_r
In file included from /usr/include/glib-2.0/gobject/gobject.h:24:0,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/gstreamer-1.0/gst/gstenumtypes.h:7,
                 from /usr/include/gstreamer-1.0/gst/gst.h:31,
                 from gstgscreamtx.cpp:51:
/usr/include/glib-2.0/gobject/gtype.h:2224:10: error: expected primary-expression before ‘)’ token
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
          ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:186:26: note: in expansion of macro ‘GST_GSCREAMTX’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                          ^~~~~~~~~~~~~
/usr/include/glib-2.0/gobject/gtype.h:2224:12: error: expected ‘)’ before ‘g_type_check_instance_cast’
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
            ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:186:26: note: in expansion of macro ‘GST_GSCREAMTX’
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                          ^~~~~~~~~~~~~
gstgscreamtx.cpp:186:48: error: expected ‘)’ before ‘;’ token
   GstgScreamTx *filter = GST_GSCREAMTX (object);
                                                ^
gstgscreamtx.cpp:186:48: error: expected ‘)’ before ‘;’ token
gstgscreamtx.cpp: At global scope:
gstgscreamtx.cpp:199:14: error: variable or field ‘getTime’ declared void
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
              ^~~~~~~~~~~~
gstgscreamtx.cpp:199:14: error: ‘GstgScreamTx’ was not declared in this scope
gstgscreamtx.cpp:199:14: note: suggested alternative: ‘GstStream’
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
              ^~~~~~~~~~~~
              GstStream
gstgscreamtx.cpp:199:28: error: ‘filter’ was not declared in this scope
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
                            ^~~~~~
gstgscreamtx.cpp:199:28: note: suggested alternative: ‘fcvt_r’
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
                            ^~~~~~
                            fcvt_r
gstgscreamtx.cpp:199:36: error: expected primary-expression before ‘float’
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
                                    ^~~~~
gstgscreamtx.cpp:199:59: error: expected primary-expression before ‘*’ token
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
                                                           ^
gstgscreamtx.cpp:199:60: error: ‘time_ntp’ was not declared in this scope
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
                                                            ^~~~~~~~
gstgscreamtx.cpp:199:60: note: suggested alternative: ‘time_t’
 void getTime(GstgScreamTx *filter, float *time_s, guint32 *time_ntp)
                                                            ^~~~~~~~
                                                            time_t
gstgscreamtx.cpp: In function ‘gboolean txTimerEvent(GstClock*, GstClockTime, GstClockID, gpointer)’:
gstgscreamtx.cpp:216:3: error: ‘GstgScreamTx’ was not declared in this scope
   GstgScreamTx *filter = (GstgScreamTx*) user_data;
   ^~~~~~~~~~~~
gstgscreamtx.cpp:216:3: note: suggested alternative: ‘GstStream’
   GstgScreamTx *filter = (GstgScreamTx*) user_data;
   ^~~~~~~~~~~~
   GstStream
gstgscreamtx.cpp:216:17: error: ‘filter’ was not declared in this scope
   GstgScreamTx *filter = (GstgScreamTx*) user_data;
                 ^~~~~~
gstgscreamtx.cpp:216:17: note: suggested alternative: ‘fcvt_r’
   GstgScreamTx *filter = (GstgScreamTx*) user_data;
                 ^~~~~~
                 fcvt_r
gstgscreamtx.cpp:216:40: error: expected primary-expression before ‘)’ token
   GstgScreamTx *filter = (GstgScreamTx*) user_data;
                                        ^
gstgscreamtx.cpp:219:3: error: ‘getTime’ was not declared in this scope
   getTime(filter,&time,&time_ntp);
   ^~~~~~~
gstgscreamtx.cpp:219:3: note: suggested alternative: ‘gmtime’
   getTime(filter,&time,&time_ntp);
   ^~~~~~~
   gmtime
gstgscreamtx.cpp: In function ‘void on_receiving_rtcp(GObject*, GstBuffer*, gboolean, GObject*)’:
gstgscreamtx.cpp:253:3: error: ‘GstgScreamTx’ was not declared in this scope
   GstgScreamTx *filter = (GstgScreamTx*)object;
   ^~~~~~~~~~~~
gstgscreamtx.cpp:253:3: note: suggested alternative: ‘GstStream’
   GstgScreamTx *filter = (GstgScreamTx*)object;
   ^~~~~~~~~~~~
   GstStream
gstgscreamtx.cpp:253:17: error: ‘filter’ was not declared in this scope
   GstgScreamTx *filter = (GstgScreamTx*)object;
                 ^~~~~~
gstgscreamtx.cpp:253:17: note: suggested alternative: ‘fcvt_r’
   GstgScreamTx *filter = (GstgScreamTx*)object;
                 ^~~~~~
                 fcvt_r
gstgscreamtx.cpp:253:40: error: expected primary-expression before ‘)’ token
   GstgScreamTx *filter = (GstgScreamTx*)object;
                                        ^
gstgscreamtx.cpp:257:11: error: ‘filter_’ was not declared in this scope
   getTime(filter_,&time,&time_ntp);
           ^~~~~~~
gstgscreamtx.cpp:257:3: error: ‘getTime’ was not declared in this scope
   getTime(filter_,&time,&time_ntp);
   ^~~~~~~
gstgscreamtx.cpp:257:3: note: suggested alternative: ‘gmtime’
   getTime(filter_,&time,&time_ntp);
   ^~~~~~~
   gmtime
gstgscreamtx.cpp: In function ‘GstFlowReturn gst_g_scream_tx_chain(GstPad*, GstObject*, GstBuffer*)’:
gstgscreamtx.cpp:399:3: error: ‘GstgScreamTx’ was not declared in this scope
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
   ^~~~~~~~~~~~
gstgscreamtx.cpp:399:3: note: suggested alternative: ‘GstStream’
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
   ^~~~~~~~~~~~
   GstStream
gstgscreamtx.cpp:399:17: error: ‘filter’ was not declared in this scope
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
                 ^~~~~~
gstgscreamtx.cpp:399:17: note: suggested alternative: ‘fcvt_r’
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
                 ^~~~~~
                 fcvt_r
In file included from /usr/include/glib-2.0/gobject/gobject.h:24:0,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/gstreamer-1.0/gst/gstenumtypes.h:7,
                 from /usr/include/gstreamer-1.0/gst/gst.h:31,
                 from gstgscreamtx.cpp:51:
/usr/include/glib-2.0/gobject/gtype.h:2224:10: error: expected primary-expression before ‘)’ token
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
          ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:399:26: note: in expansion of macro ‘GST_GSCREAMTX’
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
                          ^~~~~~~~~~~~~
/usr/include/glib-2.0/gobject/gtype.h:2224:12: error: expected ‘)’ before ‘g_type_check_instance_cast’
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
            ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:399:26: note: in expansion of macro ‘GST_GSCREAMTX’
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
                          ^~~~~~~~~~~~~
gstgscreamtx.cpp:399:48: error: expected ‘)’ before ‘;’ token
   GstgScreamTx *filter = GST_GSCREAMTX (parent);
                                                ^
gstgscreamtx.cpp:399:48: error: expected ‘)’ before ‘;’ token
In file included from /usr/include/glib-2.0/gobject/gobject.h:24:0,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/gstreamer-1.0/gst/gstenumtypes.h:7,
                 from /usr/include/gstreamer-1.0/gst/gst.h:31,
                 from gstgscreamtx.cpp:51:
/usr/include/glib-2.0/gobject/gtype.h:2224:10: error: expected primary-expression before ‘)’ token
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
          ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:401:12: note: in expansion of macro ‘GST_GSCREAMTX’
   filter = GST_GSCREAMTX (parent);
            ^~~~~~~~~~~~~
/usr/include/glib-2.0/gobject/gtype.h:2224:12: error: expected ‘)’ before ‘g_type_check_instance_cast’
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
            ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:401:12: note: in expansion of macro ‘GST_GSCREAMTX’
   filter = GST_GSCREAMTX (parent);
            ^~~~~~~~~~~~~
gstgscreamtx.cpp:401:34: error: expected ‘)’ before ‘;’ token
   filter = GST_GSCREAMTX (parent);
                                  ^
gstgscreamtx.cpp:401:34: error: expected ‘)’ before ‘;’ token
gstgscreamtx.cpp:419:3: error: ‘getTime’ was not declared in this scope
   getTime(filter,&time,&time_ntp);
   ^~~~~~~
gstgscreamtx.cpp:419:3: note: suggested alternative: ‘gmtime’
   getTime(filter,&time,&time_ntp);
   ^~~~~~~
   gmtime
gstgscreamtx.cpp:427:13: error: ‘filter_’ was not declared in this scope
     switch (filter_->media_src) {
             ^~~~~~~
gstgscreamtx.cpp:463:13: error: ‘filter_’ was not declared in this scope
             filter_->screamTx->getShortLog(time, buf2);
             ^~~~~~~
gstgscreamtx.cpp: In function ‘gboolean gst_g_scream_tx_sink_event(GstPad*, GstObject*, GstEvent*)’:
gstgscreamtx.cpp:505:3: error: ‘GstgScreamTx’ was not declared in this scope
   GstgScreamTx *filter;
   ^~~~~~~~~~~~
gstgscreamtx.cpp:505:3: note: suggested alternative: ‘GstStream’
   GstgScreamTx *filter;
   ^~~~~~~~~~~~
   GstStream
gstgscreamtx.cpp:505:17: error: ‘filter’ was not declared in this scope
   GstgScreamTx *filter;
                 ^~~~~~
gstgscreamtx.cpp:505:17: note: suggested alternative: ‘fcvt_r’
   GstgScreamTx *filter;
                 ^~~~~~
                 fcvt_r
In file included from /usr/include/glib-2.0/gobject/gobject.h:24:0,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/gstreamer-1.0/gst/gstenumtypes.h:7,
                 from /usr/include/gstreamer-1.0/gst/gst.h:31,
                 from gstgscreamtx.cpp:51:
/usr/include/glib-2.0/gobject/gtype.h:2224:10: error: expected primary-expression before ‘)’ token
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
          ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:508:12: note: in expansion of macro ‘GST_GSCREAMTX’
   filter = GST_GSCREAMTX (parent);
            ^~~~~~~~~~~~~
/usr/include/glib-2.0/gobject/gtype.h:2224:12: error: expected ‘)’ before ‘g_type_check_instance_cast’
     ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
            ^
/usr/include/glib-2.0/gobject/gtype.h:482:66: note: in expansion of macro ‘_G_TYPE_CIC’
 #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
                                                                  ^~~~~~~~~~~
gstgscreamtx.h:61:4: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
   (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_GSCREAMTX,GstgScreamTx))
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstgscreamtx.cpp:508:12: note: in expansion of macro ‘GST_GSCREAMTX’
   filter = GST_GSCREAMTX (parent);
            ^~~~~~~~~~~~~
gstgscreamtx.cpp:508:34: error: expected ‘)’ before ‘;’ token
   filter = GST_GSCREAMTX (parent);
                                  ^
gstgscreamtx.cpp:508:34: error: expected ‘)’ before ‘;’ token
gstgscreamtx.cpp:520:5: error: ‘filter_’ was not declared in this scope
     filter_ = filter;
     ^~~~~~~
In file included from gstgscreamtx.cpp:53:0:
gstgscreamtx.cpp: In function ‘gboolean gscreamtx_init(GstPlugin*)’:
gstgscreamtx.h:59:4: error: ‘gst_g_scream_tx_get_type’ was not declared in this scope
   (gst_g_scream_tx_get_type())
    ^
gstgscreamtx.cpp:587:7: note: in expansion of macro ‘GST_TYPE_GSCREAMTX’
       GST_TYPE_GSCREAMTX);
       ^~~~~~~~~~~~~~~~~~
gstgscreamtx.h:59:4: note: suggested alternative: ‘gst_g_scream_tx_get_property’
   (gst_g_scream_tx_get_type())
    ^
gstgscreamtx.cpp:587:7: note: in expansion of macro ‘GST_TYPE_GSCREAMTX’
       GST_TYPE_GSCREAMTX);
       ^~~~~~~~~~~~~~~~~~
Makefile:489: recipe for target 'libgstgscreamtx_la-gstgscreamtx.lo' failed
make[2]: *** [libgstgscreamtx_la-gstgscreamtx.lo] Error 1
make[2]: Leaving directory '/home/vortex/code/scream/code/gscream/gst-gscreamtx/gst-plugin/src'
Makefile:406: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/vortex/code/scream/code/gscream/gst-gscreamtx/gst-plugin'
Makefile:338: recipe for target 'all' failed
make: *** [all] Error 2

What am I missing here? Any pointers are much appreciated.

Get no RTCP packets in the sender

I've tried to run sender and receiver on two different gentoo systems.
But the sender is always saying: "RTP queue discarded for SSRC"

By commenting out some debugging code in the sender plugin, I think the RTCP receive callback was never fired.
My workaround for now was to don't set the bind-port parameter of the udpsinks and -srcs.
As I see gstreamer sets reuse on the UDP sockets by default, so actually it should work.

SIGSEGV when receving rtcp with not known ssrc

I've got this Segmentation Fault, when I restart my sender fast and keep the receiver running.
Then the receiver sending feedback with for a SSRC from the old session.

#0 0x00007ffff2dad58c in ScreamTx::Stream::isRtpQueueDiscard (this=0x0) at ScreamTx.cpp:2008
#1 0x00007ffff2dac990 in ScreamTx::Stream::getTargetBitrate (this=0x0) at ScreamTx.cpp:1749
#2 0x00007ffff2da987f in ScreamTx::getTargetBitrate (this=0x5555559aa330, ssrc=3462544249) at ScreamTx.cpp:885
#3 0x00007ffff2da6327 in on_receiving_rtcp (session=0x555555bc61a0, buffer=0x7fffdc0279a0, early=1436201072, object=0x7ffff0eec030)
at gstgscreamtx.cpp:307

My hotfix is to return 0 in ScreamTx::Stream::getTargetBitrate if I couldn't find the stream by SSRC.

Memory Leak due to RTCP

Hi,
i played recently a bit with the plugin-element - great tool.
Unfortunately, there seems to be a memory leak due to the exchange of RTCP-packages. The RAM of the sender increases roughly by ~10MB per ~10 minutes starting right from the beginning. The receiver takes some time 2-5min in my case, and then also starts to build up RAM and CPU consumption (up to 100% CPU after an hour).
Hints:

• If I deactivate sending RTCP from the sender, the memory leakage in the reciever stops.
• In the debug-output (GST_DEBUG=rtpsession:5) on the sender of the rr, I saw that the second sdes entry (data=gstreamer) has been disappeared, if a gscreamrx-element is used in the reciever.
• If i remove the gscreamtx element, the memory consumption still increases on the tx-side. If i remove both gscream elements the memory leak stops.
• If the RTCP-buffer is freed in the "on_recieving_rtcp"-callback, the memory-leak stops. However, with the downside, that the rtpsession does not have the rtcp-feedback available anymore either.
• I run on localhost->localhost with GStreamer 1.14.5 and the build based on the master branch.

Thanks for your work!

Note: Please also update the file ScreamRx.h in the gst-plugin folder. It does not match with referenced ScreamRx.cpp in the main-folder any more. It is difficult to determine the latest version among multiple versions of the same file with same name in different locations.

GStreamer element timestamping issues

Hello,

I’ve been trying to do some testing recently with SCReAM to understand how it performs with various levels of network quality and performance. I’m using Gstreamer to encode and decode some video streams, and then attempting to use your gstscream elements to do this all in-line, but I’m having some problems. I’m attempting to apply network conditions using the Linux tc and netem tools to apply caps to network throughput, adding jitter, random packet loss and increasing latency.

The primary issue that I’m having is that the scream elements cause timestamping problems on my platform. This manifests itself as lots of dropped frames at the receiver. This is happening even in my control tests, where I’m not applying any conditions to my test network. Using something like iperf3 in UDP mode, I can send and receive ~540Mbit/s of traffic between the sender and receiver but I’m configuring the screamtx maxrate as 10Mbit/s, so I don’t think I should be encountering any on-the-wire problems.

The pipelines I’m using are quite similar to what you’re using in the sender.sh and receiver.sh scripts available in gstscream/scripts/, except I’m adding caps to force the videotestsrc to output 720p video:

Sender:
gst-launch-1.0 -e videotestsrc is-live=true ! "video/x-raw,format=I420,width=1280,height=720,framerate=25/1" ! x264enc name=video threads=4 speed-preset=ultrafast tune=fastdecode+zerolatency bitrate=8000 ! tee name=t t. ! queue ! rtph264pay ssrc=1 config-interval=-1 ! queue max-size-buffers=2 max-size-bytes=0 max-size-time=0 ! screamtx name=screamtx params=" -forceidr -ect 1 -initrate 2500 -minrate 500 -maxrate 10000 " ! udpsink host=192.168.56.103 port=5000 sync=false t. ! queue ! fakesink silent=false sync=false rtpbin name=r udpsrc port=5001 address=192.168.56.102 ! queue ! screamtx.rtcp_sink screamtx.rtcp_src ! r.recv_rtcp_sink_0

Receiver:
gst-launch-1.0 -e rtpbin name=rtpbin udpsrc port=5000 ! screamrx name=screamrx screamrx.src ! application/x-rtp,media=video,encoding-name=H264,clock-rate=90000,payload=96 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! h264parse ! avdec_h264 name=videodecoder ! queue max-size-buffers=1 max-size-bytes=0 max-size-time=0 ! glupload ! glcolorconvert ! fpsdisplaysink video-sink=\"glimagesinkelement\" rtpbin.send_rtcp_src_0 ! funnel name=f ! udpsink host=192.168.56.102 port=5001 sync=false async=false screamrx.rtcp_src ! f.

I get lots of the following output on the receiver:
0:00:44.559898508 2231 0x7fdaec01d800 WARN videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<videodecoder> Dropping frame due to QoS. start:0:00:44.194611002 deadline:0:00:44.194611002 earliest_time:0:00:44.205054014 0:00:47.037605415 2231 0x7fdaec01d800 WARN videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<videodecoder> Dropping frame due to QoS. start:0:00:46.674504689 deadline:0:00:46.674504689 earliest_time:0:00:46.689336031 0:00:47.066500703 2231 0x7fdaec01d800 WARN videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<videodecoder> Dropping frame due to QoS. start:0:00:46.714503414 deadline:0:00:46.714503414 earliest_time:0:00:46.759894609

If I remove the screamtx and screamrx elements, I don't see any of this behaviour. Using the Gst-Shark interlatency tool, I can see that the amount of latency introduced on buffers in the screamrx element is definitely not consistent, occasionally spiking up to 800ms over an average of 33ms. My current working assumption is that this is what's causing my decode issues.

I have taken your code and compiled it against both GStreamer 1.18.3 and 1.20, but I seem to get similar results in both cases. I’ve also tried running it both in virtual machines and also on bare metal. Do you have any ideas of what I’m doing wrong?

I’m using Ubuntu 21.10 and Rust 1.56.1 on the host system(s).

Unable to set rtcp-reduced-size

In the receiver I got:
gscream name2 pipeline0

(gst-launch-1.0:11847): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed
SINK EVENT

I think it's releated to g_object_set(&(filter->rtpSession), "rtcp-reduced-size", true, NULL); in gstscreamrx.cpp

scream L4S run error

Hello , after installing scream, I did the Modifying gstreamer to use L4S in gstream.

I then went to run the L4S
. /scripts/receiver.sh
. /scripts/sender.sh

But there was an error, I couldn't test the L4S functionality of scream

The program on the sender side gives an error

Duplicated source files

Asides from #29 there are more duplicated source files around:

bw-test-tool/code/ contains copies (old? modified? both?) of:

• RtpQueue.cpp
• RtpQueue.h
• ScreamRx.cpp
• ScreamRx.h
• ScreamTx.cpp
• ScreamTx.h

These should (probably?) be replaced by symbolic links as well, and the tool adapted.

gscream/gst-gscreamtx/gst-plugin/src/ duplicates these:

• RtpQueue.cpp
• RtpQueue.h

The others are already symlinked. Maybe these two also should?

code/gscream/gst-gscreamtx/gst-plugin/src/ contains two copies…

• CMakeLists.txt
• scream_v_a.cpp
  … from code/ that probably just shouldn’t be there.

I can provide a pull request fixing these, but I cannot estimate the changes needed to the bw-test-tool to adapt.

Unexpected estimations increases under congestion

I'm running some tests in a constrained network (uplink 200kbps) and the bandwidth estimation is usually correct (˜150 kbps) but from time to time there is a sudden increase to 500-700kpbs that creates a lot of congestion.

After debugging it I found that the offending code is the one below. In my case some times delta value is -2.X and in that case the target bitrate is increased X3 instead of decreasing like it is supposed to do according to the comment and my expectations.

                float delta = (kGainDown * offTarget * bytesNewlyAcked * mss / cwnd);
                cwnd += (int)(delta);
                
                /*
                 * Especially when running over low bitrate bottlenecks, it is
                 *  beneficial to reduce the target bitrate a little, it limits
                 *  possible RTP queue delay spikes when congestion window is reduced
                 */
                float rateTotal = 0.0f;
                for (int n = 0; n < nStreams; n++)
                    rateTotal += streams[n]->getMaxRate();
                if (rateTotal < 1.0e5f) {
                    delta = -delta / cwnd;
                    float rateAdjustFactor = (1.0f - delta);
                    for (int n = 0; n < nStreams; n++) {
                        Stream *tmp = streams[n];
                        tmp->targetBitrate = std::max(tmp->minBitrate,
                                                      std::min(tmp->maxBitrate,
                                                               tmp->targetBitrate*rateAdjustFactor));
                    }
                }

In my case these were the values of some relevant variables one of the times I could reproduce the issue:

OffTarget = -7.2
cwnd = -2920
Delta = -2.13

For the time being I will change that code to do nothing if rateAdjustFactor > 1 but I'm not sure of the implications.

This is a graph with encoded and sent bitrate, bandwidth estimation and rtt where you can see how the bwe suddenly increased for no reason in the middle of the session:

Rather large difference between numbers shown

With the bandwidthtester receiver on an 100 Mbit/s ethernet link:

 summary  22.1  Transmit rate = 93584kbps, PLR =  0.00%( 0.00%), RTT = 0.009s, Queue delay = 0.025s
 summary  24.1  Transmit rate = 94336kbps, PLR =  0.00%( 0.00%), RTT = 0.008s, Queue delay = 0.024s
 summary  26.1  Transmit rate = 93545kbps, PLR =  0.00%( 0.00%), RTT = 0.012s, Queue delay = 0.033s

The -log CSV differs rather a lot though: the highest I get (shortly before ^Cing) is:

• 84352424 Media coder bitrate [bps]
• 85207824 Transmitted bitrate [bps]
• 84976040 ACKed bitrate [bps]

That’s about 10 Mbit/s less! Where does this difference come from?

Looking at the code, the “Transmit rate” command line output seems to be tracked completely independently of the values that actually end up in the CSV. This doesn’t make any sense to me… shouldn’t the bandwidth be dependent on how many bytes per second you can actually get through the link?

Isn’t ACKed bitrate (plus packet overhead) the better estimate?

Rust screamtx crash when RtpQueue was cleared

Maybe some thread locking around the RtpQeue in ScreamTx (one thread inserting, another clearing).

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Caught fatal signal - signo:11 code:1 errno:0 addr:0x40
Obtained 17 stack frames.
#0 0x007f9501d10420 in funlockfile
#1 0x007f93c001b575 in packet_free(void*, unsigned int)
#2 0x007f93c0012367 in RtpQueue::clear()
#3 0x007f93c0017772 in ScreamTx::newMediaFrame(unsigned int, unsigned int, int, bool)
#4 0x007f93c001b8b0 in ScreamSenderPush
#5 0x007f937307c50c in gstscream::screamtx::imp::Screamtx::sink_chain::h16200a4896ed69fc
#6 0x007f937307bc41 in _$LT$T$u20$as$u20$gstreamer..subclass..element..ElementImplExt$GT$::catch_panic_pad_function::hdff007fc4fa9d5a3
#7 0x007f937308e65b in gstreamer::pad::trampoline_chain_function::hf3128766d4e94aab
#8 0x007f944c720a58 in gst_pad_chain_data_unchecked
#9 0x007f944c722ed9 in gst_pad_push_data
#10 0x007f944c72a093 in gst_pad_push
#11 0x007f93c0067bf4 in gst_queue_loop
#12 0x007f944c75a207 in gst_task_func
#13 0x007f944c573e04 in g_thread_pool_thread_proxy
#14 0x007f944c573561 in g_thread_proxy
#15 0x007f9501d04609 in start_thread
#16 0x007f9501c27133 in clone

Periodic rate drop with CWND control enabled.

Hello, I am having an issue with periodic excessive rate drop when trying to use scream with ScreamTx::openWindow = false

For verification, I have set up both the sender and receiver on two machines in a local subnet, to eliminate network bandwidth variations. I have several cameras with separate streams using the prioritization functionality.

Stable with ScreamTx::openWindow = true

The transmission is very stable when running with ScreamTx::openWindow = true

Below is the output of a little statistic that I am collecting on ScreamTx::Stream::updateTargetBitrate() to visualise the incidence of different updating scenarios. I print it every 25k calls of said function.

At the bottom (of this image) is a "histogram" of ScreamTx::getTotalTargetBitrate(). You can see that in this setup, in the span of 15M calls, the bitrate remains near the maximum values limited by maximum bitrates. This was measured for about 30+ minutes.

Dipping with ScreamTx::openWindow = false

When enabling CWND control, the target bitrate stays at the same stable maximum level most of the time, but very regularly dips. Sometimes the dip reaches a medium low level and recovers after a short moment, sometimes it dips all the way to minimum bitrates and struggles to recover for tens of seconds. After half an hour or so, it gets stuck in clearing the RtpQueue and never recovers at all.

Here is the same statistic with CWND control. It can be seen that the bitrate has been all over the place, and stayed near minimum 9% of the time.
It can also be seen that many clearings of RtpQueue have been performed due to excessive delay (not Loss or Ecn events), which, I guess is due to cwnd dropping to the minimum (5000) and packets not getting sent thereby. Under normal operation, i observed the cwnd value to be around 130'000.

Here is an example of the bitrates dropping a little bit for a short while and then going all the way down for a longer time.

Question

Are there any obvious things I should try changing or any other values I should monitor to get a clue?

These coefficients are currently set to:
kLossBeta = 0.8
kEcnCeBeta = 0.9

Rust screamtx crash caused by a null buffer passed to rust callback

Rust code does not like null pointers.
RtpQueue.pop() sometimes extracts null items (when the queue is empty?)

Here are three callstacks when it happened:

1:

rtpQueueDelay 0.237793 too large 1 6693.13 RTP queue 123 packets discarded for SSRC 1 hiSeqTx 27367 hiSeqAckendl 0 seqNrOfNextRtp 27368 seqNrOfLastRtp 27490
diff 123
imp.rs: force_idr rc true enabled 1
Error: gst_pad_push: assertion 'GST_IS_BUFFER (buffer)' failed
rtpQueueDelay 0.250488 too large 1 6693.39 RTP queue 133 packets discarded for SSRC 1 hiSeqTx 27500 hiSeqAckendl 0 seqNrOfNextRtp 27501 seqNrOfLastRtp 27633 diff 133
thread '' panicked at 'Screamtx callback srcpad.push failed: Error', src/screamtx/imp.rs:358:22
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
Caught fatal signal - signo:6 code:-6 errno:0 addr:0x3e80001c894
Obtained 15 stack frames.
#0 0x007f521fd86420 in funlockfile
#1 0x007f521fbc100b in gsignal
#2 0x007f521fba0859 in abort
#3 0x007f50e0082b37 in std::sys::unix::abort_internal::hbf9c556da2861ce5
#4 0x007f50e0081252 in rust_panic
#5 0x007f50e00810da in std::panicking::rust_panic_with_hook::hdb4da1ae79c845a5
#6 0x007f50e0080e19 in std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::h02b5b35b126d5cf2
#7 0x007f50e007fbec in std::sys_common::backtrace::__rust_end_short_backtrace::h6c6853376cf416d1
#8 0x007f50e0080b22 in rust_begin_unwind
#9 0x007f50e0049f23 in core::panicking::panic_fmt::hfd9e949092070b66
#10 0x007f50e004a353 in core::result::unwrap_failed::h4d34d8346233eb49
#11 0x007f50e004d2b4 in gstscream::screamtx::imp::callback::hdc9f203da2c8fa8e
#12 0x007f50ec04f8b5 in transmitRtpThread(void*)
#13 0x007f521fd7a609 in start_thread
#14 0x007f521fc9d133 in clone

2:

Warning: Unexpected item 0x7f21040c0ea0 dequeued from queue queue1 (refcounting problem?)
0:46:24.098985438 52690 0x2a33cc0 ERROR queue_dataflow gstqueue.c:1486:gst_queue_push_one: exit because we have no item in the queue
rtpQueueDelay 0.497314 too large 1 2782.61 RTP queue 836 packets discarded for SSRC 1 hiSeqTx 58122 hiSeqAckendl 11191 seqNrOfNextRtp 58123 seqNrOfLastRtp 60763 diff 2641
thread '' panicked at 'Screamtx callback srcpad.push failed: Error', src/screamtx/imp.rs:360:22
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
Caught fatal signal - signo:6 code:-6 errno:0 addr:0x3e80000cdd2
Obtained 17 stack frames.
#0 0x007f22d7c0fcf0 in __sigaction
#1 0x007f22d7c6626b in pthread_kill
#2 0x007f22d7c0fc46 in gsignal
#3 0x007f22d7bf67fc in abort
#4 0x007f2164590327 in std::sys::unix::abort_internal::hf940f5a54d8a80b4
#5 0x007f216458ea42 in rust_panic
#6 0x007f216458e8ca in std::panicking::rust_panic_with_hook::h5cafdc4b3bfd5528
#7 0x007f216458e609 in std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::hf31c60f40775892c
#8 0x007f216458d3dc in std::sys_common::backtrace::__rust_end_short_backtrace::h28a5c7be595826cd
#9 0x007f216458e312 in rust_begin_unwind
#10 0x007f21644d0ee3 in core::panicking::panic_fmt::h8fa27a0b37dd98b7
#11 0x007f21644d1313 in core::result::unwrap_failed::h62abf61e411aaa08
#12 0x007f21644ddb18 in core::result::Result$LT$T$C$E$GT$::expect::h54fe755c33896c5a
#13 0x007f21644e594e in gstscream::screamtx::imp::callback::h11dff52b2a2873a4
#14 0x007f216493d297 in transmitRtpThread(void*)
#15 0x007f22d7c64402 in pthread_condattr_setpshared
#16 0x007f22d7cf3590 in __xmknodat

3, exactly when a refresh happened:

refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
refresh 1035.84 RTP queue 1 packets discarded for SSRC 1
Error: gst_pad_push: assertion 'GST_IS_BUFFER (buffer)' failed
thread '' panicked at 'Screamtx callback srcpad.push failed: Error', src/screamtx/imp.rs:360:22
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
Caught fatal signal - signo:6 code:-6 errno:0 addr:0x3e8000068f4
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
refresh 1035.86 RTP queue 1 packets discarded for SSRC 1
Obtained 17 stack frames.
#0 0x007f3c0f4e5cf0 in __sigaction
#1 0x007f3c0f53c26b in pthread_kill
#2 0x007f3c0f4e5c46 in gsignal
#3 0x007f3c0f4cc7fc in abort
#4 0x007f3aa81fe327 in std::sys::unix::abort_internal::hf940f5a54d8a80b4
#5 0x007f3aa81fca42 in rust_panic
#6 0x007f3aa81fc8ca in std::panicking::rust_panic_with_hook::h5cafdc4b3bfd5528
#7 0x007f3aa81fc609 in std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::hf31c60f40775892c
#8 0x007f3aa81fb3dc in std::sys_common::backtrace::__rust_end_short_backtrace::h28a5c7be595826cd
#9 0x007f3aa81fc312 in rust_begin_unwind
#10 0x007f3aa813eee3 in core::panicking::panic_fmt::h8fa27a0b37dd98b7
#11 0x007f3aa813f313 in core::result::unwrap_failed::h62abf61e411aaa08
#12 0x007f3aa814bb18 in core::result::Result$LT$T$C$E$GT$::expect::h54fe755c33896c5a
#13 0x007f3aa815394e in gstscream::screamtx::imp::callback::h11dff52b2a2873a4
#14 0x007f3b0803a28e in transmitRtpThread(void*)
#15 0x007f3c0f53a402 in pthread_condattr_setpshared
#16 0x007f3c0f5c9590 in __xmknodat