MJPEG decode failed: -1 about pyk4a

[omartin2010]

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]

I have never seen this. @etiennedub ?

[omartin2010]

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]

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?

[lpasselin]

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]

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]

Reopen if pyk4a is the problem!

[omartin2010]

will do - with the new version of the driver it should be fixed. I haven’t taken the time lately to test this specific thing but will report back eventually if it’s broken. Thanks! Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Louis-Philippe Asselin <[email protected]> Sent: Wednesday, June 10, 2020 9:57:37 PM To: etiennedub/pyk4a <[email protected]> Cc: Olivier Martin <[email protected]>; Author <[email protected]> Subject: Re: [etiennedub/pyk4a] MJPEG decode failed: -1 (#27) Reopen if pyk4a is the problem! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fetiennedub%2Fpyk4a%2Fissues%2F27%23issuecomment-642358843&data=02%7C01%7C%7Cc8c84364bf67451b0cac08d80daad178%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637274374586680923&sdata=GOyHZUzIXgDMLuHCpeFQ9%2FiDKYS1mM2hLuR2Kw6r98A%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACWYKXWBUDSO7ILS4S2PC6LRWA2ZDANCNFSM4MLOZHDQ&data=02%7C01%7C%7Cc8c84364bf67451b0cac08d80daad178%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637274374586680923&sdata=pLyEQI7pR%2FX4%2B3zPZVfgRsZ9Z3vsvG0FxusHuZZ74EM%3D&reserved=0>.

[lpasselin]

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