Improve PoE performance by introducing MJPEG encoding for streams

[VanDavv]

This PR introduces performance improvements by using MJPEG encoding before sending the frames over XLink and then decoding them on the host using OpenCV imdecode method.
Due to the current encoder limitations, not all of the preview streams have the encoding enabled:

• ❌ nn_input (the passthrough output from the nn)
• ✔️ color
• ✔️ left
• ✔️ right
• ✔️ rectified_left
• ✔️ rectified_right
• ❌ depth_raw
• ❌ depth
• ✔️ disparity
• ✔️ disparity_color

One important change that had to be introduced is that now the color stream is taken from ColorCamera video output instead of preview (since only video output can be MJPEG encoded at the moment). Using this output, the preview window is not cropped and scaled to meet the nn input size, being full FOV instead - but we wanted to introduce this feature anyway in #422. Issues reported in that PR will probably affect this PR also, but I think we can merge this PR and address them afterward, just so the demo is usable with PoE devices. CC @Luxonis-Brandon

Performance on a single stream can reach up to 28 FPS over ethernet (tested on -s left)

The more streams we request, the slower they will perform. At most, we can request up to 4 encoded streams, at which the performance is 10-12 FPS over Ethernet (tested on -s left right color disparity disparity_color)

Since disparity_color and depth are in fact the transformed versions of disparity and depth_raw respectively, they do not require a dedicated encoder and therefore can be used without increasing the resources usage on device - so running -s disparity disparity_color will use the same amount of resources as -s disparity, as all transformations are performed on host

[themarpe]

@VanDavv looking good.
Do callbacks now get encoded MJPEG frames or already decoded frames?

And just as a cross check, try retesting with a known 1Gbit connection between the device and host to maybe lay out some expected performance numbers which could be added to readme, etc..

[VanDavv]

@themarpe callbacks receive decoded frames, in preview manager the frames are decoded as soon as they arrive so access to raw mjpeg frames is limited (although if we'd like to e.g. add a functionality to redirect encoded frames to file, we are still able to add this feature)

And will experiment with my setup to test gigabit connection and speeds

[themarpe]

LGTM apart from some performance comments as to what to expect in "optimal scenario" for different cases

[Luxonis-Brandon]

Sweet, thanks both!

[Luxonis-Brandon]

Working well for me. So we may want to make the POE default to not show depth until we get that working via an encoded method.

That way the framerate will not be reduced by the unencoded depth. We could just show say disparity instead, or just the RGB with physical location.

Thoughts?

[Luxonis-Brandon]

A quick note @VanDavv - the overlay of depth information for the color stream is quite small:

Compare to the grayscale:

That said, I think we should merge, and refine over time.

[alex-luxonis]

One possible improvement for later (general, not related to this PR): the text drawn may not be easy (or not possible) to read, depending on the background image color. And filling solid color rectangles to draw over isn't that nice:

We could implement this trick of outlining the text, by double-drawing, first with a larger thickness (that would create the outline), and then the same text again with a smaller thickness and different color:
https://github.com/luxonis/depthai-experiments/blob/8385501/gen2-seq-num-sync/main.py#L133-L135

    cv2.putText(frame[c], text, (8,40), cv2.FONT_HERSHEY_DUPLEX, 1.5, (0,0,0), 8, cv2.LINE_AA)
    cv2.putText(frame[c], text, (8,40), cv2.FONT_HERSHEY_DUPLEX, 1.5, (255,255,255), 2, cv2.LINE_AA)

[Luxonis-Brandon]

Yes, great idea - thanks for bringing that up. We should totally do that for all text @VanDavv as that makes it easy to read no matter the background (black or white, or anything in-between).

[VanDavv]

Yes, that's a great idea! Will merge this PR since it helps in PoE usage and open a new one that addresses the comments above

[VanDavv]

Introduces the fixes / tweaks here - #434 CC @alex-luxonis @Luxonis-Brandon