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)
Matrix (1) doesn't seem to be generic enough in case of UYVY.
THe aim is, among others, last resort fix of the BT.601 problem when
got from QSV compression and no YCbCr->RGB conversion took place.
The JPEG is either BT.709 (lavc-encoded, YCbCr encoded by GPUJPEG)
or Adobe RGB (if encoded by GPUJPEG). Both are processed correctly
by the lavd decoder - BT.709 is assumed if YCbCr, RGB is decoded
to GBRP (so either no conversion to RGB PF or default handling
if the output PF is YCbCr).
FFmpeg returns always bt470b, even with GPUJPEG SPIFF JPEGs (only the
color_range can be either tv or pc depending if sender sets range as
JPEG or MPEG - we're setting MPEG for YCbCr always).
Also alter the JPEG message.
The same assignment is later in the get_av_pixfmt_details() call (this
is the relict from the times when function was implemented differently
- 23ca8f37).
It can be used in place of other network-related headers, not just for
htonl and family.
+ compat for fd_t and INVALID_SOCKET (that has been in config_*.h)
