All interop modules reused the util function opengl_interop_init()
(written for the software interop) to initialize the textures properties
from the chroma.
However, the actual texture format may not always be deduced from the
chroma: only the interop implementations have the full knowledge of the
texture details.
Therefore, initialize texture properties directly from each interop
implementation.
Fixes#26735Fixes#26769
Once the sequence is fully parsed we can tell the profile. The return value of
HandleVideoSequence() is how many pictures the decoder should use internally.
p_format->min_num_decode_surfaces contains the minimum for that value.
per discussion in !90, these strings were considered "too technical"
and/or advanced to want translations for, at the risk of ending up with
poor translations.
it is hoped that by adding these comments, it will avoid such unwanted
translation being resubmitted by anyone later.
This was necessary for sharing and for vlc_hold_x11(), but they were
both removed.
Note that the list is still used to match a display to an instance, so
it cannot be removed quite yet.
Originally, both the decoder and the video output would instantiate
VDPAU devices on their own. The process-global list was necessary to
force paired decoder and output to use the same VDPAU instance: they
were matched by server name and screen number.
Now that all components in a given pipeline obtain the VDPAU instance
from a shared decoder device, this trick is no longer necessary.
Incidentally, VDPAU instances would also harmlessly but nevertheless
unnecessarily be shared between independent pipelines within the same
process using the same X11 screen. We can ignore this.
Frames (video surfaces) are always held by one of more fields. Fields
already hold the video context, which holds the decoder device, which
holds the instance.
So frames can rely on any one of their referencing fields to hold the
video context.
Video surfaces in the VA pool do not really need to reference the video
context of their own as they cannot outlive the VA, which already
references the video context.
But referencing the context anyway is cleaner and allows for further
simplifications.
Surfaces logically reference their device (i.e. the video context).
So long as they are stored in the video context, a cycle of
cross-references leads to an enormous memory leak.
see e967f81f6a.
note, this does **not** affect cat-based module selection items
(of which there are just three in use by the core), since that
mechanism uses subcats not cats.
Each cuInit is leaking memory, and cuInit is supposed to be called only
once. Ensure it through a vlc_once_t wrapper, but since the function
table needs to be loaded in order to call into cuda functions, forward
some available device for the initialization.
Below, there is two leaks because of the double decoder device
allocation in debug mode. The first leak is leaked once, and is still
there. The second and third leaks are now reduced to a single one.
Direct leak of 65536 byte(s) in 1 object(s) allocated from:
#0 0x7febb6bf3652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7feb8b56828f (<unknown module>)
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7febb6bf3459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7feb89dc586a (/home/alexandre/workspace/videolabs/vlc-meson/build-native/modules/.libs/libskins2_plugin.so+0x2f1086a)
#2 0x7febb5f195c1 in decoder_device_Open ../../src/input/decoder_helpers.c:174
#3 0x7febb5e67106 in vlc_module_load ../../src/modules/modules.c:243
#4 0x7febb5f196e8 in vlc_decoder_device_Create ../../src/input/decoder_helpers.c:188
#5 0x7febb60a7435 in vout_GetDevice ../../src/video_output/video_output.c:2244
#6 0x7febb5ef7f26 in ModuleThread_GetDecoderDevice ../../src/input/decoder.c:608
#7 0x7feba02ee139 in decoder_GetDecoderDevice ../../include/vlc_codec.h:304
#8 0x7feba02fb51e in lavc_UpdateVideoFormat ../../modules/codec/avcodec/video.c:286
#9 0x7feba0313ff7 in ffmpeg_GetFormat ../../modules/codec/avcodec/video.c:1682
#10 0x7feb9f0bfe12 (/usr/lib/libavcodec.so.58+0x29ae12)
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7febb6bf3459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7feb8b5d386a (<unknown module>)
#2 0x7febb5f195c1 in decoder_device_Open ../../src/input/decoder_helpers.c:174
#3 0x7febb5e67106 in vlc_module_load ../../src/modules/modules.c:243
#4 0x7febb5f196e8 in vlc_decoder_device_Create ../../src/input/decoder_helpers.c:188
#5 0x7febb60a7435 in vout_GetDevice ../../src/video_output/video_output.c:2244
#6 0x7febb5ef7f26 in ModuleThread_GetDecoderDevice ../../src/input/decoder.c:608
#7 0x7feba02ee139 in decoder_GetDecoderDevice ../../include/vlc_codec.h:304
#8 0x7feba02fb51e in lavc_UpdateVideoFormat ../../modules/codec/avcodec/video.c:286
#9 0x7feba0313ff7 in ffmpeg_GetFormat ../../modules/codec/avcodec/video.c:1682
#10 0x7feb9f0bfe12 (/usr/lib/libavcodec.so.58+0x29ae12)
We can't really use an interface** where a void** is expected, that's a
cast/aliasing violation, even though that's what Windows and mingw64 API's do
as well.
We use an interim void* variable that receives the pointer and then set it on
the proper variable with the given type.
Fixes#26083
sys->history[MAX_PAST + MAX_FUTURE] is set a few lines above and can't be NULL
otherwise it would crash on the src->context check above.
It can't be NULL since at least 47c9655e19.
It doesn't work in UWP as that part of the registry is not available via
CoCreateInstanceFromApp(). This might be available via DeviceInformation
from winrt Windows.Devices.Enumeration (not available in wine yet) in the
Properties dictionary, but it would be for UAP/UWP builds only.
Cannot be ported back to 3.0 as this is Vista and above.
This makes it consistent with all the other uses of such defines in
the source code, which are tested for their existence rather than the
actual value.
Benefits of *not* using designated initializers:
- we can't forget a callback
- it's the same in C and C++ (<20)
Benefits of using designated initializers:
- the order of callbacks may not be wrong
- we can read immediately which function is assigned to which callback
(especially if some are NULL)
- an optional callback may be added without modifying all the modules
- we can grep a callback name to find its assignments easily
- it is consistent with others xxx_operations in the codebase
lavc doesn't set this value to a meaningful value. Only the H264 codec
has this value properly set.
Bogus log introduced in 7905bf1eba.
Before the code would rely on refs which is one and add 5 arbitrary pictures
which was OK until HEVC and VP9 were introduced.
The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
where identical to shorttext, or near enough.
bad because:
- wastes resources.
- useless tooltips in prefs GUI (poor UX) - tooltip longtext should add
something of value.
- useless repetition of text in certain help output.
in some cases they differed only in full-stop, creating unnecessary extra
burden on translators.
Without conditional activation of the plugins through autoconf, -rpath
is always defined when adding the plugin libtool archive target to
codec_LTLIBRARIES or nvdec_LTLIBRARIES. If the target's LDFLAGS is not
defined, it will also use AM_LDFLAGS by default.
Sort of revert 1d2b56c68b but it actually
finish the work done in ticket #9367 by removing the last recursive
makefile target in modules/.
It allows faster make (though not significant here) but most of all,
sharing the same variable definition scope in modules/ for all
makefiles.
In particular, this facilitate for future work implementing partial
linking at the module level, which actually needs the list of all
plugins being compiled.
Use only the MMAL_CFLAGS/MMAL_LIBS instead of sharing the flags of a
non-existant plugin. In addition, LDFLAGS is for linker flags different
from the -l or -L ones, and -rpath only needs to be defined when using
conditional compilation from autoconf (LTLIB and VLC_ADD_PLUGIN) so the
MMAL_LIBS must go to LIBADD.
In prevision of the removal of the recursive Makefile.am, use the
MMAL_CFLAGS on every targets that needs them.
Passing NULL ends up using the same value.
We use vd->cfg in all cases so no need to pass it.
Also clean subsequent place_dest calls so we can tell which are not using
vd->source.
It's easier to find out who flushes filters and when.
It's also easier to reorder the code without having the Flush callback above a
lot of common code.
The di_flush call in MMAL passthrough mode was probably wrong.
Romain Vimont