Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better frame queue overrun handling #16

Open
rezonant opened this issue Jun 19, 2019 · 0 comments
Open

Better frame queue overrun handling #16

rezonant opened this issue Jun 19, 2019 · 0 comments

Comments

@rezonant
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant