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

[Steve Lhomme]

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.