[vlc-devel] [RFC PATCH 0/9] Fixing A/V dejitter with high latency devices

Steve Lhomme robux4 at ycbcr.xyz
Fri Dec 11 10:54:25 CET 2020

On 2020-12-11 10:37, Thomas Guillem wrote:
> On Fri, Dec 11, 2020, at 10:20, Steve Lhomme wrote:
>> On 2020-12-10 20:14, Thomas Guillem wrote:
>>> On Thu, Dec 10, 2020, at 18:35, Francois Cartegnie wrote:
>>>> Le 10/12/2020 à 18:10, Thomas Guillem a écrit :
>>>>> 2/ Add a callback to the master clock that will fetch the aout delay.
>>>>> This callback could be triggered by the vout before displaying a frame.
>>>> That means trigger condition is generally when converting the first non
>>>> master stream timestamp ?
>>> Indeed, so if the vout is early (audio not ready), the time_get() callback won't return a valid delay and the vout will use the monotonic clock. Then it will wait for the frame display time with vlc_clock_Wait(). This waiting function should take care of polling the last delay before returning.
>> Shouldn't it just return INT64_MAX (which should have a proper
>> name/define) ? In that case the vout considers it's paused.
> And when there is no audio?

Isn't the master clock different in that case ?

>> IMO, contrary to what is done now, the first frame should not be
>> displayed ASAP but when its time has come. A file could start with 5s of
>> audio and then the video starts. There's no reason the first frame
>> should be shown when the source intentionally didn't have something to
>> display.
> I agree but I think it is independent of this patch set.

If the goal is to avoid frame drops at the beginning, maybe not.

More information about the vlc-devel mailing list