Den 10.02.2023 04:03, skrev Andrew Randrianasulu:
пт, 10 февр. 2023 г., 04:37 Terje J. Hanssen via Cin
<[email protected]>:
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 <[email protected]>
L: [email protected]
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(?)
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.
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.
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.
===
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).
--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin
--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin
