onFps calls even if no network connectivity

[muhanov]

During RTMP stream I tried to switch off both WiFi and Mobile data.
Indifferently, onFps() callback is constantly calling every 1 sec. Actual FPS is lower a bit than required but still available.
Do we have a way to track actual streaming FPS based off actual network state?

[pedroSG94]

Hello,

You can try to discount the fps dropped using this:

val realFps = fps - genericStream.getStreamClient().getDroppedVideoFrames()
//Then you can reset the value for the next iteration:
genericStream.getStreamClient().resetDroppedVideoFrames()

[muhanov]

@pedroSG94 Thank you for the idea. However, I observe that dropped frames both for audio and video are 0-es even the is no actual data connection.
Just in case I use 2.6.6 version of the lib.
Might it be the cache size?
I did 5 different experiments where the is no data connectivity for 1,2,3,4,5 mins. In all of these cases dropped frames are 0-es.
Looks redicilous for me.

I realized (debugged) that disconnect of the network will stop sending frames, and won't count the dropped frames.

[pedroSG94]

Hello,

In this library dropped frames only happens when your connection is too slow and for that reason the cache is filled, then the fps drop begins. Basically, you have a bottleneck between what is produced and what is sent.

If you lose the connection, the library detects it and disconnects the stream so the cache is not filled. You can check the packets in cache but it is a combination of video/audio
As an alternative, you have a count of video or audio packets sent to the server, you can count it on the callback and reset the value.

[muhanov]

Thank you, @pedroSG94.
I did 2 different experiments on LTE network.

1. sending 720p RTMP video - cache size is 1 maximum. Typically, 0.
2. sending 1080p RTMP video - cache size is catastrophically growing till the end of test. it is 2826 media frames cached.
   Looks like for such cache it'd be better to drop frames rather than collect them.
   What do you think?
   Attached log files. They actually JSONL.
   StreamSourceKpis-720p.json
   StreamSourceKpis-1080p.json

[pedroSG94]

Hello,

This was fixed for the next release here:
76fa8c4

[muhanov]

Thanks, @pedroSG94.
I personally tried to wrap the queue u used PriorityBlockingQueue and apply bounded queue instead to prevent adding extra elements.
It works but your solution works much more easier and elegant.
Looking for the next release :-)

Just in case. videoFramesSent, etc we get from GenericStreamClient are updated in some internal thread but read typically from another thread (in main one or in some coroutine). It leads to the situation when reading thread gets it with no actual updates (value cached in between different threads). Operation isn't atomic (specifically to Long values).
Probably, more convenient way is to add some callback for all of them like u did for bitrate update.

[pedroSG94]

Hello,

I think that convert that values to atomic is a better idea because the callback called each time a packet is sent feels bad (so much calls), one time each second is weird because should calculate it and I still should fix current methods for compatibility reasons.