When included prior to (Mingw-W64) windows.h, it causes compilation
fail, because "R" is used as a param name in transitively included
avx512fp16intrin.h.
Do not enforce the file to be either included before stdlib.h or stdlib.h
to be using __STDC_WANT_LIB_EXT1__ = 1. The bound checking API is
currently nowhere implemented, anyways, and we may use system native secure
qsort implementation (qsort_r in *NIX, MS variant of qsort_s).
Removed some old FFmpeg compat functions that cannot be used, since UG
won't compile with that version anyways (even newer compat was already
removed).
+ moved some function definitions from header to implementation file
(perhaps needlessly in header and it worsens readibility)
This was unnecessary compat macro, since we always build with a compiler
that understands __attribute__ except of the AJA module in MSW, which
uses MSVC compiler
As a last resort sort tie-break, codec_t value was used but the sorting
was actually descending. It is perhaps more natural to have it ascending
(although not so important).
Fixed wrong ordering in rare cases, eg.:
1. R10k->UYVY->yuv444p
2. R10k->UYVY->yuv422p
For both conversion chain, the same property 10b 4:2:2 is selected. But
as a tie-break, R10k is compared with resulting AVPixelFormat's
properties, winning #1 because seemingly keeping 4:4:4 subsampling, not
reflecting the degradation in chain.
To fix it up, use for the second comparison the minimum of src pixfmt
desc and the conversions' chain (for both are the same as mentioned in
previous paragraph).
+ improved debugging (in debug2, print comparison results & print
property of the uv->uv-only conversions)
This will allow user more control over compression if requiring a
different properties than would default sorting select.
This is mostly to avoid user specifying '--param lavc-use-codec', which
is not supported, anyways.
configure av_to_uv_conversion and swscale only once if needed
This has on one hand performance advantages. More importantely,
from_lavc_vid_conv now generates a warning on depth/subsampling
degradation. If it is the case, without this change, output would be
spammed by that warning for every decoded frame.
Steps to reproduce the fixed behavior:
uv -t testcard:codec=R10k -d dummy:codec=v210 -c libavcodec
Improved/fixed AV pixfmt comparison algorighm (get_available_pix_fmts).
If UV->UV->AV is involved, the lower bound of properties (bitrate,
subsampling) is used for the comparison. This would prevent eg.
conversion chain v210->UYVY->10b to be incorrectly treated as 10 bit
(because there is 8 bit format in the chain).
removed .id member from struct pixfmt_desc and the comparator
compare_pixfmt is not usually used directly as a comparator itself but
called from within another comparator. If 2 pixels format have the same
properties, the caller should rather decide by itself if there is some
other metrics to conside or just compare according to identity in the
end.
- renamed in_frame - now it is actually out_frame from our perspective
- same_linesizes - exit early + doxy documentation
- other docuementation improvements
changed prototype of some functions:
- to_lavc_vid_conv - accept (char *) instead of (struct video_frame)
- get_av_pixfmt_details - (enum AVPixelFormat) instead of int
+ make to_lavc_vid_conv.c partially C++ compatible (I attempted first to
include it as was it libavcodec.cpp), so leave it (just in case)
Handle conversion to codec supported input pixel format entirely in
to_lavc_vid_conv.
+ removed AVPixelFormats (both codec input and sws input) from struct
(no longer needed)
+ cleanup - set sws pointer to NULL (prevent potential double free)
YUV is always limited rante BT.709, RGB full range. Thus it doesn't need
to be in the conversion table for every one pixfmt. Also UG pixfmt was
actually useless in the prototype.
FFmpeg's Y210 and Y212 can be directly mapped to UG Y216 (have
just lower bits unused). This shouldn't, however, be given directly to
uv_to_av_pixfmts, because the mapping isn't 1:1. If it would, for
encoder, eg. the conversion Y216->Y210 will be considered as lossless
but it is reducing depth 16->10 b. So added just dummy conversions for
them.
Also removed RG48 and RGB dummy conversions to corresponding AV pixel
formats. This is the opposite case as mentioned in previous paragraph,
the correspondence is 1:1. Also the conversion/memcpy is dispatched
directly in av_to_uv_convert().
Until now only aggregate time of pixfmt change was printed. But when
there will be more indirect conversions (eg. XV30->Y416->R12L), it would
be useful to eventually split the decode times to assess a bottleneck.
fixed crashing:
uv -t testcard:codec=R10k:size=3600x2160 -d dummy -c \
libavcode:encoder=libx265:disable_intra_refresh --param \
force-lavd-decoder=hevc_qsv,decoder-use-codec=R10k
The problem was that 3600 width rounds up to 3648 pixel for which there
was not allocated enough space (even with MAX_PADDING, which doesn't
protect against such cases).
vc_get_size() should be used instead of vc_get_linesize in all this
cases.
Allow to use AV conversion and consequently UG pixfmt conversion.
This should avoid using falling back to swscale conversion in most of
the cases. Moreover, it can be not only a fallback behavior but also a
generailzation reducing the need to write AV conversion to plenty of UG
pixfmts.
Do not use av_to_uv_conversions::native to select best ultragrid codec_t
matching AVPixelFormat.
This will allow deploy policies (to keep color space or bit depth) and
doesn't require developer to pick one <codec_t,AVPixelFormat> pair as
"privileged".
The structure is no longer part of the API and the indirection is
unneeded. On the other hand, its size could not have been possible to
query.
+ use enum AVPixelFormat in the struct instead of int
+ removed unneeded headers from module header
