Viewing Stream Statistics

you can view all the accumulative statistics for a connected input stream in real time it is possible to reset the counters by clicking reset the statistics may differ between the various stream types to view stream statistics on the inputs page of zixi broadcaster, click the desired input stream for which you want to view statistics for the stream’s statistics are displayed on the bottom of the screen field description bitrate (kbps) displays the current bitrate of the input stream last connected displays the date and time in which the stream was connected uptime displays the amount of time the stream has been active reconnections displays the number of reconnection attempts rtt (ms) displays the round trip time (rtt) from the source (in milliseconds) jitter (ms) displays the current jitter, measured in milliseconds congestion displays an estimation of the communication's congestion level – '0' means congestion free, '100' means fully congested latency (ms) displays the stream latency configured on the source feeder total packets displays the total number of packets that have been transmitted packet rate displays the current number of packets per second merged packets displays number of missing packets recovered using content based matching (not 2022 7 mode) late packets displays the packets thrown away on failover group output, because they were stuck for significantly longer than the search window time (typically performance issues) packet loss % displays current percentage of the packets that were dropped on route from the source consecutive drops the number of packets that were dropped in a row when consecutive packets are dropped that could imply burst loss, as opposed to a sustained % of loss that would imply congestion dropped packets displays the total number of packets dropped between the feeder and the broadcaster since the beginning of the stream drop correlation queue overflows displays the number of packets thrown away on failover group entry, because there is no space in the buffer (typically max bitrate too low) stream switches displays the number of times a failover group has switched between different streams (not relevant when streams are identical) smpte 2022 7 mode indicates that the streams in a failover group are being merged based on rtp sequences rtp drops displays the number of missing packets according to rtp sequences rtp restarts displays the number of time that the rtp stream had a discontinuity, due to a large jump in sequence numbers or in timestamps remuxing resets remuxing resets can occur when remuxing to cbr (i e value of ‘remux to bitrate’ field is set) in this case, the value is not high enough to remux the video+audio+other pids data a possible solution is to increase value of the ‘remux to bitrate’ parameter remuxing overflows this indicates that the multiplexer internal queues are full smoothing drops the smoothing feature uses a buffer to time packets according to the stream's clock this is useful when there are bursts in the rate in which the stream arrives the smoothing drops indicator indicates that the stream is too "bursty" recovered packets displays the number of dropped packets that have been recovered since the beginning of the stream not recovered packets displays the number of non recovered packets fec packets displays the number of fec packets transmitted fec recovered displays the number of fec packets recovered arq requests displays the number of requests for retransmission of dropped packets made with arq arq recovered displays the number of dropped packets recovered via arq arq out of credit displays the number of retransmission requests skipped because it hits a limit, which protects from floods of retransmissions when many packets are missing arq duplicates displays the number of duplicate recovery packets received via arq overflows the number of packets lost due to buffer overflow note overflow is usually the result of the max bitrate being too low consecutive not recovered displays the maximal number of consecutive "not recovered packets" in the last measurement period (1 second) this measurement this can help identify long streaks of unrecovered packets, which it is not possible to see by just looking at the global "not recovered" counter