EricssonResearch / scream

SCReAM - Mobile optimised congestion control algorithm
BSD 2-Clause "Simplified" License
174 stars 53 forks source link

gscreamrx / RTCP feedback problem ? #16

Open iampeteandrews opened 5 years ago

iampeteandrews commented 5 years ago

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

IngJohEricsson commented 5 years ago

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 notifications@github.com Sent: den 16 maj 2019 17:19 To: EricssonResearch/scream scream@noreply.github.com Cc: Subscribed subscribed@noreply.github.com 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: 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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com Sent: den 16 maj 2019 19:21 To: EricssonResearch/scream scream@noreply.github.com Cc: Ingemar Johansson S ingemar.s.johansson@ericsson.com; Comment comment@noreply.github.com 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 commented 5 years ago

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

-pete

iampeteandrews commented 5 years ago

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 commented 5 years ago

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 notifications@github.com Sent: den 17 maj 2019 17:30 To: EricssonResearch/scream scream@noreply.github.com Cc: Ingemar Johansson S ingemar.s.johansson@ericsson.com; Comment comment@noreply.github.com 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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com Sent: den 20 maj 2019 14:36 To: EricssonResearch/scream scream@noreply.github.com Cc: Ingemar Johansson S ingemar.s.johansson@ericsson.com; Comment comment@noreply.github.com 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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com Sent: den 21 maj 2019 16:07 To: EricssonResearch/scream scream@noreply.github.com Cc: Ingemar Johansson S ingemar.s.johansson@ericsson.com; Comment comment@noreply.github.com 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 commented 5 years ago

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 commented 5 years ago

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