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.
In order not to be pressed by accident - other SW displays disable 'q'
as well.
Also, the call was incorrect - the message with the key would receive
root module because the first argument is the receiver of the key event,
which should be the sdl display mod. Also the events were not handled in
check_message event.
- module is now removed when reach ref=0
- childer now hold reference to parent
As a consequence, if parent is (mistakenly) removed before child, the
poiner to it doesn't need to be erased, which is bug-prone (other thread
might have already retrieved the parent pointer).
This allows indirect conversion of 8-bit YUV 4:4:4 at least to Y416 for
displays that do not support VUYA directly over VUYA. Previously, due
to limited set of conversions from yuv444p and to Y416 it was UYVY, which
decimated the subsampling to 4:2:2.
If running from inside out-of-tree build, the shaders were not located -
now look them up in srcdir (if the the formerly looked shader directory
doesn't exist).
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
to avoid unintended change in behavior because the behavior for VC_NONE
has changed
It should perhaps not be called on VC_NONE but if so, we should perhaps
catch and investigate that.
somehow more readable - the flag may be also searched directly
PRORES has set interframe=TRUE, perhaps irrelevant - not preserved
+ fix warning (0.0->0 conversion for block_size_pixels)
almost everytime when opaque=TRUE, the subsampling is 0
An exception was VDPAU which has set both opaque=1 and subsampling=4440
but it seem that the subsampling doesn't need to be necessarily set.
Also for VC_NONE is_codec_opaque() returns newly true (VC_OPAQUE=0).
winsock2.h (include from utils/net.h) should be included prior to
windows.h, otherwise windows.h includes winsock.h (version 1), that
is incompatible. WIN32_LEAN_AND_MEAN causes some headers not being
included with windows.h (including winsock.h).
Seems to work correctly now (aside that it converted to BT.601 by the
device, not BT.709, which is an outstanding issue with RGB formats passed
to QSV).
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.
Since the pulsation issue, it was not much usable, anyways and this
clean-ups the code a bit.
Also the behavior will be now more deterministic - it behaved differently
with patched FFmpeg (most likely GH Linux builds), othewrise differntly.
+ enable the header-inserter if user expliclty requesetd intra-refresh
refers to GH-114
Avoid pulsation with inra-refresh by repeating the missing SPS/PPS with
header inseter.
Unfortunately this is doesn't work well with HEVC because it seems that
the NVIDIA encoder keeps the reference almost forever in specific cases,
eg. `testcard:patt=text`. However, it _may_ work under some circumstances.
Due to recent changes, libavcodec initialization fails because trying
to register the lavc module prior to vcomp.
This crashes due to the recent changes but it has been a dark zone so far.
Initialize the vcomp module correctly prior to the lavc.
+ add assert to module_register that would catch this problem
to allow multiple calls of module_done to same state (as keyboard_control
is called).
otherwise dump-tree would fail
This acutally revers the commit 33bdcb48 (2020-03-13).
Unsure if the name is really needed except the hd-rum-translator where it
may not need to store this in module - removing that may be considered as
it simplifies the code (added with commit c1b0bd8f2).