Pixel format discussion

[NickSpag]

In the camera implementation it references Video 4 Linux 2's (linux's video capture) pixel format definitions- basically, how each pixel's data is arranged in the byte array. Presumably we'll need the equivalent in macOS's Core Video apis. The source lists 3 supported formats, a top-level list in the Camera implementation, which I outlined at the end.

Supported looks to mean that it's properly handled in the get_next_frame() method on the FrameInput. When the camera is initialized one of the formats is defined, and then in get_next_frame each format has its own case on a switch statement that properly rearranges the bytes in accordance with what the RasterHandle return type presumably needs. In the raster_handle.hh header, a 'RasterHandle' is actually a VP8RasterHandle. So the arrangement that get_next_frame method is converting to is probably the arrangement that salsify's VP8-derived codec needs. We should understand this better but in reality we could initially just ensure that Core Video is kicking out frames in the same format as the one v4l2 used to reuse the original source's arrangement code, but with different format definitions in line with CoreVideo. Or abstract out those formats to something that isn't platform-specific and have some compiler directives that sub in for V4L2 or macOs or whatever. CoreVideo has a ton of pixel formats, listed here, and I think most of ours are in the kCVPixelFormatType_4##YpCbCr8 and then Planar/PlanarFullRange/BiPlanar/etc. Not 100% sure yet. Help wanted lol.

V4L2_PIX_FMT_NV12 (the default, see /salsify/real-webcam.cc: 56 and salsify/salsify-sender.cc:203)
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-nv12.html

V4L2_PIX_FMT_YUYV
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuyv.html

V4L2_PIX_FMT_YUV420
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuv420.html