https://github.com/apache/openmeetings/pull/128
Thanks Seb Sebastian Wagner Director Arrakeen Solutions, OM-Hosting.com http://arrakeen-solutions.co.nz/ https://om-hosting.com - Cloud & Server Hosting for HTML5 Video-Conferencing OpenMeetings <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> On Thu, 11 Feb 2021 at 16:25, [email protected] <[email protected]> wrote: > Well then maybe we just add the check for killing the stream only in case > audio-only for now. > > Thanks, > Sebastian > > Sebastian Wagner > Director Arrakeen Solutions, OM-Hosting.com > http://arrakeen-solutions.co.nz/ > https://om-hosting.com - Cloud & Server Hosting for HTML5 > Video-Conferencing OpenMeetings > > <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> > <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> > > > On Thu, 11 Feb 2021 at 16:04, Maxim Solodovnik <[email protected]> > wrote: > >> On Thu, 11 Feb 2021 at 09:02, [email protected] < >> [email protected]> >> wrote: >> >> > Yeah that is what I meant, maybe yo should check n case of flowType == >> > FLOW_STATE.*NOT_FLOWING*: >> > >> > (1) If the client is stream audio+video && the evt.getType == AUDIO => >> Do >> > *NOT* stopBroadcast >> > (2) If the client is stream audio-only && the evt.getType == AUDIO => Do >> > STOP KStream by calling stopBroadcast >> > >> > I think (2) would not be ideal still, cause basically you are killing >> audio >> > streams that potentially are just "quiet" but not dead. But at least we >> are >> > not killing off a video stream because audio is quiet currently. >> > >> > Maybe for (2) we can also increase the timeout which may help a bit. >> > >> >> Timeout is configurable `kurento.flowout.timeout` (5secs by default) >> >> >> > is there no other more reliable event we could use ? >> > >> >> Unfortunately I'm not aware of such :((( >> >> >> > >> > Thanks, >> > Seb >> > >> > Sebastian Wagner >> > Director Arrakeen Solutions, OM-Hosting.com >> > http://arrakeen-solutions.co.nz/ >> > https://om-hosting.com - Cloud & Server Hosting for HTML5 >> > Video-Conferencing OpenMeetings >> > < >> > >> https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url >> > > >> > < >> > >> https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url >> > > >> > >> > >> > On Thu, 11 Feb 2021 at 14:49, Maxim Solodovnik <[email protected]> >> > wrote: >> > >> > > (sorry for multi-posting) >> > > >> > > Can you check if this code will work as expected in audio-only room? >> > > I'm would like to ensure we will not break this code :) >> > > >> > > On Thu, 11 Feb 2021 at 08:43, Maxim Solodovnik <[email protected]> >> > > wrote: >> > > >> > > > BTW there is cancel to cancel stopBroadcast() if flow is restored >> > > > the timeout seems to be insufficient ... :( >> > > > >> > > > On Thu, 11 Feb 2021 at 08:39, Maxim Solodovnik < >> [email protected]> >> > > > wrote: >> > > > >> > > >> >> > > >> >> > > >> On Thu, 11 Feb 2021 at 02:26, [email protected] < >> > > >> [email protected]> wrote: >> > > >> >> > > >>> According to my observations: if stream is NOT_FLOWING it will >> never >> > > flow >> > > >>> again :( >> > > >>> this is why the connection is dropped >> > > >>> >> > > >>> That might be true for MediaType VIDEO but NOT for MediaType >> *AUDIO* >> > > >>> >> > > >>> In the log file (I've added streamIds to the logs) you can see >> > > >>> NOT_FLOWING >> > > >>> but later again you can see FLOWING events. For the *same* >> streamId >> > > >>> >> > > >>> Example 1 >> > > >>> [34mINFO [0;39m 02-10 08:11:38.220 [36mo.a.o.c.r.KStream:160 >> > > >>> [ventExec-e2-t48] [0;39m - Media Flow STATE :: *NOT_FLOWING*, type >> > > >>> MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> *d6c5db69-0d30-4ba6-b863-aa3c297e17ac*, uid >> > > >>> 9ad475f3-e994-4850-97a3-3e3717bf755a >> > > >>> [34mINFO [0;39m 02-10 08:11:47.022 [36mo.a.o.c.r.KStream:160 >> > > >>> [ventExec-e2-t73] [0;39m - Media Flow STATE :: *FLOWING*, type >> > > >>> MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> *d6c5db69-0d30-4ba6-b863-aa3c297e17ac*, uid >> > > >>> 9ad475f3-e994-4850-97a3-3e3717bf755a >> > > >>> >> > > >>> Example 2 >> > > >>> [34mINFO [0;39m 02-10 08:11:52.066 [36mo.a.o.c.r.KStream:160 >> > > >>> [ventExec-e2-t65] [0;39m - Media Flow STATE :: *NOT_FLOWING*, type >> > > >>> MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> *b8e9f1a6-d29f-482c-8faf-4ac9b9939527*, uid >> > > >>> eb6a7aa7-b913-4d51-a34f-ab1ac684f27d >> > > >>> [34mINFO [0;39m 02-10 08:12:03.501 [36mo.a.o.c.r.KStream:160 >> > > >>> [ventExec-e2-t51] [0;39m - Media Flow STATE :: *FLOWING*, type >> > > >>> MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> *b8e9f1a6-d29f-482c-8faf-4ac9b9939527*, uid >> > > >>> eb6a7aa7-b913-4d51-a34f-ab1ac684f27d >> > > >>> >> > > >>> Example 3 >> > > >>> [34mINFO [0;39m 02-10 08:12:16.099 [36mo.a.o.c.r.KStream:160 >> > > >>> [ventExec-e2-t40] [0;39m - Media Flow STATE :: *NOT_FLOWING*, type >> > > >>> MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> *46420fab-fcaa-493f-9283-1b2fbf9f3170*, uid >> > > >>> b996144c-9ab1-43d5-8500-da359446ad13 >> > > >>> [34mINFO [0;39m 02-10 08:12:19.305 [36mo.a.o.c.r.KStream:160 >> > > >>> [ventExec-e2-t40] [0;39m - Media Flow STATE :: *FLOWING*, type >> > > >>> MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> *46420fab-fcaa-493f-9283-1b2fbf9f3170*, uid >> > > >>> b996144c-9ab1-43d5-8500-da359446ad13 >> > > >>> >> > > >>> I have copied the full log of all MediaFlow State events when >> doing >> > the >> > > >>> 140 >> > > >>> users test here: https://pastebin.com/ZEmtZVyH >> > > >>> >> > > >>> => You can find another 20 examples of FLOWING after NOT_FLOWING >> for >> > > type >> > > >>> AUDIO. You can _never_ find it for VIDEO. But type AUDIO can >> indeed >> > > start >> > > >>> flowing again! >> > > >>> >> > > >>> I understand that this might be a challenge to detect stop events >> if >> > we >> > > >>> can't use this one. But just to be clear, I'm talking about type >> > AUDIO. >> > > >>> There must be a way to filter them out to not kill the stream in >> > those >> > > >>> cases. >> > > >>> >> > > >> >> > > >> Great! >> > > >> Thanks for the clarifications! >> > > >> I'll add this check to the master ASAP! >> > > >> >> > > >> >> > > >>> >> > > >>> Thanks >> > > >>> Sebastian >> > > >>> >> > > >>> Sebastian Wagner >> > > >>> Director Arrakeen Solutions, OM-Hosting.com >> > > >>> http://arrakeen-solutions.co.nz/ >> > > >>> https://om-hosting.com - Cloud & Server Hosting for HTML5 >> > > >>> Video-Conferencing OpenMeetings >> > > >>> < >> > > >>> >> > > >> > >> https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url >> > > >>> > >> > > >>> < >> > > >>> >> > > >> > >> https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url >> > > >>> > >> > > >>> >> > > >>> >> > > >>> On Wed, 10 Feb 2021 at 23:53, Maxim Solodovnik < >> [email protected] >> > > >> > > >>> wrote: >> > > >>> >> > > >>> > On Wed, 10 Feb 2021 at 16:22, [email protected] < >> > > >>> [email protected] >> > > >>> > > >> > > >>> > wrote: >> > > >>> > >> > > >>> > > I was able to fix the missing Video Pods issue. And I think it >> > was >> > > a >> > > >>> > > successful test with 140 users. >> > > >>> > > >> > > >>> > > See: >> > > >>> > > >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> > >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+10-02-2021+with+256crypt+and+FLOW_STATE+fix+for+not+terminating+AUDIO >> > > >>> > > >> > > >>> > > Fixes in the branch I was testing: >> > > >>> > > >> > > >>> > > - The previously described fix to reduce the N factor in >> > SCrypt >> > > >>> > > calculation >> > > >>> > > - The previous fix for adding some DB INdex on >> Address.email >> > > >>> column >> > > >>> > > >> > > >>> > > And also in this one: Fix for not calling "stopBroadcast" when >> > > >>> > > MediaFlowState.NOT_FLOWING is of type AUDIO. >> > > >>> > > => I discovered in previous tests that there are almost >> exactly >> > the >> > > >>> > amount >> > > >>> > > of video pods missing compared to the log event: >> > > >>> > > [34mINFO [0;39m 02-10 08:11:38.220 [36mo.a.o.c.r.KStream:160 >> > > >>> > > [ventExec-e2-t48] [0;39m - Media Flow STATE :: NOT_FLOWING, >> type >> > > >>> > > MediaFlowOutStateChange, evt *AUDIO*, sid >> > > >>> > > d6c5db69-0d30-4ba6-b863-aa3c297e17ac, uid >> > > >>> > > 9ad475f3-e994-4850-97a3-3e3717bf755a >> > > >>> > > >> > > >>> > > I think AUDIO can stop flowing! there is no need to kill the >> > stream >> > > >>> in >> > > >>> > this >> > > >>> > > scenario. >> > > >>> > > >> > > >>> > > To test and verify I updated my performance investigating >> branch >> > to >> > > >>> > modify >> > > >>> > > and add && MediaType.VIDEO == evt.getMediaType(): before >> > > >>> > > >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> > >> https://github.com/apache/openmeetings/blob/feature/OPENMEETINGS-2567-investigate-performance-monitoring/openmeetings-core/src/main/java/org/apache/openmeetings/core/remote/KStream.java#L162 >> > > >>> > > >> > > >>> > > And I repeated the 140 user test and it's fine now! (well a >> lot >> > > >>> better!) >> > > >>> > > >> > > >>> > >> > > >>> > This code was added because clients thought everything is OK >> while >> > > >>> other >> > > >>> > people in the room were not seeing/hearing >> > > >>> > And such misunderstanding is much worse than just reloading :( >> > > >>> > I believe the change like this need to be tested extremely >> > carefully >> > > >>> > >> > > >>> > According to my observations: if stream is NOT_FLOWING it will >> > never >> > > >>> flow >> > > >>> > again :( >> > > >>> > this is why the connection is dropped >> > > >>> > >> > > >>> > >> > > >>> > > During this test there were almost 100 "Media Flow STATE :: >> > > >>> NOT_FLOWING, >> > > >>> > > type AUDIO" events BUT as you can see in the screenshots most >> > > video >> > > >>> pods >> > > >>> > > are fine: >> > > >>> > > >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> > >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+10-02-2021+with+256crypt+and+FLOW_STATE+fix+for+not+terminating+AUDIO#OpenMeetings140userstest10022021with256cryptandFLOW_STATEfixfornotterminatingAUDIO-ScreenshotsfromeachroomwithVideoPods >> > > >>> > > >> > > >>> > > There are other issues :) There is a low percentage of video >> pods >> > > >>> hanging >> > > >>> > > (see screenshots on some pods). But previously those pods were >> > > >>> completely >> > > >>> > > missing and the ratio of pods missing was 50-70%!! >> > > >>> > > => So I still call this a success :) Since it's a massive >> > > improvement >> > > >>> > from >> > > >>> > > the results before. >> > > >>> > > >> > > >>> > > I will raise a separated PR for discussing lowering the SCrypt >> > > value >> > > >>> (1) >> > > >>> > > and how to address the issue around MediaState.NOT_FLOWING and >> > type >> > > >>> AUDIO >> > > >>> > > to not close the broadCast in those cases (2). >> > > >>> > > >> > > >>> > > Unfortunate NOT_FLOWING for type AUDIO, I'm not sure but we >> may >> > not >> > > >>> be >> > > >>> > able >> > > >>> > > to use this. I can also remember from the past that gaps in >> Audio >> > > >>> streams >> > > >>> > > can happen in a normal streaming scenario. Cause streaming >> tries >> > to >> > > >>> save >> > > >>> > > bandwidth. So NOT_FLOWING for Audio may actually not mean >> > anything. >> > > >>> > > >> > > >>> > > Thanks, >> > > >>> > > Seb >> > > >>> > > >> > > >>> > > Sebastian Wagner >> > > >>> > > Director Arrakeen Solutions, OM-Hosting.com >> > > >>> > > http://arrakeen-solutions.co.nz/ >> > > >>> > > https://om-hosting.com - Cloud & Server Hosting for HTML5 >> > > >>> > > Video-Conferencing OpenMeetings >> > > >>> > > < >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> > >> https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url >> > > >>> > > > >> > > >>> > > < >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> > >> https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url >> > > >>> > > > >> > > >>> > > >> > > >>> > >> > > >>> > >> > > >>> > -- >> > > >>> > Best regards, >> > > >>> > Maxim >> > > >>> > >> > > >>> >> > > >> >> > > >> >> > > >> -- >> > > >> Best regards, >> > > >> Maxim >> > > >> >> > > > >> > > > >> > > > -- >> > > > Best regards, >> > > > Maxim >> > > > >> > > >> > > >> > > -- >> > > Best regards, >> > > Maxim >> > > >> > >> >> >> -- >> Best regards, >> Maxim >> >
