[Cin] 10-bit 422 Video capture not part of the UVC spec?
Terje J. Hanssen
terjejhanssen at gmail.com
Fri Feb 10 21:00:31 CET 2023
Den 10.02.2023 17:28, skrev Andrew Randrianasulu:
>
>
> пт, 10 февр. 2023 г., 15:44 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>
>
> Den 10.02.2023 04:03, skrev Andrew Randrianasulu:
>>
>>
>> пт, 10 февр. 2023 г., 04:37 Terje J. Hanssen via Cin
>> <cin at lists.cinelerra-gg.org>:
>>
>> 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 at ideasonboard.com>
>> L: linux-media at vger.kernel.org
>> S: Maintained
>> W: http://www.ideasonboard.org/uvc/
>> T: git git://linuxtv.org/media_tree.git <http://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..
>>
>>
>> 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.
>>
>
> What I meant to say is that (my thought ) 8-bit YUY2 output
> support seems to be the current limit of HDMI-USB3 Video Capture
> sticks like in the new ms2130.
> I saw that the (previous) USB2 model that still was announced in
> parallell didn't support YUY2. But I expect this is just a
> question of time as the chip technology evolves - so maybe the
> next model and UVC then get 10-bit support(?)
>
>
>
> may be, I tried to fwd Laurent's answer to both cin list and
> linux-media, just kernel list reject html quotation (?) mobile gmail
> does by default.
Thanks, you have been busy :)
>
>
>> 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?
>
> There have been discussions about that. VHS/Video8 is low-end
> composite video, while S-Video (2) and Component Video (3) are
> better. But cheap ADC to HDMI adapters, sadly also often with
> missing technical specs, most probably at best output 8-bit(?) At
> least here 8-bit YUY2 ms2130 may fit well.
> Digital cameras with direct HDMI output on the other hand may
> utilize 10-bit.
>
By the way, I'll return the unuseable Hama HDMI to USB3 capture stick,
and have ordered a new ms2130. To halph the price I expect the latter
works twice as well :)
Estimated delivery date by the end of next month, though. Then also the
companion ADC adapter should have arrieved.
In the meantme I'll have work enough to continue and fullfill the rest
of my S-video to DV recorder path.
>
>
> yeah .. sdi-usb3 probably can face 10-bit signal at receiving end too
> .... but so far it seems video enthusiasts (ones who buy 400$+ gear +
> all additional devices) and Linux enthusiasts (who like to punch some
> code in) not crossed each other paths, at least in public ....
Sooner or later I'll also give the BMD 10-bit path: Analog to SDI
miniconverter + Hyperdeck shuttle 2, another try, due to the expected
firmware issue a year ago
https://forum.blackmagicdesign.com/viewtopic.php?f=18&t=153772
>
>
> As a generic reference, I compare this with "The Digitization of
> VHS Videotapes – Technical Bulletin 31
>
> Digitization Set-up Two with an external capture device
> https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8b
> while Set-up _Three is Digitization with an internal (PCIe)
> capture card
> https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8c
>
> The Digitization procedure/Video compressor section discuss 10-bit
> vs 8-bit
>
> https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8c3
>
> Using 10-bit is advocated by many, although several
> institutions also use 8-bit (see Appendix B). It is debatable
> whether 10-bit is required for VHS video but some believe that
> because of VHS’s shortcomings in the area of resolution,
> luminance and colour range, capturing the finer details
> becomes more important.Footnote 29 It is believed that
> capturing at higher quality will ultimately produce a better
> result if significant manipulation occurs, such as editing of
> files, and a better result if future compression of the file
> is necessary.
>
>
>
>
> thanks!
>
>
>>
>> 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
>>
>>
>
> Very interesting reading. I admit I have never heard about
> "vhs-decode" before and do not yet have an overview of what it
> includes.
>
>
>
> A lot of python :)
>
> I tried to compile it on termux, and some python compiler component
> (numba) died on install, saying my python too new!
>
>
> see also my forwarded mail from project's github
>
> ====
>
> ╰─> [8 lines of output] Traceback (most recent call last):
> File "<string>", line 2, in <module>
> File
> "<pip-setuptools-caller>", line 34, in <module>
> File
> "/data/data/com.termux/files/usr/tmp/pip-install-2ef2atl2/numba_c8a210c3a25440f4b4b4a45449fcfb73/setup.py",
> line 51, in <module> _guard_py_ver()
> File
> "/data/data/com.termux/files/usr/tmp/pip-install-2ef2atl2/numba_c8a210c3a25440f4b4b4a45449fcfb73/setup.py",
> line 48, in _guard_py_ver
> raise RuntimeError(msg.format(cur_py, min_py, max_py))
> RuntimeError: Cannot install on Python version
> 3.11.2; only versions >=3.7,<3.11 are supported
>
> =====
>
> so VM with debian, probably ....
>
>
>> ===
>>
>> 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?
>>
>
> I think I don't mess with internal proprietary PCIe capture cards
> anymore. I had once a Pinnacle DV500/DVD system for Windows 98 (or
> was it 95).
>
>
>
> yeah, unfortunately they all more or less proprietary - firmware is
> closed-source, anf for some nice in overview chips you can't even get
> spec easily
>
> http://en.macrosilicon.com/info.asp?base_id=2&third_id=45
> <http://en.macrosilicon.com/info.asp?base_id=2&third_id=45>
>
> ms1824 looks interesting (even if *ten* channels of input surely
> overkill) with 16 bit yuv 4.2.2 output listed in params, but who will
> make card or box around it?
>
> Custom electronics for video tend to cost much more if they only done
> in small batches .... even if you are lucky to have engineer(s) with
> some free time!
>
>
> I looked again at https://hdmi2usb.tv/home/ but no, no miracles here
> too .... "
>
>
> What resolutions are supported?
>
> The firmware is currently targeted at supporting two operating
> resolutions;
>
> *
>
> 16:9 - 720p60 mode
>
> *
>
> 4:3 - 1024x768 at 60Hz
>
> Other resolutions can be used but are less tested and may not work."
>
>
> usb 2.0 ....
>
>
> So even if in theory open hardware is better in practice lack of
> engineers (with access to components and debug equipment) makes
> projects look .... underdeveloped.
>
>
>
>
>
>>
>>
>>
>>
>>
>>
>> --
>> Cin mailing list
>> Cin at lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230210/c474a5a7/attachment-0001.htm>
More information about the Cin
mailing list