R10k line is padded to 256 B (as DeckLinks requires) so widths not
divisible by 64 pixels were not displayed correctly.
Not sure if AJA holds also this convetion, it is not mentioned in docs
for NTV2_FBF_10BIT_DPX. However, SDI formats' line widths are generally
divisible by 64 pixels so it is not relevant there.
Steps to reproduce the problem were:
uv -t testcard:size=48x32:codec=R10k -d gl
Although those bits seem to be used as a padding only (eg. according to
multimediawiki), it maps eg. to OpenGL format that uses 2 remaining bits
as an alpha so it is safer to set it to ones.
- the required space for intermediate result was actually 2x larger than
dst buffer could provide
+ make arguments of vc_copylineRGBAtoUYVY restrict again -- no longer
used in situ, thus it can be restricted again
Some macros are quite common so it is perhaps more wise to use a
separate header.
Also moved ref_count_init_once and ref_count_terminate last to misc.h.
- check for exact match first
- continue comparing if bit depths are the same - this was perhaps
incorrect previously, because it reported codec equality if bit
depth was equal
Do not use third parameter of get_decoder_from_to by caller to get fast
decode first, Created function get_fastest_decoder_from instead, that
hides and encapsulates the selection logic.
- get_best_decoder_for: added doxy
- " : return also vc_memcpy
- " : simplified return - there exist only one
conversion in the end (no matter if slow or not)
- fixed protoypes for both get_best_decoder_for and codec_is_in_set:
the first should not be neither const nor pure, 2nd may be pure
- codec_is_in_set: argument can be pointer to const
+ return vc_copylineRGB[A] for RGB->RGB and RGBA->RGBA instead of
vc_memcpy - we cannot know if caller wants or doesn't want to use
rgb-shifts other than default. Both implementations call vc_memcpy
if s/he does
Those were required previously when some conversions had incompatible
prototype (missing r,g,b shifts for pixfmts not using it - that is
almost all except RGBA).
Use distinct fourcc for different profiles - this is now not necessarily
required but it seems like videotoolbox decoder may need to have it set.
Moreover, this fourcc selection is "correct" because the codec
distinguishes the profiles with different codes.
bsrli and bssli are supported since gcc 4.8 and clang 3.7 (7 years old).
Supporting older compilers does not make sense anymore since
UltraGrid needs c++17 support.
