External process preparsing is not available on Android and iOS-derived
platforms (iOS, tvOS, watchOS, visionOS) as spawning external processes
is either restricted or impractical on these platforms.
Use the internal (in-process) preparser instead.
VLC_PKG_LIBEXEC_DIR is truncated, leading to failure to find binaries
from LIBEXEC, and thus Qt interface not starting.
[255/2305] Compiling C object src/libvlccore.so.9.0.0.p/posix_dirs.c.o
../src/posix/dirs.c: In function ‘config_GetSysPath’:
../src/posix/dirs.c:53:33: warning: initializer-string for array of ‘char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (17 chars into 16 available) [-Wunterminated-string-initialization]
53 | [VLC_PKG_LIBEXEC_DIR] = "VLC_LIBEXEC_PATH",
| ^~~~~~~~~~~~~~~~~~
Co-authored-by: Fatih Uzunoglu <fuzun54@outlook.com>
Fatih found the root cause and reported it after Gabriel signalled he
couldn't launch the UI anymore.
Regression from e23555302f.
Oss-fuzz 6290126878867456 highlights a possible integer overflow in
video_format_IsSimilar.
The i_sar_num and i_sar_den are stored as 32 bit unsigned integers
(unsigned int).
The multiplication of theses two terms can exceed the maximum value of a
signed 64-bit integer.
The maximal possible value UINT32_MAX * UINT32_MAX fits in an unsigned
64 bit integer.
Tackles https://code.videolan.org/videolan/vlc/-/issues/29562
std::from_utf8 is from std.
See https://doc.rust-lang.org/std/str/fn.from_utf8.html
error[E0599]: no function or associated item named `from_utf8` found for type `str` in the current scope
--> src/rust/vlcrs-core/src/convert.rs:62:18
|
62 | str::from_utf8(self.to_bytes()).expect("Unexpected invalid UTF8 coming from VLC")
| ^^^^^^^^^ function or associated item not found in `str`
|
help: you are looking for the module in `std`, not the primitive type
|
62 | std::str::from_utf8(self.to_bytes()).expect("Unexpected invalid UTF8 coming from VLC")
| +++++
Fix the following warning by making the elided lifetime explicit
in the return type:
warning: hiding a lifetime that's elided elsewhere is confusing
--> src/rust/vlcrs-core/src/tracer/mod.rs:243:20
|
243 | pub fn entries(&self) -> TraceIterator {
| ^^^^^ ^^^^^^^^^^^^^ the same lifetime is hidden here
| |
| the lifetime is elided here
|
= help: the same lifetime is referred to in inconsistent ways,
making the signature confusing
To be able to declare modules unconditionally, declare the rust
dependencies and state variables that will be used when declaring
modules, without executing the commands that depend on Rust.
In short, this allows using the enabled: flag instead of conditionally
defining the module under an if get_option('rust').allowed() block.
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
Most of the code was written by Loïc and extracted from his original
merge request, but those snippets were not merged upstream. The code was
extracted to a separate meson build definition.
The added extension addition allows ensuring the built artifact matches
with what cargo will build. Since it's a proc-macro crate, it will build
a plugin for the compiler, which is a dynamic library of the building
platform.
The plugin itself is not used currently, but this allows checking that
the proc_macro builds correctly.
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
Most of the code was written by Loïc and extracted from his original
merge request, but those snippets were not merged upstream. The code was
extracted to a separate meson build definition.
Those definitions were finally added in modules/ here when the whole
infrastructure was thought to be going into the modules/ folder, but now
that it's in the src/rust/ folder, the definition there is better to
have the core crates use the same definitions.
If the input source send a ts, that is not updated (because audio or
video have higher priority), don't store it in last_ts.
Fix video ts being updated 2 times when the same picture was displayed more
than one time.
2/2 to fix spurious player pause test fail:
```
test_src_player_pause: ../../test/src/player/pause.c:97: test_pause: Assertion `paused_time == new_paused_time' fail
```
This could happen after few seconds when running 100 pause tests in
parallel and with heavy CPU load
1/2 to fix spurious player pause test fail:
```
test_src_player_pause: ../../test/src/player/pause.c:97: test_pause: Assertion `paused_time == new_paused_time' failed.
```
This could happen after few seconds when running 100 pause tests in
parallel and with heavy CPU load
* Add a new backend to preform preparsing by sending preparser request
to an external process and wait for the preparsed media in a
preparser responce format.
* Use the new preparser with external process inside the playlist and
the medialib thumbnailer.
* Create a preparser IPC (preparser request and response) to send
preparser requests to another process and receive the preparsed
media in return.
* Implement a de/serialization module capable of serializing and
deserializing preparser messages (requests and responses).
* Create a function to Update input item from an other one. This function
updates the value: `psz_name`, `psz_uri`, `i_duration`, `es_vec` and
`p_meta`.
If vout_Request() fails, the clock is destroyed. However, the code
continued to assign the freed clock pointer to owner_sys->clock.
This patch adds an early return on failure to prevent the use-after-free
and ensures owner_sys members are only updated on success.
Fixes#29371
Signed-off-by: Abderhman Gamal <abderhmangamal246@gmail.com>
ea93b2c847 is working by luck.
vlc_input_decoder_IsEmpty() should not be used to know if the input need
more buffering, it might return false when the fifo is empty and when
the vout has few pictures. In the unlikely case where the vout has fewer
pictures than the number of frame-next request (only when sending
requests in a burst via API, and not by hotkeys), it will keep returning
false, not triggering the buffering when it needed.
Furthermore, when paused, if ES_OUT_PRIV_GET_BUFFERING return false, the
input_thread_t will wait undefinitely (only wake by a new request).
This commit introduces a workaround, that is not cleaner than the
previous one, reinventing buffering when we decided to postpone it, but
it is only done for the next-frame usage and works reliably (cf.
unit-tests).
Really fixes#28145Fixes#29487
This will allow the frames_countdown variable to match with the actual
number of frame-next requests.
Indeed, this variable was incremented, regardless of the number of
pictures ready to be displayed by the vout (just decoded).
This was resulting in a buffering gap: If there were 20 frames on the
paused vout, the same amount of pictures was kept ahead for all future
frame-next requests because of the frames_countdown increase. Because of
that, it was also impossible to know when we reached EOF on next-frame.
Furthermore, this commit is needed for the new and future next-frame
buffering workaround as it allows finer buffering (ask buffering only
when needed, and not 20 frames in advance).
Refs #29487
Alexandre Janniaux
Steve Lhomme
Gabriel Lafond-Thenaille
Mathias APARICIO
Rémi Denis-Courmont
Loïc Branstett
KO Myung-Hun
Pierre Lamot
Thomas Guillem
Ayush Dey
Abderhman Gamal