GNOME Bugzilla – Bug 796843
srtserversink: Do not post error message during stopping
Last modified: 2018-07-29 16:14:09 UTC
During stopping sink, "Invalid epoll ID" error from libsrt is not an unexpected behavior, since the epoll was released already for interrupting srt_epoll_wait().
Created attachment 373102 [details] [review] srtserversink: Do not post error message during stopping
Review of attachment 373102 [details] [review]: ::: ext/srt/gstsrtserversink.c @@ +206,2 @@ int srt_errno = srt_getlasterror (NULL); Maybe we just want to do: if (g_atomic_int_get (&priv->cancelled)) return FALSE; before the check for the srt_errno value..
(In reply to Olivier Crête from comment #2) > Review of attachment 373102 [details] [review] [review]: > > ::: ext/srt/gstsrtserversink.c > @@ +206,2 @@ > int srt_errno = srt_getlasterror (NULL); > > > Maybe we just want to do: > > if (g_atomic_int_get (&priv->cancelled)) > return FALSE; > > before the check for the srt_errno value.. Thanks. That looks better to me also :)
Review of attachment 373102 [details] [review]: ::: ext/srt/gstsrtserversink.c @@ +219,2 @@ GST_DEBUG_OBJECT (self, "Cancelled waiting for client"); ret = FALSE; What was the exact expected behavior in here? For some reasons, basesink::unlock() && basesink::unlock_stop() can be called and then, this GSource callback function could be returned with "FALSE" (if my understanding is correct, then this callback will not be called again) But there seems no code for re- attaching GSource. Do I missing something?
(In reply to Seungha Yang from comment #4) > Review of attachment 373102 [details] [review] [review]: > > ::: ext/srt/gstsrtserversink.c > @@ +219,2 @@ > GST_DEBUG_OBJECT (self, "Cancelled waiting for client"); > ret = FALSE; > > What was the exact expected behavior in here? > > For some reasons, basesink::unlock() && basesink::unlock_stop() can be > called and > then, this GSource callback function could be returned with "FALSE" > (if my understanding is correct, then this callback will not be called again) > > But there seems no code for re- attaching GSource. Do I missing something? I think the unlock/unlock_stop() shouldn't be used here.. instead it should just stop the thread in the _stop() vfunc like you added. unlock/unlock_stop() are normally for the case where it can block in the _render() vfunc. But here we jut create a new thread where blocking happens.
I updated a patch for fixing this issue on bug #796842. Please drop this ticket.
*** This bug has been marked as a duplicate of bug 796842 ***