[vlc-devel] [PATCH v3 2/6] clock: add vlc_clock_main_SetInputDrift

[Thomas Guillem]

I agree this may not be the perfect solution, but it is a simple one that will avoid many regressions with livestreams.

To sum-up, this patch set switch back to the monotonic clock (so no master audio) if the access can't control the pace. In that case, the legacy input clock will send averaged drift update to the output clock. This drift won't be used by the master clock (since it's disabled at this point), but by all ES slaves (video, that will be displayed faster/slower, audio, that will be resampled).

Right now, I don't see any other solution. Even if there is a better solution, how long will it take to implement? Should we postpone it to VLC 5.0? Therefore, I suggest that we merge this patch set for VLC 4.0.

On Tue, Mar 16, 2021, at 09:36, Francois Cartegnie wrote:
> Le 15/03/2021 à 12:06, Denis Charmet a écrit :
> 
> >> -    return system + (clock->delay - main_clock->delay) * rate;
> >> +    return system + main_clock->input_drift +
> > 
> > You cannot do that. The whole point of the main clock is to be the 
> > reference used to calculate the different drifts of other clocks. The 
> > main clock cannot drift it's the monotonic clock if you start doing that 
> > you are basically going back to the PCR master of the previous versions.
> > 
> 
> That's how drift was handled before: Do an average and add it to clock 
> computation.
> 
> You can't accelerate playback on master/audio clock.
> You can't accelerate clock on the remote server.
> We don't want to reset clock each time we reach some limit.
> 
> Now that was removed we have both clocks drifting away and eventually 
> breaking up playback.
> 
> 
> -- 
> Francois Cartegnie
> VideoLAN - VLC Developer
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel