Momindum live monitoring - dashboard
All times in this interface are UTC
Momindum live monitoring interface is splited into 4 different areas.
Pink area : “Visual monitoring“
1. Top of the page : basic information + overall status
As basic information, we are giving you the name of the live, and the start and end date (UTC time).
The overall status is the big line that could have 3 colors :
Green : everything is working fine. Our AWS encoder is up and running, and receiving video and audio data
Orange : there is at least 1 active alert (please see below : “Botomm : active alerts”). Most of the time, that means our AWS encoder is up and running but we are not receiving data (network issue on your side, bad stream url/key etc.)
Red : this should never happend. That means our AWS encoder is not running and we are not receiving anything. Maybe you didn’t launch your test from Momindum Cloud ?
2. Players
On the left, it is the direct stream from AWS encoder. This player is showing what we are receiving, on encoding the RTMP received to single quality HLS (no multiple bitrate, no CDN, no P2P etc.)
On the right, it is the Live preview. This player is showing what your viewers are currently seeing (with multiple bitrates, CDN, etc.).
Thanks to them you can check if there is an issue between what we receive and what we deliver. Please note that the left player will be more in “realtime” that the right one, as it hasn’t any network optimization.
3. Active alerts
These are the raw alerts from AWS encoder. If we are not receiving anything, we will have 4 alerts (“Waiting for RTMP input”, “Searching for RTMP Push stream”, “Video not detected”, “Audio not detected”).
4. Misc
You will have 2 other information : the current audience (the audience will be counted at the begning of the live, not during the tests) and a link to this documentation.
Blue area : “Interaction interfaces“
Here you are having the shortcut to the 3 private interaction interfaces (moderator, speaker and projection) as well as the full question wall, as seen by your viewers.
Yellow area : “Graphs“
Every graph is having 1 value per minute. Almost all the graphs are a mean over a minute (except for FillMsec and DroppedFrames, please see the description below). So, if we have received 1.800 frame between 14:15 and 14:16, we will take the value 30 at 14:15. That’s why, even if you are sending a constant frame rate, you can have small variations.
| Description | Good display | Bad display |
|---|---|---|---|
Input Video Frame Rate | Framerate we are receiving from your encoder |  We can see we are receiving around 30 FPS | If we are not receiving frames anymore, then this value will drop to 0. If you are still pushing something but the value is not the one we are receiving, there may be an issue too (on your network, or on your encoder). If you have a value at 0 but Network In has a value greater than 0, the issue may be related to the fact you’re not using the right stream name. You should have, on the errors, something like : Setting alert [xxx] [xxx] [xxx] [Searching for RTMP Push stream [xxx], which does not exist at this time] |
FillMsec | How much time we did not receive video, and we had to fill the stream with a black error frame. The fill will be activated only | We didn’t had to fill your video stream with the error message, everything is right on this side | The graph will give the number of consecutive milli secondes for when we began to push our black error frames. If you see a constant increase, that means we are no more receiving video. If you see small peaks, that mean we are not receiving all of your frames, so please check your encoder and network. |
Active Alerts | How much “Active alerts” (in the pink area) we had at any time. Any value grater than 0 means there is an issue. The alert history can be found on “level 2 support logs” (green area). | We began without stream, so all the alerts were there. Then, we began to push around 14:15 and the alert stay at 0 since then. | Any value grater than 0 means there is an issue and so please check “Active alerts”. |
Network In | The stream bandwidth (in Mbps) we are receiving from your encoder. | We are pushing at CBR (Constant BitRate) at around 3.5 Mbps, everything is ok. If you are pushing using VBR (Variable BitRate) the curve will not be flat, and you can just check it never reaches 0. | Here we can see a sudent drop in the received bandwidth, even if we were receiving CBR before. Please check your encoder messages, it should explain you why it is not sending stream as expected. |
Network Out | The stream Mbps we are sending to the CDN. The value is the sum of the bitrate of all the qualities. | The network out should be almost flat.
| A sudent drop in the network out should means we are generating a static black error frame (that is taking less bandwidth to be encoded). |
Dropped Frames | How much frames we have dropped since the beginning of your stream. This should always stay at 0. | We didn’t drop any frame here, everything is OK. | In some rare case, your encoder may send the same frames more than once, causing them to be dropped. It could be linked to micro cut on your network, forcing your encoder to send them twice. If this value is stable, that means there wasn’t new micro cut. It could be a severe issue if the value increase. |
Svq Time | The SVQ (Speed Versus Quality) Time metric defines the percentage of time averaged over the last 10 seconds that the encoder has had to reduce quality optimizations to speed up the encode in order to keep the Live encoder running in real time. | A value of zero indicates that the encoder is keeping up in real time without requiring any reductions to quality optimizations. | A non-zero percentage indicates the system may be overloaded. This sould never happen as you can’t choose more than 5 different qualities generated for a single stream. |
Primary Active | Number of primary active stream. Should alway be 1. |
|
|
Green area : “Advanced logs“
These logs will be used by Momindum to understand what is happening at the encoder level.