technically it will be C2Y but the c23.h can be perhaps used for both
in c++, std::size() is rather used
This fixes compilation of pano_gl, where its implementation
of countof clashes with the macro (leaked through
debug.h->color_out.h->utils/macros.h, which no longer contains that
define).
This is handled differently and may trigger unexpected decode to HW_VDPAU
if gl display advertises that, eg. `uv -t testcard -c lavc:c=MJPG -d gl`.
This fixes the commit 647d8627 (2025-06-25) that unintentionally
enabled that.
The HW accel is hanndled actually separately ahd snouldn't be "enabled"
in this way.
see also recent commit 951f9648
countof seem to be upcoming C2Y language macro (and _Countof operator)
so make use of it instead of ARR_COUNT that is now removed.
compare just the in codec and the MIN(intermediate, out_pixfmt)
to avoid missleading message
`[to_lavc_vid_conv] conversion is reducing subsampling from 4444 to 4440`
as eg. in:
<https://github.com/CESNET/UltraGrid/issues/480>
if converting R12L to bgra over RGBA - the alpha channel is present just
in the intermediate but both ends have 444 without alpha channel.
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).
