Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gscreamrx / RTCP feedback problem ? #16

Open
iampeteandrews opened this issue May 16, 2019 · 12 comments
Open

gscreamrx / RTCP feedback problem ? #16

iampeteandrews opened this issue May 16, 2019 · 12 comments

Comments

@iampeteandrews
Copy link

iampeteandrews commented May 16, 2019

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
Copy link
Contributor

IngJohEricsson commented May 16, 2019 via email

@iampeteandrews
Copy link
Author

iampeteandrews commented May 16, 2019

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
Copy link
Contributor

IngJohEricsson commented May 16, 2019 via email

@iampeteandrews
Copy link
Author

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

-pete

@iampeteandrews
Copy link
Author

iampeteandrews commented May 17, 2019

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
Copy link
Contributor

IngJohEricsson commented May 19, 2019 via email

@iampeteandrews
Copy link
Author

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
Copy link
Contributor

IngJohEricsson commented May 21, 2019 via email

@iampeteandrews
Copy link
Author

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
Copy link
Contributor

IngJohEricsson commented May 21, 2019 via email

@iampeteandrews
Copy link
Author

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants