Feature Request: LLHLS Session Timeout

[bchah]

In #1304 we discussed the issue where HTTP/2.0 connections do not get closed until the browser window is closed, even when the page is reloaded. The result is that OME will hold many connections even if it is only using one of them, and the viewer statistics will be inaccurate.

I know we cannot change HTTP/2.0, but maybe it's possible to solve the problem with another approach...

Would it be possible to add a "Timeout" configuration value to the LLHLS publisher? The purpose of the timeout would be to observe if no data has flowed to that session in the last X seconds, then the session would be destroyed. This would in theory keep the viewer count accurate. I hope you can consider adding this because the inaccurate viewer count is a security concern for users of LLHLS 🥹

[getroot]

I think my explanation was misrepresented. OvenMediaEngine will of course close the connection after 30 seconds if no data is flowing on the TCP connection. It is not true that you said that OME holds many connections. The fact that there are multiple sessions is just a statistical number, and there is only one actual TCP connection.

In detail, it is as follows.

As shown in the figure, the HTTP/2 browser uses only one connection in the entire PC when connecting to one server.

In other words, even if you run 3 browsers on your PC and play 3 videos with OvenPlayer, only one TCP connection is connected to OME.

This makes it difficult for OvenMediaEngine to calculate "concurrent viewers".

There may be several strategies.

1. Calculate concurrent viewers only with the number of TCP connections

   This is displayed as 1 simultaneous viewer even when playing n streams on one PC. Early on, we had this strategy.

2. The master playlist (default: llhls.m3u8) is taken only once when the player starts, so 1 concurrent view count is added each time the master playlist is downloaded > This has the following weaknesses.

Let's assume the following.
(1) Launch 3 players on one PC and start playback
(2) Quit 2 players and continue playing with only 1

Can OvenMediaEngine recognize that two players are closed at this time?

This is very difficult. Because it is related to the HLS protocol. There is no state called "end" in the HLS protocol. Because the client just downloads the chunklist and segments. Two players are closed, but one player is still downloading chunks. So OvenMediaEngine doesn't know that both players are closed.

So I put an algorithm that determines that all three sessions related to it are closed when the connection is disconnected or when no data flows through the connection.

Please let me know if you have any better algorithm ideas for calculating statistics.

[getroot]

I asked a step faster than you. ;-)
#1313 (reply in thread)

[bchah]

Replying to your edited comment: if my latest suggestion is no good, I think your updated suggestion is fantastic. 10 players of the same stream on the same screen is still one viewer in my opinion - and the throughout can still be measured for all 10 streams anyways so no info is lost. Interested to see what you think!

[getroot]

Your latest proposal (#1313 (reply in thread)) and my last proposal (#1313 (reply in thread)) essentially use the same algorithm.

I'm not sure which approach users would prefer between the current method and the one you suggested. You believe that calculating multiple players playing the same stream on one PC as one is a better approach? I fully respect your opinion. Please consider discussing this with your customers and let me know.

As I talk with you, I feel like there won't be many strange viewers who would watch the same stream on ten different players from one PC, so there may not be a need to consider them.

However, in the rare case that such peculiar viewers are very abundant, there could be disputes during cost settlement. The throughput would be very high, but the number of viewers might be significantly lower, potentially leading to disagreements when calculating expenses.

[bchah]

Of course the King of OME is faster than me 😂

You have shared so much important insight and information, I feel educated to rephrase my question now:

Would you consider adding a "uniqueViewerCount" metric to the Stream Stats API which uses the new calculation method we have discussed? 😁 Then the original method can remain too.

Thank you for all of your help and insight here @getroot 👑

[getroot]

If Meta is added, WebRTC or WHIP must also be considered, so let's think about the number of various cases. 😃
First of all, I am positive about applying a new viewership calculation method to LLHLS.