[Bug 796842] srt: Refactor plugin to support non-blocking SRT APIs

[GStreamer (GNOME Bugzilla)]

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.