How to interpret console logging statistics?

[mikekoetter]

Is there any guide how to best interpret the data in the log outputs?
For example, in the Video decode stats, it seems to suggest something is being dropped or missed:

Video dec stats (cumulative): 208418 total / 208407 disp / 8 drop / 1 corr / 3 miss FEC noerr/OK/NOK: 208295/119/1

However in the following Decklink display line it seems to suggest everything is arriving just fine:

[DeckLink display] 0 frames late, 0 dropped, 0 flushed cumulative
[DeckLink display] 121 frames in 5.04146 seconds = 24.001 FPS

This is just one example (btw this is a comprimato send with RS FEC and nvidia hardware decode to decklink with sync option)
I would love to better understand how to parse this information, but wasn't able to find a breakdown in the documentation... and haven't yet tried to find all the different outputs in the code

Any pointers here would be greatly appreciated

[MartinPulec]

Hi.

Video dec stats (cumulative):

tells statistics from the decoder, so it usually relates to network. But the numbers are so low so it doesn't perhaps matter. It should be rather interpreted when you experiencing errors, so that this can help. I believe that just these fields may not be intuitive:

• drop - usually UltraGrid presents the frame as soon as possible not to increase latency waiting, so this when display is still busy, the frame is dropped not to increase latency
• corr - number of corrupted frames (equals FEC NOK if FEC is on)
• miss - the frames were missing altogether from the network stream - this seem weird but take into account that it may just have been at the beginning of the stream

DeckLink stat doesn't map to the above in any way... actually, in non-scheduled stream (default) it will be always 0.

[mikekoetter]

ok got it - the cumulative is the life of the session. Please forgive me for asking what are probably some naive questions.
Is there a way to reset that cumulative counter through the communication port?

In the cumulative stats for audio is there any way to get the FEC corr data? I don't see that in the current output
Audio dec stats (cumulative): 12649 played / 12652 total audio frames
I guess a followup question would be is there a way to ensure the FEC is working on the decoder?

Previously if we had an audio frame drop it would present its self as an Audio Buffer Over/Under flow. Since decoding with the :sync option, that error has gone away. We do on occasion get an 'empty channel' warning which does appear to be associated with packet loss.

[Audio decompress] 5 empty channel(s) returned!
[DeckLink display] 0 frames late, 0 dropped, 0 
[DeckLink display] 120 frames in 5.00523 
SSRC 0x1486e660: 13425/13440 packets received 
[Audio decoder] Received 18871680/18890400 B (18720 lost), decoded 238000 samples in 5.00 sec.

Does this sample loss get recorded in the cumulative audio frames played / not played?

[MartinPulec]

Is there a way to reset that cumulative counter through the communication port?

no

In the cumulative stats for audio is there any way to get the FEC corr data? I don't see that in the current output Audio dec stats (cumulative): 12649 played / 12652 total audio frames I guess a followup question would be is there a way to ensure the FEC is working on the decoder?

You mean that you'd like to have similar statistics as for the video? For Reed-Solomon or the mult? For which configuration (channel count, bits per sample)? The problem is that the situation for audio is not similar than for video - you can easily lose all packet of the audio frame. So basically the FEC statistics would show that everything is OK although you'd losing frames. I believe that the count of played/total samples played is much more useful.

Does this sample loss get recorded in the cumulative audio frames played / not played?

I believe so. I don't know your setting so it is a bit tricky to tell but in general the counts is after decoding (and eventual error correction) so it should correspond with the loss count.

[alatteri]

FEC noerr/OK/NOK: 208295/119/1

I wondering about the FEC section.
can I assume the following?
noerr- packet received, no loss
OK- packet lost but rebuilt by FEC
NOK- packet lost and un-able to be rebuilt by FEC. considered a bad packet

[MartinPulec]

FEC noerr/OK/NOK: 208295/119/1

I wondering about the FEC section. can I assume the following? noerr- packet received, no loss OK- packet lost but rebuilt by FEC NOK- packet lost and un-able to be rebuilt by FEC. considered a bad packet

Well, the statistics are per video frame, not per individual packets. So that the semantics is (IIRC):

• noerr - all packets of the frame received successfully
• OK - not all packets of the video frame were received but from the rest the all the missing data was reconstructed
• NOK - not all packets of the frame were received and FEC was not able to reconstruct all of the data (although something might have been). Then the frame may be either passed further or dropped (it depends from the context which of these is better).

[alatteri]

Perfect. Thank you for the explanation.