- Jul 13, 2023
-
-
This adds a -Drust feature option to the meson build system, which aims to enable pure Rust modules. This option will check for the presence of cargo (Rust package manager and build system) and give a warning about the experimental nature of the Rust modules. This option is disabled by default.
-
If the underlying windows is or becomes null, mark the accessible interface as invalid
-
this may happen when the interface is shutting down (render stopped but video still runing)
-
Steve Lhomme authored
So far we did not need it. We should always have the format matching the one we detected by the decoder. If we don't that means the packetizer failed to reset the decoder.
-
Steve Lhomme authored
-
Steve Lhomme authored
This is what is passed in the normal decoding case. This fixes an issue where 10-bit sources don't play properly as we can't tell from the Profile 0 is we're decoding in 8-bit or 10-bit.
-
Steve Lhomme authored
-
Steve Lhomme authored
We read 32 bits, we skip exactly 8 bytes. We don't need to know the storage size where we put the value. From C11 7.20.1.1: The typedef name uintN_t designates an unsigned integer type with width N and no padding bits.
-
Steve Lhomme authored
From C11 7.20.1.1: The typedef name uintN_t designates an unsigned integer type with width N and no padding bits.
-
Steve Lhomme authored
We may want to change the size. This should be kept coherent.
-
Steve Lhomme authored
We may want to change the size. This should be kept coherent.
-
Steve Lhomme authored
We use 4 bytes, no uint32_t is involved. The code around already use some hardcoded sizes.
-
Steve Lhomme authored
We don't have to have the same storage as the source.
-
Steve Lhomme authored
-
Steve Lhomme authored
It's better than assuming it's a uint32_t. We don't need to know its type.
-
Steve Lhomme authored
It's initialized to 0 and incremented with uint32_t values. It can never exceed 32-bit values.
-
Steve Lhomme authored
We write 16 bits anyway. From C11 7.20.1.1: The typedef name uintN_t designates an unsigned integer type with width N and no padding bits.
-
Steve Lhomme authored
p_buf is effectively p_block->p_buffer + 2U + i_psz_bytelength, ie the buffer after the subtitle text. The use of i_psz_bytelength after that seems suspicious.
-
Steve Lhomme authored
GetWBE() reads exactly 2 bytes. We don't need a sizeof for that.
-
Steve Lhomme authored
We use 2 bytes, no uint16_t is involved. The code around already use some hardcoded sizes.
-
Steve Lhomme authored
This is more logical. The #if check should also use that, but we can't use sizeof() here.
-
Steve Lhomme authored
We have to read 16 bytes (GUID), then 2 (number of streams) then at least one entry (2 bytes). In the end 2*2 = 2+2, but the multiplier is incorrect in this case. We don't need to use sizeof(uint16_t) as we actually read with a number of bytes (2).
-
Steve Lhomme authored
So there can be no mismatch.
-
Steve Lhomme authored
From C11 7.20.1.1: The typedef name uintN_t designates an unsigned integer type with width N and no padding bits.
-
Steve Lhomme authored
They will always match.
-
Steve Lhomme authored
From C11 7.20.1.1: The typedef name uintN_t designates an unsigned integer type with width N and no padding bits.
-
- Jul 12, 2023
-
-
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
-
Fix the following leak: Direct leak of 440 byte(s) in 1 object(s) allocated from: #0 0x7f16238e1369 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x7f162362bb1b in picture_NewFromFormat ../../src/misc/picture.c:271 #2 0x55a72c5485c7 in test_opengl_offscreen ../../test/modules/video_output/opengl/filters.c:158 #3 0x55a72c547005 in main ../../test/modules/video_output/opengl/filters.c:294 #4 0x7f162314c84f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
-
- Jul 11, 2023
-
-
Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
macosx: Do not show recents section in video library table view if no recent media items are available Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
macosx: Constify pointers in VLCLibraryVideoCollectionViewsStackViewController.generateCollectionViewContainers Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
Tracklist events were aggregated by the processing code into it's own linked-list which was then used to drpo the events. The code was different from how events are released when closing the application with events that were not sent to the dbus thread. This commit unify the way they are released by duplicating the existing release code matching the signal type and dropping them from the ProcessEvents function instead.
-
When a second tracklist (append or remove) event was queued to the dbus thread, it detected that an existing event was already there and discarded the event without destroying it, despite the ownership being transferred. By checking whether the event was transferred or not and release it if not, we don't risk leaking the event structures and the underlying items hold by them. No functional changes since those events were not discarded anymore.
-
This commit fixes a memory leak on playlist event. After MR !3189 [^1], the leak was fixed when closing the interface before the events are processed, but not when the events were being processed and the ownership moved to the dbus thread. When a second tracklist (append or remove) event was queued to the dbus thread, it detected that an existing event was already there and discarded the event without destroying it, despite the ownership being transferred. It is necessary to check whether the event was transferred or not and release it if not, which will be done in a following commit, but the tracklist events are gathered by the event processing code and event type duplicates don't have the same information and shouldn't be discarded first, which solves the following root leak: ==81939==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fd01ced85cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x7fd00d6a3129 in tracklist_append_event_create ../../modules/control/dbus/dbus_tracklist.c:41 #2 0x7fd00d6b1f98 in playlist_on_items_added ../../modules/control/dbus/dbus.c:1063 #3 0x7fd01c03e071 in vlc_playlist_ItemsInserted ../../src/playlist/content.c:76 #4 0x7fd01c045b3e in vlc_playlist_Expand ../../src/playlist/content.c:382 #5 0x7fd01c0537e8 in vlc_playlist_ExpandItem ../../src/playlist/preparse.c:59 #6 0x7fd01c053942 in vlc_playlist_ExpandItemFromNode ../../src/playlist/preparse.c:76 #7 0x7fd01c05397f in on_subtree_added ../../src/playlist/preparse.c:87 #8 0x7fd01c070088 in OnParserSubtreeAdded ../../src/preparser/preparser.c:171 #9 0x7fd01c08848b in input_item_parser_InputEvent ../../src/input/item.c:1402 [^1]: videolan/vlc!3189 Refs #27780 Fixes #28307
-
Those functions are defined in a header file which will not use them directly. `static` only will imply that the function will be used in the file including it or the header itself. `static inline` is much more suitable and will remove the unused function warning.
-
... and add it back where it was missing in a source file. Also regroup the includes in libvlc_internal.h somewhat.
-