So UVC standard 1.5 supports broadcast quality uncompressed video in only ONE format: UYUV. This is 8bit 4:2:2 video. (NV12 and I420 are 4:2:0, which is severely hampered chroma subsampling)
Uncompressed 10 bit 4:2:2 video is V210. This is not defined in the UVC standard. This means ALL UVC based driverless USB 3.0 capture devices use 8bit.
PCI-E based capture cards however support 10bit, so hence why “HDR” capture cards are currently only really PCI-E for uncompressed capture. There is only ONE capture card that can do this at 4K 60fps 10bit in Linux… A Magewell Pro Capture 4K HDMI Plus card, which uses a Xilinx ARTIX-7 XC7A100 FPGA.
Compressed video payloads over UVC is another story. A H.264 stream can be whatever, but is extremely computationally heavy to decode, and would introduce a very high amount of streaming latency.
As of present, without a specification update, there is no way to achieve 10 bit video over UVC compliant devices.
So what about low compression alternatives? You could use JPEG XS, a stream format that allows 2:1 to 6:1 lightweight compression for 4:4:4 and 4:2:2 YUV video up to 16 bits. https://jpeg.org/jpegxs/ But you’d need a defined payload standard for that to work with UVC… UNLESS…
This comes in with ideas to make the ultimate UVC device… The Logitech C922.
According to this Polish blog post: http://w2017.pl/logitech-vlc-ffmpeg-c922-streaming/
The C922 packetizes H264 inside a MJPEG payload.
We can use this same technique to packetize JPEG XS in a MJPEG payload. Remember, that JPEG XS is very light on CPU since it’s a very low compression codec, and can support bit depths up to 16bit and chroma up to 4:4:4. This can fit in a ARTIX-7 XC7A100 or XC7A200 if necessary.
The HDMI receiver chip would likely be from ITE: http://www.ite.com.tw/en/product/view?mid=98
All that’s required on the Linux end is a demux of the MJPEG payload and decode of the JPEG XS stream embedded in the MJPEG stream.
As of yet, this is literally the only way I can think of to deliver 10bit video over UVC and not incur a CPU performance and latency penalty. It will have to be a low lightweight compression that handles the streaming, but it would fit in USB 3.1 Gen 1 bandwidth if done right, since that is the only “GPIF II” chip that Cypress Semiconductor uses to do UVC protocol communications, and there is no Gen 2 chip on the horizon from Cypress, so there would need to be fitting in under bandwidth restrictions.
I’m letting this idea go to see who can make this FIRST. This idea is no longer proprietary, and is fully public domain, because it is needed, BADLY.