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.

Sign up for GitHub

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

Jump to bottom

MJPEG decode failed: -1 #27

Closed
omartin2010 opened this issue Apr 18, 2020 · 9 comments
Closed

MJPEG decode failed: -1 #27

omartin2010 opened this issue Apr 18, 2020 · 9 comments

Comments

@omartin2010
Copy link
Contributor

Did you guys ever see this :

[2020-04-18 14:47:40.098] [error] [t=32] ../../src/color/uvc_camerareader.cpp (1300): DecodeMJPEGtoBGRA32(). MJPEG decode failed: -1
[2020-04-18 14:47:40.110] [error] [t=32] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_depth" was popped in a disabled state.
[2020-04-18 14:47:40.124] [error] [t=29] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_color" was popped in a disabled state.
[2020-04-18 14:47:40.170] [error] [t=29] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_color" was popped in a disabled state.
[2020-04-18 14:47:40.184] [error] [t=34] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_capture" was popped in a disabled state.
[2020-04-18 14:47:40.184] [error] [t=34] ../../src/sdk/k4a.c (269): capturesync_get_capture(device->capturesync, capture_handle, timeout_in_ms) returned failure in k4a_device_get_capture()
[2020-04-18 14:47:40.246] [error] [t=29] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_color" was popped in a disabled state.
[2020-04-18 14:47:40.303] [error] [t=29] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_color" was popped in a disabled state.
[2020-04-18 14:47:40.370] [error] [t=29] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_color" was popped in a disabled state.
[2020-04-18 14:47:40.374] [error] [t=34] ../../src/queue/queue.c (112): queue_pop(). Queue "Queue_capture" was popped in a disabled state.
[2020-04-18 14:47:40.374] [error] [t=34] ../../src/sdk/k4a.c (269): capturesync_get_capture(device->capturesync, capture_handle, timeout_in_ms) returned failure in k4a_device_get_capture()

and it goes on forever? I just reset the device and it works after. It doesn't happen too often but sometimes it does and I find it interesting/annoying. :)
@lpasselin
Copy link
Collaborator

I have never seen this. @etiennedub ?

@omartin2010
Copy link
Contributor Author

omartin2010 commented Apr 23, 2020 •
edited
Loading

It's happening under conditions that I noticed is around low amount of RAM. In fact, I'm doing video analytics and running the k4adevice.get_capture(...) function in a continuous loop. How are we freeing RAM that is required to be freed by the C SDK? I'm no C expert nor python to C bindings, so... how does one free this manually? Or ensure it's not dangling? My process is taking huge amounts of memory and while I suspect I may be doing something not efficient in Python myself, I'm curious about this part...

       if (K4A_RESULT_SUCCEEDED == res) {
            res = k4a_image_to_numpy(depth_image_transformed, &np_depth_image);
        }

        if (K4A_RESULT_SUCCEEDED == res) {
            return PyArray_Return(np_depth_image);
        }
        else {
            free(depth_image_transformed);
            return Py_BuildValue("");
        }

In particular, in this snippet... shouldn't the free(depth_image_transformed) work when there is a success too?... I guess I'm thinking async here, because once it returned... perhaps this is all handled by python's garbage collector?

@lpasselin
Copy link
Collaborator

lpasselin commented Apr 23, 2020 •
edited
Loading

The free is not used on success because this is handled in the capsule_cleanup function, which is called when your Python code garbage collects the images. So you have to make sure you aren't storing images in a list forever or similar. We do it this way because we must call k4a_release everytime we stop using a capture frame (this does the freeing internally, if the reference count to the capture is zero). By having the garbage collector call the k4a_free function we make sure users don't need to bother with releasing the captures themselves.

Can you confirm the transform function is problematic? If you do not transform, do you still have the problem after a while?

I have doubts about the buffer to k4a function. Maybe it does copy the buffer content and we need to free it. (edit: it should be fine. It reuses the buffer directly. There is an option for a callback to release. We do not need this if our buffer comes from python.)

My Kinect is at the University lab and I can't access for a while to test myself. But I am happy to help debug the problem. This is probably the most complicated part of our wrapper.

Could you create a minimal example file to reproduce the bug?

@omartin2010
Copy link
Contributor Author

I guess I'm luckier, I have the unit at home... :)
Got it, makes sense. And I'm not keeping images indefinitely... after some investigation, it seems to be an issue with K4A, not about freeing buffers.

See here : microsoft/Azure-Kinect-Sensor-SDK#1187

I will try to investigate the work to not using BGRA as a format in the capture, or at least what it means in this python package. I'm not super familiar with C/C++ so it might be a bit challenging for me but I can take a stab if I can't mitigate the issue.

@lpasselin
Copy link
Collaborator

microsoft/Azure-Kinect-Sensor-SDK#1187 is closed, is there still an issue with pyk4a?

In the future it would be nice to support MJPEG

@omartin2010
Copy link
Contributor Author

There is a patch that is addressing the issue but using my container, I have another depth sensor issue when I use the new .so file that fixes the issue. In fact, the issue is that it's now throwing a warning versus an error when the underlying decoder, libjpeg-turbo returns certain errors that can be ignored. It should not matter to the rest but somehow when I change the so file in my container, I see another error that I'm not sure what to do about. I'll wait that the package is pushed out to the repos to retry it using the python wrapper. For now it works because I keep the CPU/memory usage to a lower amount by restricting other docker containers from competing too much on resources.

@lpasselin
Copy link
Collaborator

Reopen if pyk4a is the problem!

@omartin2010
Copy link
Contributor Author

omartin2010 commented Jun 11, 2020 via email

@lpasselin
Copy link
Collaborator

Hey if MJPEG decoding is still a problem, you can try directly getting compressed MJPEG color images now: #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lpasselin @omartin2010