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

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796842

Olivier Crête <olivier.crete at ocrete.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #373210|none                        |needs-work
             status|                            |

--- Comment #44 from Olivier Crête <olivier.crete at ocrete.ca> ---
Review of attachment 373210:
 --> (https://bugzilla.gnome.org/review?bug=796842&attachment=373210)

As a general note on the concept, I don't understand how that would block if
you have a pipeline like "videotestsrc ! x264enc ! mpegtsmux ! srtserversink
sync=0".. won't it end up using all of the available RAM ? I think the easiest
way to prevent that is to block until at least one of the client queues is
empty, to make sure that we never send faster than the fastest receiver. But
also set a max queue length so we limit the memory usage in any case (and a
property to decide to drop or block).

::: ext/srt/gstsrtserversink.c
@@ +52,3 @@
+  GstTask *event_task;
+  GRecMutex event_lock;
+  GRecMutex client_lock;

Do you really need a recursive mutex? They're hard to get wrong and error
prone!

@@ +163,3 @@
+  priv->clients = g_list_append (priv->clients, client);
+  g_hash_table_insert (priv->client_hash,
+      &client->sock, srt_client_ref (client));

May not need the linked list if we also have the hash table and iterators

@@ +164,3 @@
+  g_hash_table_insert (priv->client_hash,
+      &client->sock, srt_client_ref (client));
+  priv->num_clients++;

That counter is also duplicative with g_hash_table_size()

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.