- Apr 14, 2025
-
-
Tristan Matthews authored- Bug Fixes * b:396169342: Assertion `av1_is_subpelmv_in_range(&ms_params.mv_limits, start_mv)' failed. * b:401671154: typo in void init_src_params(...) * Coverity defect 323670: Uninitialized scalar variable in encode_with_and_without_superres() * cmake: bump minimum version to 3.16 * cfl_ppc: fix subtract_average_vsx * Fix an incorrect index in av1_highbd_pixel_proj_error_neon -
The handling through GCD was added back then in commit cc07bce0. In that commit, signal(SIGCHLD, SIG_DFL) was already called to ensure the behavior of the signal is restored to default handlers. In `man 3 signal` from the macos manual, it is said that when setting SIG_IGN for SIGCHLD, the operating system will not create zombie process and the exit status will be ignored. We do want to avoid creating zombie process but we also want to have exit status, which means we do indeed need the SIG_DFL handler here. See also the following commit on the linux side: 94763831. However, GCD was used to automatically call waitpid() on the process that are being signalled as closing. Since we're always calling waitpid when spawning any process, this duplicates the handling. But the clients are actually using vlc_waitpid which is checking errno != ECHILD, so it would break as soon as the GCD handler is executed before...
-
- Apr 13, 2025
-
-
Signed-off-by:Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by: -
macosx: Use the acquire/return video view methods in PIP implementation in VLCMainVideoViewController Signed-off-by: -
macosx: Add method to acquire and return the vout containing view from the main video view controller Signed-off-by:
-
- Apr 12, 2025
-
-
Signed-off-by: -
macosx: Ensure the displaying of the fake title bar gets updated when going into fullscreen even if we disable library controls Signed-off-by: -
This prioritize using the start_time path if start_time has been defined regardless of whether vlc_clock_SetFirstPcr has been called or not, instead of using the first_pcr path as long as first_pcr has been defined.
-
The conversion function might not have wait_sync_ref defined in the next steps as it won't generate the wait_sync_ref itself, but choosing the start_date requires transforming the current point. The assertion on wait_sync_ref is removed given that it would be NULL when using start_time. Co-authored-by:Thomas Guillem <thomas@gllm.fr>
-
Clock must now be started from a dedicated input vlc_clock. The start is not yet mandatory but is available and will be mandatory after next patches. Previously, the clock was driven by two values: coeff and offset. The idea was that since the clock is supposed to look like an affine line, we could extrapolate any `ts` media point into `ts * coeff + offset` in system time. It meant that offset could take any value depending on the difference between system time and media time, reducing the interpretability of the values. After this patch, offset is computed from the start of the stream in the test, so it will basically only include the difference between the timestamp computation and the real clock. Co-authored-by: -
DecoderWaitUnblock is waiting for the vlc_input_decoder_StopWait which will be called by the es_out when every decoders are ready to start playing. When DecoderWaitUnblock is called and almost ready to return, it means that we already have a frame in the output and that playback has started. We can compute the monotonic start by calling vlc_clock_Start. Some care must be taken given that other reasons might unblock the decoders, like flushing or closing the decoder. Currently, vlc_clock_Start() does nothing as long as we didn't start the input vlc_clock_t also, but all of the code will be enabled after. Co-authored-by: -
Not buffered can happen if a decoder output a first frame late (after buffering)
-
This fixes a lipsync issue when a context is created from the beginning of the stream.
-
Ensure that every clocks (even input) has a valid clock_context, and specifically select them during vlc_clock_Start(), and un-select them during vlc_clock_Reset(). The previous mode is still present in the code to avoid breaking the current code until all the necessary changes are introduced, and is selected by whether the main_clock->first_pcr value has been set or not. Now that vlc_clock_main_Reset() is not called anymore at this location, the points registered from the input when it is driving the clock bus will not be removed. /!\ As a consequence, --clock-master=input now starts from the input /!\ clock points instead of starting from a monotonic clock point. This indirectly fixes an issue where the output_dejitter is accounted in computing the wait_sync_ref date, but also making all the outputs late compared to the input clock, leading to "Deferring start" messages from the audio output, and then "Starting late" message. Co-authored-by: -
No functional changes for now. The function will be implemented differently for the input vlc_clock, so that it always a source of new clock context, while the reset of the output clocks will allow selecting a newer clock context insteand.
-
vlc_clock_main_Reset() breaks the information inside clock context and it makes tracking the context switching harder. By using the clock-specific reset function, we'll be able to setup the behaviour of the input clock being reset and handle the creation of a new context instead.
-
wait_sync_ref should not be reset when resetting a derived clock. The clock bus should instead accept multiple possible time and choose the best start time for the given context, and reset() should only allow the clock to switch context. Co-authored-by: -
We want every outputs to update their points, but they might be forced (like the first video picture). Since a valid update follow a convert, we prefer to only create wait_sync_ref from convert. This will be clear with the upcoming vlc_clock_Start rework (the wait_sync_ref point will be always created from this upcoming function). Co-authored-by:Alexandre Janniaux <ajanni@videolabs.io>
-
The initialization of the clock was missing in the test, which was not an issue before but will be in the next commits.
-
Previously, calling vlc_clock_ConvertToSystem was the only way to initialize the monotonic wait_sync_ref point which will be used to start the outputs. The rationale for that is written in commit: commit 491b48a6 Author: Thomas Guillem <thomas@gllm.fr> Date: Thu Oct 10 17:25:51 2019 +0200 clock: fix false start with some SPU tracks Reminder of the design: Any calls to vlc_clock_ConvertToSystem() or vlc_clock_Update() will create the reference point (wait_sync_ref) if it is the first call of all sub clocks. This point will be used as a reference by all clocks until the master does its first vlc_clock_Update(). Creating a reference point from vlc_clock_ConvertToSystem() can be discussed. You don't expect to modify the main_clock from a function with such name ("convert"). The pro of this design is that vlc_clock_ConvertToSystem() can't fail and will always return a valid point. Returning a valid point is mandatory for the actual design, let's see how the audio output is using it: The aout will first call vlc_clock_ConvertToSystem(ts) to get the first system date of the ts, this first system date will take into account the output dejitter, the input dejitter and the pcr_delay int and will be very likely in the future. Enough in the future to wait for any other tracks. When this system date is reached by the aout plugin, the aout will call the first update() and will drive all other clocks. ... Nowadays, two startup modes can be highlighted for the clock: - Either the input clock drives the clock bus and we have a reference point from the start of the stream in the next patches, so we don't use the monotonic start to setup the first clock points. - Or one of the outputs will drive the clock bus and we setup the first time conversion for those output depending on the input start, the clock priorities (added in 491b48a6). In the second point, it can only happen at the beginning of the elementary stream, or after a proper flush/seek. By calling a vlc_clock_Start function instead, we make it clearer that some setup will be done, and we can log those points to trace the startup conditions. The code is extracted from the current vlc_clock_ConvertToSystem startup mechanism but has been heavily documented to replace the "Fixup: remove" comment. Co-authored-by: -
The test is extending the current clock.c test but is specifically designed to check the clock startup scenarios. Those tests are also matching with the "SCENARIO_RUN" case in the clock.c test. It doesn't need the tracer infrastructure to run. Co-authored-by: -
Previously, the clock was driven by two values: coeff and offset. The idea was that since the clock is supposed to look like an affine line, we could extrapolate any `ts` media point into `ts * coeff + offset` in system time. It meant that offset could take any value depending on the difference between system time and media time, reducing the interpretability of the values. After this patch, offset is computed from the start of the stream, so it will basically only include the difference between the timestamp computation and the real clock. Co-authored-by: -
...instead of VLC_TICK_INVALID. Drift is a time difference and a reference clock is never drifting.
-
Offset is a time difference, so it should really be initialized to 0 and not VLC_TICK_INVALID.
-
Resetting the main_clock breaks the clock context information, especially regarding startup and monotonic synchronization. We only want to reset the coefficient to 1.f, and recompute the offset accordingly.
-
This commit creates a new way in the clock system to intercept the behaviour of the "startup" depending on whether the clock is for the input or the output and whether it's a reference clock or a derived one. Allowing to specify this behaviour contributes to unify the usage of the clock, so that it's easier to use in the future (think start() with the current time and startup PCR as planned vs SetFirstPCR() with a corrected startup time and the last PCR received). It also contributes to improve the cases where the input is a reference clock and paced by the source. The es_out is handling the current startup sequence for the clock by resetting the clock, shifting the input clock and setting the startup time again. Those functions are mixing three different components and behaviour and makes it hard to test the startup scenarios. vlc_clock_Start() on the input vlc_clock_t will replace those calls by providing the correct offset on the output points instead of transforming the input points. In addition, vlc_clock_Start() will be provided to the output clocks so that they can provide the wait_sync reference point, instead of relying on the first conversion done, and specify the exact startup time for the output clocks by computing the additional delay at the moment the playback really starts. Like first_pcr, start_time must be shifted when pause is set. It would also be possible to "reset" the start_time when un-pausing to the un-pause date. Note that this commit doesn't change the behaviour yet, and the consequences it brings will be seen when SetFirstPCR is effectively removed. Current case coverage is also quite low in tests, so failures would happen without SetFirstPCR in a random way. Co-authored-by: -
We'll be changing the way the offset is computed, and reproduce the computation at multiple locations. Factoring the computation in a function will allow to simplify the rest of the changes.
-
Currently, the main clock is reset once the new buffering is done. This buffering step will happen at the following locations: - at the beginning of a playback - when a seek is triggered by the user - when the demux needs to trigger RESET_PCR But the input clock was already reset at this location and will start to provide new points. Resetting the clock there as well as when the buffering is done currently changes nothing because we either have already flushed everything (seek or RESET_PCR) or we are not running through a clock (frame-by-frame mode). However, future patches will remove the clock reset at the end of the buffering and expect the clock to be already reset, to introduce a start function for the clock. Co-authored-by: -
Logging to stdout makes weird log interlacing with console logger which outputs to stderr, and makes it less easy to track synchronize in the test log file.
-
The delay is added to specify some margin for the start but we actually want to register the real startup date, since it will be accounted to startup the monotonic clock and prepare the playback offset from the input clock. Co-authored-by: -
-
Using 100 ticks instead of 1 tick allows differentiating off-by-VLC_TICK_0 errors from pause not working correctly.
-
The input vlc_clock will be used to define start_date for the playback timeline, when vlc_clock_Start() operation will be introduced.
-
Make sure the start date is always defined for CLOCK_SCENARIO_RUN tests so that the proper first PCR is defined.
-
-
Converted recursive implementation to an iterative one to prevent stack overflows from deeply nested calls. This enhances stability and ensures safer execution for long sequences.
-
Signed-off by: Ash <ashutoshv191@gmail.com>
-
-
- Apr 11, 2025
-
-
In the default config, audio packets are 40ms long and video is 25/1 frame per seconds, so frames are displayed every 40ms. When changing framerate to 50/1, everything still works correctly and the DemuxVideo call will generate two frames for one audio packet, and the sys->clock accumulator will move forward 40ms too. However, when using any frame rate value that would make 40ms not divisible by the video frame duration, eg. 60/1fps which is a period of 16.666ms, then the video would drift apart from the other tracks. Symmetrically, when using any frame rate value < 25/1 that would not be divisible by 40ms, the audio would drift apart from the other tracks. It came from the fact that video and audio were allowed to move forward the same amount starting from their previous pts value, which is not the same starting point for each track in case the divisibility condition is not met. The following graph represents the situation by drawing the two tracks with different origins to show how the video makes more progress than the audio in the case audio has 40ms packet and video is 60/1fps. PTS video ^ audio * --+ | * / | We go further than the | / * | audio track here. But | / / | we'll continue sending | / * --+ packets by group of 3. | / / | * * | / / | / * | / / | / * | * / | / * --+ | / / | This shows we can generate three | / * | video packet for each audio | / / | packet in the current state. | * * --+ | / / +---------------------------------------->ts By keeping the track-specific start point, we don't miss any value, and by setting the maximum date from sys->clock instead of the track-specific start point, we ensure we don't send more packets than wanted. Fix #29122
-
