[Bug 796842] srt: Refactor plugin to support non-blocking SRT APIs
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun Aug 12 12:11:44 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=796842
--- Comment #57 from Seungha Yang <pudding8757 at gmail.com> ---
(In reply to Olivier CrĂȘte from comment #56)
> I asked on SRT's slack what the expected behaviour is.
Hum... I think libsrt is unstable for now, especially congestion control seems
to unreliable.
<Observation 1>
The libsrt's default sender queue size is 8192 * (1500 - 28) bytes and I guess
my environment cannot hit the max bound of the queue size with following
command.
"videotestsrc ! x264enc key-int-max=30 ! mpegtsmux alignmeng=7 ! srtserversink
uri=srt://localhost:9999 sync=false"
Note that, from Gstreamer point of view, the default queue size is needlessly
too large in my opinion anyway.
So, I tested using movie file but it did not show difference (cannot hit the
bound).
<Observation 2>
To hit the bound, I tested reduced queue size using SRTO_SNDBUF srt socket
option, then I could hit the bound. The problem was,
[Case 1. non-blocking clientsink - non-blocking serversrc]
clientsink will stuck in srt_epoll_wait() after hit the bound several times.
That means there is no SRT_EPOLL_OUT event.
[Case 2. blocking clientsink - non-blocking serversrc]
locked by srt_sendmsg2() and no return ...
Both cases show "No room to store incoming packet" message at receiver side.
I guess https://github.com/Haivision/srt/issues/409 issue may be related this
behavior, but not sure.
<Observation 3>
To avoid stuck, I tried to control queued buffer manually. For example, waiting
call srt_sendmsg2() until half of queue size are available. But nothing
changed. libsrt was stuck in srt_sendmsg2() or srt_epoll_wait().
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list