<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 10 февр. 2023 г., 15:44 Terje J. Hanssen <<a href="mailto:terjejhanssen@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">terjejhanssen@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br>
<br>
<div>Den 10.02.2023 04:03, skrev Andrew
Randrianasulu:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">пт, 10 февр. 2023 г.,
04:37 Terje J. Hanssen via Cin <<a href="mailto:cin@lists.cinelerra-gg.org" rel="noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">cin@lists.cinelerra-gg.org</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> We have some threads this month discussing the
performance of UVC HDMI-USB3 Vide Capture stics/dongles
or devices.<br>
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) <br>
<br>
1. To repeate the illustrative article 8-Bit vs 10-Bit
Video Color Explained (millions/banding vs billion
shades): <br>
<a href="https://fujifilm-x.com/en-us/series/the-filmmakers-handbook/8-bit-or-10-bit-video-color-explained/" rel="noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://fujifilm-x.com/en-us/series/the-filmmakers-handbook/8-bit-or-10-bit-video-color-explained/</a><br>
<br>
<br>
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<br>
<a href="https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#preferred-yuv-formats" rel="noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#preferred-yuv-formats</a><br>
<br>
<blockquote><font face="Courier New, Courier, monospace">YUY2
4:2:2 Packed 8 bits pr channel</font><br>
<font face="Courier New, Courier, monospace">Y210
4:2:2 Packed 10</font><br>
<font face="Courier New, Courier, monospace">NV12
4:2:0 Planar 8</font><br>
<font face="Courier New, Courier, monospace">P010
4:2:0 Planar 10</font><br>
<br>
</blockquote>
3. So I found an interesting discussion on the Digital
Photography Review forum: <br>
Cheapest (and decent) way to record 10 bits HDMI on
Windows? <br>
<a href="https://www.dpreview.com/forums/thread/4562209" rel="noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.dpreview.com/forums/thread/4562209</a><br>
<br>
Extract here an interesting section from the first reply
of Mar 19, 2021: <br>
<blockquote>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
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/usb/uvc/uvcvideo.h?h=v5.11.7" rel="noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/usb/uvc/uvcvideo.h?h=v5.11.7</a>
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.<br>
</blockquote>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Isn't such question more for Maintainer?</div>
<div dir="auto"><br>
</div>
<div dir="auto">"USB VIDEO CLASS</div>
<pre><code><pre>M: Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">laurent.pinchart@ideasonboard.com</a>>
L: <a href="mailto:linux-media@vger.kernel.org" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">linux-media@vger.kernel.org</a>
S: Maintained
W: <a href="http://www.ideasonboard.org/uvc/" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.ideasonboard.org/uvc/</a>
T: git git://<a href="http://linuxtv.org/media_tree.git" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">linuxtv.org/media_tree.git</a>
F: drivers/media/usb/uvc/
F: include/uapi/linux/uvcvideo.h
</pre></code></pre>
<div dir="auto">"</div>
<div dir="auto"><br>
</div>
<div dir="auto">from <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS" rel="noreferrer noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS</a></div>
<div dir="auto"><br>
</div>
<div dir="auto">I looked at (hopefully) uvc spec, but mostly for
interlace info</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a href="https://www.spinelelectronics.com/pdf/UVC%25201.5%2520Class%2520specification.pdf" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.spinelelectronics.com/pdf/UVC%25201.5%2520Class%2520specification.pdf</a><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I'll look for guid info some more..</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<blockquote> </blockquote>
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.<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
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(?)<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> 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.<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.)</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is any real external vhs (ish) sources worth 10
bits path?</div>
</div>
</blockquote>
<br>
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.<br>
Digital cameras with direct HDMI output on the other hand may
utilize 10-bit.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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 ....</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
As a generic reference, I compare this with "The Digitization of VHS
Videotapes – Technical Bulletin 31<br>
<blockquote>Digitization Set-up Two with an external capture device
<br>
<a href="https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8b" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8b</a><br>
while Set-up _Three is Digitization with an internal (PCIe)
capture card<br>
<a href="https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8c" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8c</a><br>
</blockquote>
The Digitization procedure/Video compressor section discuss 10-bit
vs 8-bit <br>
<blockquote><a href="https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8c3" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/technical-bulletins/digitization-vhs-video-tapes.html#a8c3</a><br>
</blockquote>
<blockquote>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.<br></blockquote></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">thanks!</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote>
</blockquote>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto"><a href="https://github.com/happycube/cxadc-linux3" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/happycube/cxadc-linux3</a><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">===</div>
<div dir="auto">
<p dir="auto">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.</p>
<p dir="auto"><strong>Note!</strong> cx23885 and cx23888 are
incompatible chips.</p>
<p dir="auto">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.</p>
<p dir="auto"><br>
</p>
<p dir="auto">====</p>
<p dir="auto"><br>
</p>
<p dir="auto">vhs-decode wiki has some ffmpeg command encoding
raw captures into prores 10bit file</p>
<p dir="auto"><br>
</p>
<p dir="auto"><a href="https://github.com/oyvindln/vhs-decode" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/oyvindln/vhs-decode</a></p>
<p dir="auto"><br>
</p>
</div>
</div>
</blockquote>
<br>
Very interesting reading. I admit I have never heard about
"vhs-decode" before and do not yet have an overview of what it
includes.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">A lot of python :)</div><div dir="auto"><br></div><div dir="auto">I tried to compile it on termux, and some python compiler component (numba) died on install, saying my python too new!</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">see also my forwarded mail from project's github</div><div dir="auto"><br></div><div dir="auto">====</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">╰─> [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()</div><div dir="auto"> File "/data/data/com.termux/files/usr/tmp/pip-install-2ef2atl2/numba_c8a210c3a25440f4b4b4a45449fcfb73/setup.py", line 48, in _guard_py_ver</div><div dir="auto"> 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</div><div dir="auto"><br></div><div dir="auto">=====</div><div dir="auto"><br></div><div dir="auto">so VM with debian, probably ....</div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<p dir="auto">===<br>
</p>
<p dir="auto">VHS-Decode produces two timebase corrected
16-bit <code>GREY16</code> headerless files separated into
chroma/luma composite video signals in the <code>.tbc</code>
format alongside <code>.json</code> and <code>.log</code>
files, usable with the LD-Decode family of tools ld-analyse,
ld-process-vbi, ld-process-vits and ld-dropout-correct.</p>
<p dir="auto">
</p>
<p dir="auto">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.</p>
<p dir="auto"><br>
</p>
<p dir="auto">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.</p>
<p dir="auto">Both commands will automatically use the last
file generated as the input.</p>
<p dir="auto">For editors this transcodes an FFV1/V210 output
to a "<em>near complient</em>" interlaced ProRes HQ file:</p>
<div dir="auto">
<pre><code>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"
</code></pre>
</div>
<p dir="auto">For basic online sharing you can use this
command to convert the FFV1 output to a de-interlaced lossy
upscaled MP4:</p>
<p dir="auto">
</p>
<div dir="auto">
<pre><code>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"
</code></pre>
</div>
<p dir="auto">====</p>
<p dir="auto"><br>
</p>
<p dir="auto">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?</p>
</div>
</div>
</blockquote>
<br>
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).</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto"><a href="http://en.macrosilicon.com/info.asp?base_id=2&third_id=45" rel="noreferrer noreferrer" target="_blank">http://en.macrosilicon.com/info.asp?base_id=2&third_id=45</a><br></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I looked again at <a href="https://hdmi2usb.tv/home/" target="_blank" rel="noreferrer">https://hdmi2usb.tv/home/</a> but no, no miracles here too .... "</div><h3>What resolutions are supported?</h3>
<p>The firmware is currently targeted at supporting two operating resolutions;</p>
<ul><li>
<p>16:9 - 720p60 mode</p>
</li><li>
<p>4:3 - 1024x768@60Hz</p>
</li></ul>
<p>Other resolutions can be used but are less tested and may not work." </p><p><br></p><p>usb 2.0 ....</p><p><br></p><p>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.</p><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <br>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<p dir="auto"><br>
</p>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> <br>
<br>
<br>
</div>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" rel="noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer noreferrer noreferrer noreferrer
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div></div>