Hello Andrew, (CC'ing the linux-media mailing list, as the discussion you've forwarded already occured on a public list I assume that's not an issue) пт, 10 февр. 2023 г., 06:03, Andrew Randrianasulu: > пт, 10 февр. 2023 г., 04:37 Terje J. Hanssen via Cin <cin@xxxxxxxxxxxxxxxxxxxxxx>: > > > We have some threads this month discussing the performance of UVC > > HDMI-USB3 Vide Capture stics/dongles or devices. > > If technical specs are available, sadly often deficient, they may manage > > 422 chroma subsampling, but limited to 8-bit "Deep color" (4KVC00) or > > "YUY2" (ms2130) > > > > 1. To repeate the illustrative article 8-Bit vs 10-Bit Video Color > > Explained (millions/banding vs billion shades): > > > > https://fujifilm-x.com/en-us/series/the-filmmakers-handbook/8-bit-or-10-bit-video-color-explained/ > > > > > > 2. In a couple of learn.microsoft articles, 10- and 16-bit YUV Video > > Formats are recommended for capturing, processing, and displaying video, > > while 8-bit YUV color formats that are recommended for video rendering. To > > extract and learn the most relevant YUV formats in this context from the > > table > > > > https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#preferred-yuv-formats > > > > YUY2 4:2:2 Packed 8 bits pr channel > > Y210 4:2:2 Packed 10 > > NV12 4:2:0 Planar 8 > > P010 4:2:0 Planar 10 > > > > 3. So I found an interesting discussion on the Digital Photography Review > > forum: > > Cheapest (and decent) way to record 10 bits HDMI on Windows? > > https://www.dpreview.com/forums/thread/4562209 > > > > Extract here an interesting section from the first reply of Mar 19, 2021: > > > > It almost looks like 10-bit may not be part of the UVC specs unless the > > device does hardware H.264 or HEVC decoding, there are no 10-bit color > > formats that appear in > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/usb/uvc/uvcvideo.h?h=v5.11.7 > > such as p010, and I would expect that if the UVC spec supported p010 video > > it would have appeared in the Linux kernel by now. > > Isn't such question more for Maintainer? > > "USB VIDEO CLASS > > M: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > L: linux-media@xxxxxxxxxxxxxxx > S: Maintained > W: http://www.ideasonboard.org/uvc/ > T: git git://linuxtv.org/media_tree.git > F: drivers/media/usb/uvc/ > F: include/uapi/linux/uvcvideo.h > > " > > from > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS > > I looked at (hopefully) uvc spec, but mostly for interlace info > > https://www.spinelelectronics.com/pdf/UVC%25201.5%2520Class%2520specification.pdf > > I'll look for guid info some more.. The UVC specification standardizes very few pixel formats, but allows for devices to expose additional frame-based formats. In practice devices use the same GUIDs as Windows in that case, and the uvcvideo driver supports many of those already. See include/media/v4l2-uvc.h in the latest mainline kernel for a list. This could easily be extended with 10-bit YUV formats. > > If someone can confirm this is the case also today, we don't need to search > > for cheap or inexpensive HDMI-USB3 Video capture stick/dongles with 10-bit > > 422 output support. > > Down In the same thread also some high-priced UVC compliant devices are > > mentioned, but they tend to support 10-bit on HDMI input and so downscale > > it to 8-bit on USB3 output. > > Apparently hacked Cx driver can output 16 bits as ADC, but then we have > question of feeding it with good enough signal (vhs-decode just vampires > into VCR guts.) > > Is any real external vhs (ish) sources worth 10 bits path? > > https://github.com/happycube/cxadc-linux3 > > === > > cxadc is an alternative Linux driver for the Conexant CX2388x series of > video decoder/encoder chips used on many PCI TV tuner and capture cards. > > *Note!* cx23885 and cx23888 are incompatible chips. > > The new driver configures the CX2388x to capture in its raw output mode in > 8-bit or 16-bit unsigned samples from the video input ports, allowing these > cards to be used as a low-cost 28-54Mhz 10bit ADC for SDR and similar > applications. > > ==== > > vhs-decode wiki has some ffmpeg command encoding raw captures into prores > 10bit file > > https://github.com/oyvindln/vhs-decode > > === > > VHS-Decode produces two timebase corrected 16-bit GREY16 headerless files > separated into chroma/luma composite video signals in the .tbc format > alongside .json and .log files, usable with the LD-Decode family of tools > ld-analyse, ld-process-vbi, ld-process-vits and ld-dropout-correct. > > The gen chroma scrips will use decoded .tbc files and generate standard > video files by default a lossless, interlaced top field first and > high-bitrate (roughly 70-100 Mb/s) FFV1 codec video which, which although > ideal for archival and further processing. > > > For editing due to lack of support of FFV1 and sharing online without > de-interlacing is not supported properly, as such the two commands are > provided below to make suitable files for this use. > > Both commands will automatically use the last file generated as the input. > > For editors this transcodes an FFV1/V210 output to a "*near complient*" > interlaced ProRes HQ file: > > ffmpeg -hide_banner -i "$1.mkv" -vf setfield=tff -flags +ilme+ildct > -c:v prores -profile:v 3 -vendor apl0 -bits_per_mb 8000 -quant_mat hq > -mbs_per_slice 8 -pixel_format yuv422p10lep -color_range tv > -color_primaries bt709 -color_trc bt709 -colorspace bt709 -c:a s24le > -vf setdar=4/3,setfield=tff "$1_ProResHQ.mov" > > For basic online sharing you can use this command to convert the FFV1 > output to a de-interlaced lossy upscaled MP4: > > ffmpeg -hide_banner -i "$1.mkv" -vf > scale=in_color_matrix=bt601:out_color_matrix=bt709:1440x1080,bwdif=1:0:0 > -c:v libx264 -preset veryslow -b:v 15M -maxrate 15M -bufsize 8M > -pixel_format yuv420p -color_primaries bt709 -color_trc bt709 > -colorspace bt709 -aspect 4:3 -c:a libopus -b:a 192k -strict -2 > -movflags +faststart -y "$1_1440x1080_lossy.mp4" > > ==== > > Maaay be we still can use pci-e capture card with normal inputs, just > process raw captures to see if there any difference between 8 and 10 bit? -- Regards, Laurent Pinchart
