- Oct 04, 2024
-
-
-
-
-
this is not an error but it lights up red in various log viewers, might be confusing.
-
- Oct 03, 2024
-
-
And put the vlc_object_t argument in 1st, to behave like most API. cf. 9c57c2cc This will allow adding extra params easily, like: - bool parse_subitems (to remove input_item_t.i_preparse_depth) - bool interact (to remove input_item_t.b_preparse_interact)
-
-
This will allow adding extra params easily, like: - bool parse_subitems (to remove input_item_t.i_preparse_depth) - bool interact (to remove input_item_t.b_preparse_interact)
-
-
Resulting in the following changes when thumbnailing: - no renderer - no stats - no sout - no titles - no title info
-
-
-
The main dispatch_queue is a serial queue and cannot be re-entered, so we cannot start the QApplication there since it will block into a callback while servicing the main queue, and thus no more blocks will be able to be executed on this main dispatch_queue. By running the CFRunLoop instead, we don't have this serial execution constraint and can re-enter the loop while servicing the main dispatch queue from inside the QApplication runloop. Regression from 9cae3668 which introduced the dispatch call.
-
The main dispatch_queue is a serial queue and cannot be re-entered, so we cannot start the NSApp runloop there since it will block into the callback while servicing the main queue, and thus no more blocks will be able to be executed on this main dispatch_queue. It is visible with the callstack there: thread #1, queue = 'com.apple.main-thread' frame #0: 0x0000000183c3e1f4 libsystem_kernel.dylib`mach_msg2_trap + 8 frame #1: 0x0000000183c50b24 libsystem_kernel.dylib`mach_msg2_internal + 80 frame #2: 0x0000000183c46e34 libsystem_kernel.dylib`mach_msg_overwrite + 476 frame #3: 0x0000000183c3e578 libsystem_kernel.dylib`mach_msg + 24 frame #4: 0x0000000183d5e680 CoreFoundation`__CFRunLoopServiceMachPort + 160 frame #5: 0x0000000183d5cf44 CoreFoundation`__CFRunLoopRun + 1208 frame #6: 0x0000000183d5c434 CoreFoundation`CFRunLoopRunSpecific + 608 frame #7: 0x000000018e50019c HIToolbox`RunCurrentEventLoopInMode + 292 frame #8: 0x000000018e4fffd8 HIToolbox`ReceiveNextEventCommon + 648 frame #9: 0x000000018e4ffd30 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #10: 0x00000001875bbd68 AppKit`_DPSNextEvent + 660 frame #11: 0x0000000187db1808 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 frame #12: 0x00000001875af09c AppKit`-[NSApplication run] + 476 frame #13: 0x00000001030b791c libmacosx_plugin.dylib`__OpenIntf_block_invoke_2(.block_descriptor=<unavailable>) at VLCMain.m:166:17 [opt] frame #14: 0x0000000183acc750 libdispatch.dylib`_dispatch_call_block_and_release + 32 frame #15: 0x0000000183ace3e8 libdispatch.dylib`_dispatch_client_callout + 20 frame #16: 0x0000000183adcbb8 libdispatch.dylib`_dispatch_main_queue_drain + 988 frame #17: 0x0000000183adc7cc libdispatch.dylib`_dispatch_main_queue_callback_4CF + 44 frame #18: 0x0000000183d9fad4 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 frame #19: 0x0000000183d5d258 CoreFoundation`__CFRunLoopRun + 1996 frame #20: 0x0000000183d5c434 CoreFoundation`CFRunLoopRunSpecific + 608 frame #21: 0x0000000183dda45c CoreFoundation`CFRunLoopRun + 64 frame #22: 0x0000000100003084 vlc-osx-static`main(i_argc=1, ppsz_argv=0x000000016fdff0c8) at darwinvlc.m:309:9 [opt] frame #23: 0x00000001838f60e0 dyld`start + 2360 By running the CFRunLoop instead, we don't have this serial execution constraint and can re-enter the loop while servicing the main dispatch queue from inside the [NSApp run] runloop. It now has the following callstack when running: thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x0000000183c3e1f4 libsystem_kernel.dylib`mach_msg2_trap + 8 frame #1: 0x0000000183c50b24 libsystem_kernel.dylib`mach_msg2_internal + 80 frame #2: 0x0000000183c46e34 libsystem_kernel.dylib`mach_msg_overwrite + 476 frame #3: 0x0000000183c3e578 libsystem_kernel.dylib`mach_msg + 24 frame #4: 0x0000000183d5e680 CoreFoundation`__CFRunLoopServiceMachPort + 160 frame #5: 0x0000000183d5cf44 CoreFoundation`__CFRunLoopRun + 1208 frame #6: 0x0000000183d5c434 CoreFoundation`CFRunLoopRunSpecific + 608 frame #7: 0x000000018e50019c HIToolbox`RunCurrentEventLoopInMode + 292 frame #8: 0x000000018e4fffd8 HIToolbox`ReceiveNextEventCommon + 648 frame #9: 0x000000018e4ffd30 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #10: 0x00000001875bbd68 AppKit`_DPSNextEvent + 660 frame #11: 0x0000000187db1808 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 frame #12: 0x00000001875af09c AppKit`-[NSApplication run] + 476 frame #13: 0x00000001030b76c8 libmacosx_plugin.dylib`__OpenIntf_block_invoke(.block_descriptor=0x00006000038813c0) at VLCMain.m:166:13 [opt] frame #14: 0x0000000183d5e070 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 frame #15: 0x0000000183d5df84 CoreFoundation`__CFRunLoopDoBlocks + 356 frame #16: 0x0000000183d5d414 CoreFoundation`__CFRunLoopRun + 2440 frame #17: 0x0000000183d5c434 CoreFoundation`CFRunLoopRunSpecific + 608 frame #18: 0x0000000183dda45c CoreFoundation`CFRunLoopRun + 64 frame #19: 0x0000000100003084 vlc-osx-static`main(i_argc=1, ppsz_argv=0x000000016fdff0c8) at darwinvlc.m:309:9 [opt] frame #20: 0x00000001838f60e0 dyld`start + 2360 And now dispatch will correctly work inside this. Regression from 3a6bd45b which introduced the dispatch call and then changed also in 9cae3668 which also modified the dispatch call in the destructor. Fixes #28812 -
-
-
-
vlcrs-core is the crate that will be responsible for having the safe abstractions around the unsafe C functions and definitions.
-
- Oct 02, 2024
-
-
As we have the element content when inserting them in the library, so we can insert them "a priori" in our cache and update the interface before the medialibrary notifies us with the actual content ("a posteriori"). If assumption was wrong, diffutil will correct it -
-
-
- Oct 01, 2024
-
-
Signed-off-by:Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by: -
-
-
Signaling discontinuity had 2 purposes: - To handle seek requests, but it could not really work, hence the new on_seek() callback. - Signal when the player is paused or stopping Therefore, replace this event with on_paused().
-
To signal when the player seek.
-
The documentation will be updated in a future commit.
-
-
- Sep 30, 2024
-
-
-
-
-
-
A method listing all media indexed from the medialibrary was missing and was introduced in 0.13.1.
-
This release brings fixes to 0.13.0 and a small set of non-breaking changes. Medialibrary 0.13.1 new non breaking features: * Media manipulation in playlists can now be done in ranges (videolan/medialibrary!777) * All media can now be retrieved in a single request (videolan/medialibrary!773) Medialibrary 0.13.1 fixes: * Fixed a FS discover crash on Windows (videolan/medialibrary#483) Fixed * a startup crash for applications not implementing a cache worker (videolan/medialibrary!770) All the contrib patches have been included in this release.
-
This method requires the direct composition device in order to create the video visual. When this method is called, Qt might not have fully initialized the interface as scene graph initialization is done asynchronously. In this case, simply wait for the initialization to complete. If the initialization fails or takes too much time to complete, then fail by returning false. Co-authored-by:Pierre Lamot <pierre@videolabs.io>
-
Segments not starting with a sync point are legal in the HLS ref. However, using them as a seek point is hazardous. Warn the user that their stream might have issues fixable by adapting the encoding parameters.
-
This patch implements a best effort algorithm to try and start segments with an I-Frame. While optional in the RFC, this guarantees sane seeking points and no artifacts on the first connection of clients in the middle of the stream. Obviously, the input of the module should be a feed that has a GOP generally smaller than the requested segment size, otherwise, the algorithm will fall back to the old behavior and create a segment that isn't self decodable. This is still preparation work for the new Chromecast backend, in particular to support seeking in the exposed media window. Refs #27391
-
Allow multiple segments to be output by the same pass. This is mainly to handle parallel tracks that differ in segment sizes, if one has its muxer outputting very small segments against a track with the maximal segment size, the small segments must be output at a faster rate. This work is in preparation of the I-frame based segmentation where this behavior will likely exist.
-
Steve Lhomme authored
That may allow using regular Windows version checks that maxed out at Win 8.1. https://learn.microsoft.com/en-us/windows/win32/w8cookbook/windows-version-check#declaring-windows-10-compatibility-with-an-app-manifest
-
Steve Lhomme authored
It's supposed to be a better allocator than the default/legacy one [1]: The value SegmentHeap indicates that segment heap will be used. Segment heap is a modern heap implementation that will generally reduce your overall memory usage. This element is supported in Windows 10, version 2004 (build 19041) and later. On my usual test file (hardware decoding, dummy UI) I get from 266.1 Mo of memory usage to 264.4 Mo (-0.6%). The results are consistent between runs. [1] https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#heaptype
-
