gscreamrx / RTCP feedback problem ? about scream

[IngJohEricsson]

Hi My experience is that answers are more often dumb than the questions. Your pipeline below should work, what is perhaps an issue is that packets are echoed on the local host (127.0.0.1) . I have not tried that, can you try with sender and receiver on different machines (first on the same subnet) and see if that solves the issue ? Regards Ingemar From: Pete Andrews <[email protected]> Sent: den 16 maj 2019 17:19 To: EricssonResearch/scream <[email protected]> Cc: Subscribed <[email protected]> Subject: [EricssonResearch/scream] gscreamrx / RTCP feedback problem ? (#16) 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. 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 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/url?k=69184f3f-35934403-69180fa4-86ef624f95b6-5b8f0491980ff22d&q=1&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Fissues%2F16%3Femail_source%3Dnotifications%26email_token%3DACRZ2GCNEULHKB2NJUBDYXTPVV3MXA5CNFSM4HNNUAT2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUGNC4Q> , or mute the thread <https://protect2.fireeye.com/url?k=d5bd1979-89361245-d5bd59e2-86ef624f95b6-3a665e1aa3cef5f9&q=1&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GCBKN27D6YN2BCVY4LPVV3MXANCNFSM4HNNUATQ> .

[iampeteandrews]

Ingemar -
thanks for the quick response!
so that's what i've tried first. two machines on the same subnet.
i just ran it again... and same results. Video starts ok, but quickly degrades and i get freezes and large grey frames intermittently. again.. lots of RTP queue discarded messages.

what is the error i'm seeing here on the receiver about the G_IS_OBJECT assertion failing?
any idea?

(keep in mind - these pipes work fine without gscreamtx/rx included.)

-pete

[IngJohEricsson]

OK, I need to have a look at this, I have not seen this problem before but then again my gstreamer programming skills are not too good, it is possible that I did something wrong in gstgscreamrx.cpp /Ingemar From: Pete Andrews <[email protected]> Sent: den 16 maj 2019 19:21 To: EricssonResearch/scream <[email protected]> Cc: Ingemar Johansson S <[email protected]>; Comment <[email protected]> Subject: Re: [EricssonResearch/scream] gscreamrx / RTCP feedback problem ? (#16) Ingemar - thanks for the quick response! so that's what i've tried first. two machines on the same subnet. i just ran it again... and same results. Video starts ok, but quickly degrades and i get freezes and large grey frames intermittently. again.. lots of RTP queue discarded messages. what is the error i'm seeing here on the receiver about the G_IS_OBJECT assertion failing? any idea?

…

-pete — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/url?k=cad40a3d-96000196-cad44aa6-864b0d136b87-b8e5cfe47c2af6f6&q=1&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Fissues%2F16%3Femail_source%3Dnotifications%26email_token%3DACRZ2GFTIXQBKMOKQ3D7WMTPVWJWBA5CNFSM4HNNUAT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVSPVIQ%23issuecomment-493157026> , or mute the thread <https://protect2.fireeye.com/url?k=c4f3db20-9827d08b-c4f39bbb-864b0d136b87-aad58068b335003a&q=1&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GB7MDTLOTRKHVSGTQDPVWJWBANCNFSM4HNNUATQ> .

[iampeteandrews]

ok thanks...i also have pcaps i can provide if thats something you want...

-pete

[iampeteandrews]

wireshark shows RTCP feedback packets getting back to the sender, however the RTCP Feedback message type (FMT) is always 0 in the Receiver reports (Generic RTP Feedback)

is that correct behavior?

[IngJohEricsson]

OK, thanks. I tried with both sender and receiver on the same PC and it definitely shows some odd behavior. Sometimes it works, sometimes not. What I wonder here is if is the fact that the same RTCP port is used for both sender and receiver RTCP that causes the issue. I will leave that local sender and receiver setup for the time being as it is not a real-life scenario. One question however regarding the pipelines you set up (repeated below). Is the sender and receiver of two different PCs in this case. It seems strange that the receiver sends RTCP to 127.0.0.1 which is the local interface ? /Ingemar ======= 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 ======== From: Pete Andrews <[email protected]> Sent: den 17 maj 2019 17:30 To: EricssonResearch/scream <[email protected]> Cc: Ingemar Johansson S <[email protected]>; Comment <[email protected]> Subject: Re: [EricssonResearch/scream] gscreamrx / RTCP feedback problem ? (#16) wireshark shows RTCP feedback packets getting back to the sender, however the RTCP Feedback message type (FMT) is always 0. is that correct behavior? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/url?k=64352ce8-38e126e1-64356c73-86740465fc08-b686498b78b074e5&q=1&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Fissues%2F16%3Femail_source%3Dnotifications%26email_token%3DACRZ2GA4O3H6B6T2CDKBHJTPV3FQ7A5CNFSM4HNNUAT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVCQPI%23issuecomment-493496381> , or mute the thread <https://protect2.fireeye.com/url?k=2c338d05-70e7870c-2c33cd9e-86740465fc08-408562ce99f989ed&q=1&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GA2EBLIUOYJMNCO2QDPV3FQ7ANCNFSM4HNNUATQ> .

[iampeteandrews]

ok - so my initial pipelines i put up were a bit confusing. They were indeed on the same machine (135.112.62.140) ... i just had the IP and localhost mixed into the same sender pipeline.

but again, this strange behavior is happening on pipes between 2 different machines as well.
That's what i was doing when i ran wireshark to see what was coming back to the sender in the RTCP messages.

this is the setup on the 2 different 18.04 machines: (sender = .140 / receiver = .159)
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=$SENDER_IP sync=false async=false

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=$RECEIVER_IP port=5000 rtpbin.send_rtcp_src_0 ! udpsink host=$RECEIVER_IP port=5001 udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0

[IngJohEricsson]

Hi OK, thanks for the clarification. Somehow I don’t manage to replicate the problem. I did test with a camera and not a video file however but I don’t believe that this should make any difference. I will try some more and see if I can trigger this problem. /Ingemar From: Pete Andrews <[email protected]> Sent: den 20 maj 2019 14:36 To: EricssonResearch/scream <[email protected]> Cc: Ingemar Johansson S <[email protected]>; Comment <[email protected]> Subject: Re: [EricssonResearch/scream] gscreamrx / RTCP feedback problem ? (#16) ok - so my initial pipelines i put up were a bit confusing. They were indeed on the same machine (135.112.62.140) ... i just had the IP and localhost mixed into the same sender pipeline. but again, this strange behavior is happening on pipes between 2 different machines as well. That's what i was doing when i ran wireshark to see what was coming back to the sender in the RTCP messages. this is the setup on the 2 different 18.04 machines: (sender = .140 / receiver = .159) 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=$SENDER_IP sync=false async=false 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=$RECEIVER_IP port=5000 rtpbin.send_rtcp_src_0 ! udpsink host=$RECEIVER_IP port=5001 udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/url?k=af36f1b3-f3e2f7de-af36b128-867011091b6c-7cf6fa391adab8d4&q=1&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Fissues%2F16%3Femail_source%3Dnotifications%26email_token%3DACRZ2GAKYIMCMQRJQOXROTLPWKLJPA5CNFSM4HNNUAT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVYVXFY%23issuecomment-493968279> , or mute the thread <https://protect2.fireeye.com/url?k=9672b374-caa6b519-9672f3ef-867011091b6c-00f9126dbb63b38f&q=1&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GDZOAMUFXEGQXHQTLTPWKLJPANCNFSM4HNNUATQ> .

[iampeteandrews]

Is the Generic RTP Feedback message type (FMT) Unknown an issue?
would there be any network config problems perhaps? anything in that area to check for?

[IngJohEricsson]

Hi It may be possible that it is a problem. The code for the addition of the feedback packet starts at <https://github.com/EricssonResearch/scream/blob/master/code/gscream/gst-gscreamrx/gst-plugin/src/gstgscreamrx.cpp#L377> https://github.com/EricssonResearch/scream/blob/master/code/gscream/gst-gscreamrx/gst-plugin/src/gstgscreamrx.cpp#L377 Perhaps I have missed to set the FMT field properly ? /Ingemar From: Pete Andrews <[email protected]> Sent: den 21 maj 2019 16:07 To: EricssonResearch/scream <[email protected]> Cc: Ingemar Johansson S <[email protected]>; Comment <[email protected]> Subject: Re: [EricssonResearch/scream] gscreamrx / RTCP feedback problem ? (#16) Is the Generic RTP Feedback message type (FMT) Unknown an issue? would there be any network config problems perhaps? anything in that area to check for? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/url?k=e235c358-bee1c6e7-e23583c3-868f633dbf25-339cd3256d404d69&q=1&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Fissues%2F16%3Femail_source%3Dnotifications%26email_token%3DACRZ2GHMZN64R2HZ6F5HVK3PWP6XRA5CNFSM4HNNUAT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV4AWRQ%23issuecomment-494406470> , or mute the thread <https://protect2.fireeye.com/url?k=0e829157-525694e8-0e82d1cc-868f633dbf25-05a05371e0c4587f&q=1&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GDSMPZP3LDMRHD3BFTPWP6XRANCNFSM4HNNUATQ> .

[iampeteandrews]

Hello Ingemar -
any further thoughts on this?
is it helpful for you to see my pcap files for this issue i'm seeing?

-pete

[IngJohEricsson]

Hi
Unfortunately I have been stuck with other issues.. and it is not guaranteed that I will have time to look at this in June. Please share the pcap files anyway, all of a sudden I may get a few hours to spare.
/Ingemar