Fix the benchmark tool build when src/config.h present and CUDA
conversions enabled there. The appropriate CUDA files will be required
if HAVE_LAVC_CUDA_CONV is defined.
If there is no direct conversion from a AV PF compatible with internal
format, penalize a bit.
This may be mostly unneeded but just in case. It can be safely reverted,
anyways.
Assume that the output pixel format (ugc) is supported if there is at
least one conversion. This may not be optimal but it is just as it was
until now, we just remove the hard coded list.
Effectively this is just a refactor, except:
- VDEC_PRIO_NOT_PREFERRED now not returned if internal.rgb !=
codec_is_rgb(ugc) - doesn't seem relevant, because the codec is already
probed and ugc determined. So any alternative decompress will need to do
the conversion as well.
When supported by the display, this eliminates the conversion eg. to
Y416 for video display because UYVY or v210 are 4:2:2. But the conversion
went over UYVY anyways (there was no conv from Y444 keeping subsampling), eg:
`$ uv -t testcard:c=vuya -d gl`
was originally:
```
./src/libavcodec/from_lavc_vid_conv.c: selected conversion from yuv444p to Y416 with UYVY intermediate.
```
now VUYA is selected
Set the metadata for parallel conversion later - av_frame_make_writable()
may actually alter that (at least pointer but perhaps also linesize), those
old values might have been invalidated by that lavc call.
Corrected various spelling mistakes in comments, documentation, and
variable names across the project. Changes include:
- Documentation files (CONTRIBUTING.md, README.md, etc.)
- Source code comments in C/C++ files
- Function parameter names and descriptions
No functional changes were made.
1. to SDL3 nv12 (not supported before)
2. to_lavc - use rgba_to_bgra - the vc_copyline version was not keeping alpha
(if ever used - this may cause regressions, unfortunately, if alpha is
assumed to be 100%, because the orig version set it always)
3. uyvy_to_i420 use by testcard and to_lavc
uyvy_to_i420: do not write out of bounds
If width % 2 = 1, 1 extra luma on first line of pair will override the
first luma on the second.
There are some calls using just the codec_ctx
parameter, which fail (with the compat with
legacy FFmpeg).
eg. `uv -A Opus -s testcard` (using the old FFmpeg)
The rationale is to separate the config.h-dependent stuff to a separate
file to eliminate the need to transitively include config.h.
+ fix the files that need config.h directly to include it
Some AVCodec properties like pix_fmts or sample_fmts are marked as
deprecated and should be replaced by avcodec_get_supported_config()
in current FFmpeg.
Created compat functions to get rid of deprecate warnings running with
both old and new FFmpeg.
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.
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).
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)
Mainly depth is included in Y_ and CBCR_LIMIT - the used denominator
255.0 matched only 8 bits.
Add (substract) epsilon 0.5 when converting the to integer to round the
value correctly.
