In the Playout instance configuration tool on the Playback tab there is a special field for setting the Queue size. The Queue size defines the maximum video buffer size on the playout server. The default and recommended value for all formats is 150.

This buffer (queue) is between the decoder and SDI output and it’s set in video frames. Normally the decoder is able to read and decode frames faster than real-time, and it puts the decoded frame into this buffer in advance, until the buffer is full. So, if for some reason a single frame (or several frames) are being read longer, the frames from the buffer will be sent to the output, until the buffer is empty. Only if the buffer is empty and we still have no decoded frame – there will be a drop on the output.

 It means, the bigger the buffer is, the longer reading/decode delay it can process without drop. But it consumes extra memory, as the system will need to allocate the memory for all the frames in the buffer. E.g. the buffer 150 frames long in 60 fps mode means 2,5 seconds. So, if the frame reading and decoding takes less than 2,5 seconds, the buffer can correct it without any drops on the output. In case the frame reading or decoding is longer, it cannot send the output frames anymore and it will drop output frames, that results in distorted sound and jittering video.

Practically in every Air log you may encounter messages like “Total frame read time is too long. Takes 104 ms”. Those messages are actually not errors but rather information messages (notifications) that the time to read a certain frame has taken more than the real time. The average frame read speed should be faster than the real-time. The usual frame read time for PAL format is about 40 ms.

Such messages usually appear at the start of the file reading or while reading the next chunk. If such messages are not very frequent, not for each frame - such fluctuations of media files reading are easily smoothed and compensated by buffers (queue) and do not affect Broadcast output.

Here is the sample line in the log:

29.09.2016 08:39:48.282 (616) PERF: Read 71 ms (R,P,D): V(P,53,0) ANC(D,0,0) A0(P,18,0)

And this is the explanation of the messages:

PERF: Read XX ms - time spent for performing reading in milliseconds

(R,P,D) - (READING, PROXY, DIRECTLY). Reading from proxy or reading file directly from its location.

V - video; ANC - vanc data; A0 - audio

For example: 

PERF: Read 77 ms (R,P,D): V(P,48,0) ANC(D,0,0) A0(P,29,0) – reading is performed in 77 ms.

V(P,48,0) – V (reading video from Proxy, spent 48 ms, 0 - time spent on reading directly)

ANC(D,0,0) – ANC (reading vanc data). There is no vanc data due to 0 value.

A0(P,29,0) – A (reading audio from Proxy, spent 29 ms, 0 - time spent on reading directly)