ubuntu-latest is now U24.04, which uses .source files in deb822 format
instead the original .list in one-line-style format. ubuntu-latest is
used by Coverity runner.
The documentation in header for
NDIlib_video_frame_v2_t.line_stride_in_bytes says that if set to 0,
default value (size of pixel * bpp) will be used.
However, this doesn't seem to work for P216 and PA16 in Windows. It does
in Linux, also 8-bit formats do not require that. However in Windows,
it causes "No data received.".
see also GH-148
Compared to MSW, NDI doesn't set neither the NDI_RUNTIME_DIR_V6
environment variable nor doesn't have "global" runtimne installation path.
The dylib is, however, included dirctly inside individual applications'
bundles. Most of the NDI Tools apps use libndi_advanced.dylib but some
(including the used NDI Launcher) uses libndi.dylib.
In the [wiki], for macOS and Windows, NDI Tools installation is advised,
which does bring its own NDI Runtime, but in a different path. So adding
it for Windows.
[wiki]: https://github.com/CESNET/UltraGrid/wiki/NDI
- allow also matching for machine name (case-insensitive) in addition
to source name
- document it in help
- various improvemetnts: includes, the partial matching is now done in
a separate loop and without c++ regexes (readabilitz)
Set lmt_rng=0 for full-range src YCbCr only - the color conversions are
used for both (src) YCbCr->RGB and RGB->YCbCr (perhaps less often). In
the second case, the input is full-range so that output YCbCr would be
full-range YCbCr 709. which is incorrect.
If CS conversion is done, handle also full-range input. This shouldn't be
the case most of the time (we use always limited range) but the case that
is handled is namely a JPEG from a webcam or so, which is 601
limited. Full YCbCr->YCbCr is not handled by this commit.
Check if range is MPEG and CS=BT470GB (JPEG compressed with FFmpeg in
UltraGrid). Otherwise do not override the props - JPEGs from webcamse
etc. that almost certailny have the JPEG (full) range.
(if BT601 is not set by --param)
The default value is SDL_YUV_CONVERSION_AUTO, which is 601 for SD and 709
for HD. UltraGrid doesn't distinguish and implictly assumes 709 always
(although 601 for SD makes sense).
In MSW it seems like the video.info is written in text mode, so that line
ending is CRLF. When read in POSIX systems, \r is not consumated so that
expect it can be present.
Remove MJPG codec_t which was complementary to JPEG. The difference was
that JPEG was used for JPEG with restart intervals and MJPG without.
But slices are now enabled for MJPG (emits reset marker every 16 lines)
which actually gives the GPUJPEG decoder a space for efficient decoding.
Measured decoding performance using Ryzen 7900X and RTX 4080:
NewZealand (UYVY, 3840x2160, frame 2500):
encoded by\decoded by GPUJPEG lavd
-c libavcodec 7.1 ms 19 ms
-c gpujpeg 1.35 ms 14.3 ms
-t testcard:s=3840x2160:patt=text
encoded by\decoded by GPUJPEG lavd
-c libavcodec 2 ms 40 ms
-c gpujpeg 25 ms 40 ms
The advantage is simpler maintanance (no need to handle 2 codec
identifiers) and also performance because from the above, the GPUJPEG
decode should be faster even for JPEGs encoded by lavc.
Only situation where lavd performs better is a stream without restart
intervals at all (either `-c lavc:slices=1`, `-c gpujpeg:r=0` or from
a webcam), let say 28 ms for lavd and 40 for GPUJPEG. But it is not worth
keeping it for such a case - it will be better implemented using struct
pixfmt_desc to return rst count and picking the decoder according to
this if really needed.
As this can occur if the source is eg. a webcam-compressed JPEG and
cannot be easily work-arounded, print the warning just once.
Also update the message - it is not problem that is not being unsupported
but clipping the values (also redundant "may", because we can be sure).
Hint to use matrix2 - matrix (1) is somehow special, especially when
handling UYVY that is handled (historically) very unorthodoxly - after
matrix applied, marked as RGB (YUV expanded to 4:4:4).
also improved including (IWYU)
