You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the Macadam mainline prints an unclear debug message when it is unable to enqueue a new video frame onto the async frame queue. This can happen when the host application does not pull new frames fast enough (and thus the allotted amount of frame buffers is overrun).
hangover = napi_call_threadsafe_function(tsFn, data, napi_tsfn_nonblocking);
if (hangover != napi_ok) {
printf("DEBUG: Failed to call NAPI threadsafe function on capture.");
}
This debug message could be more helpful. I have drafted the following during my work on this library so that at least the case identified in this issue is clearly communicated:
hangover = napi_call_threadsafe_function(tsFn, data, napi_tsfn_nonblocking);
if (hangover != napi_ok) {
if (hangover == napi_queue_full)
printf("WARNING: Frame overrun: Dropped frame as frame queue is full! status=%d.\n", hangover);
else
printf("DEBUG: Failed to call NAPI threadsafe function on capture, status=%d.\n", hangover);
}
However this is not ideal for many applications- indeed many applications may wish to have an option to control the amount of buffers in use and/or modify Macadam's behavior when the application falls behind when processing frame buffers. For instance, the application may wish to have a smaller queue size and discard frames when it overruns in the interest of keeping latency low. In that case they may wish to receive an event indicating that frames were dropped without otherwise impacting the regular flow of frames.
The text was updated successfully, but these errors were encountered:
Currently the Macadam mainline prints an unclear debug message when it is unable to enqueue a new video frame onto the async frame queue. This can happen when the host application does not pull new frames fast enough (and thus the allotted amount of frame buffers is overrun).
This debug message could be more helpful. I have drafted the following during my work on this library so that at least the case identified in this issue is clearly communicated:
However this is not ideal for many applications- indeed many applications may wish to have an option to control the amount of buffers in use and/or modify Macadam's behavior when the application falls behind when processing frame buffers. For instance, the application may wish to have a smaller queue size and discard frames when it overruns in the interest of keeping latency low. In that case they may wish to receive an event indicating that frames were dropped without otherwise impacting the regular flow of frames.
The text was updated successfully, but these errors were encountered: