Our forum software is confusing. It makes the link look like an image because it has Google Docs integration. So the above is actually a link to the Google Drive folder. Below is the same thing written as code so that our forum software doesn't show it looking like an image:

https://drive.google.com/file/d/1pEb0_OCA3eYZAncolTHy8hSlQiK2S0KX/view

Here is the link with our forum software allowed to show it as embedded content:

    Brandon Thanks. I downloaded and installed the wheel. When cd examples to run the 01_ example, it reported:
    Unable to init server: Could not connect: Connection refused
    Traceback (most recent call last):
    File "01_rgb_preview.py", line 34, in <module>
    cv2.imshow("bgr", inRgb.getCvFrame())
    cv2.error: OpenCV(4.5.1) /tmp/pip-wheel-qd18ncao/opencv-python/opencv/modules/highgui/src/window_gtk.cpp:624: error: (-2:Unspecified error) Can't initialize GTK backend in function 'cvInitSystem'

    I then did a 'python3 -m pip install opencv-python --force-reinstall', successfully, but still had the same error when running the example.

        GergelySzabolcs Brandon
        My bad. I should have remembered opencv window doesn't know where to imshow in ssh session. The X forwading still has the same problem. Are there more steps to set it properly? It works in vnc terminal now.

            I always forget how to properly get XForwarding working. I ended up getting a mini-HDMI to HDMI adapter cable (here) and then a micro USB adapter (here) which I hooked to a USB hub (here) for doing all the initial testing on the Pi. That way I could get everything working first before fighting XForwarding

              Last night I tested multiple examples on Pi Zero, all working using the prebuilt wheel. Bravos GergelySzabolcs Brandon ! I'm still curious how you guys got around the problem prebuild the wheel for RPi OS, while my pi zero refused to.

              For any newbies exploring practical use, Pi Zero is too slow for handling video streams/files, with or without depthai. May still good for still pictures if Oak-1 or Oak-D handle all the detection and trigger pi zero to store the critical images. Any tips or comments would be great.

                    Thanks for circling back Jason .

                    And for taking still pictures based on seeing a given class, check out this example:
                    https://github.com/luxonis/depthai-experiments/tree/master/gen2-class-saver-jpeg

                    Question on the Pi Zero slowness: Is it fast enough to just save the video that DepthAI outputs from the DepthAI video encoder? I was assuming (and I think I'm quoted that it is) but I'm not sure if I actually tested it (can't recall). The reason I was thinking so is that 1920x1080 on not-high settings is only 3mbps. And I figured an ARMv6 had to be able to ingest that and save to uSD card without a problem. I wouldn't expect it to be able to play it, but at least to be able to save it.

                    Thoughts?

                    Thanks,
                    Brandon

                        Brandon I initially thought so. But based on how fast pi zero is reading video frames, I have doubt now. I'll surely test out this weekend and let you know.

                          Hi @Jason ,

                          So we did some testing internally and the reason that DepthAI encoding isn't working on Pi Zero is because of this bug:

                          https://github.com/luxonis/depthai/issues/354

                          @GergelySzabolcs has done 1080p recording with DepthAI on Pi Zero.

                          And actually, if you want to get this going now, our Gen1 API is successfully doing this. So you could actually use it here:
                          https://github.com/luxonis/depthai

                          And the instructions for recording the video are here:
                          https://docs.luxonis.com/en/gen1_master/pages/faq/#how-do-i-record-or-encode-video-with-depthai

                          (These are the Gen1 instructions.)

                          So this actually should be able to record full HD to the Pi Zero. You just won't be able to play it back on the Pi Zero. But you can SCP it off and play it elsewhere for example. And you should be able to record as long as the microSD can handle - so you should be able to record hours of footage if you have a decent-sized SD card on the Pi Zero.

                          We're in the midst of debugging why we have this issue with Pi in general in Gen2. So far we don't have great leads.

                          I'll try to remember to post here once this is resolved in Gen2 API, but for now can use Gen1 for this and it should work fine. And we'll definitely update the linked Github issue above.

                          Thoughts?

                          Thanks,
                          Brandon

                            Brandon That's great!

                            Would switching back and forward between Gen1 and Gen2 cause any problems? I experienced "connection" problems when switching b&f between Gen1 and Gen2 using mac and oak-D, even though PyCharm should have kept each in its venv. One layer deeper, is firmware on oak-D or oak-1 gets refreshed each time we switch between Gen1 Gen2?

                              Hi @Jason ,

                              So we have found that one needs to unplug USB and power from OAK-D/DepthAI between switching between Gen1 and Gen2.

                              The firmware is reflashed each time. But apparently, somehow, there's some state information that persists that can cause issues some times. But not all the times. We haven't dug into it much as we are planning on leaving Gen1 completely once all Gen2 features are fully stable (the video encoder issue on the Pi is the first we saw of instability in Gen2, but we expect it's actually a problem that impacts all of Gen2, which just occurs faster with the video encoder).