[vlc-devel] [PATCH 3/6] clock: add vlc_clock_SetDecoderLatency

[Thomas Guillem]

On Thu, Oct 3, 2019, at 14:39, Rémi Denis-Courmont wrote:
> Even a "moderate" increase in latency can break audio playback due to permanently too late buffers. 
Then, we could add a max gap that will be equals to the network-cache. So we will know that this latency has already been tested.

> 
> 
> And this will either do nothing or break in the case of dynamic (e.g. TS), dynamically enabled (e.g. multiple audio tracks), or irregular (e.g. voice codec) ES.

No, I already explained, this will do nothing for these cases, and not break it.

> 
> Le 3 octobre 2019 15:01:05 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>> 
>> On Thu, Oct 3, 2019, at 13:49, Rémi Denis-Courmont wrote:
>>> As far as I can tell, this makes broken assumptions that will break playback in some cases.
>> 
>> Could you be more precise ? When will it break playback ? Which assumption is broken ?
>> 
>> In the worst case scenario, avcodec will continue anyway even if the latency induced by the threads is not handled.
>> In better case, avcodec will redure its number of threads.
>> In most common case, the input delay will be lightly increased.
>> 
>>> 
>>> Le 3 octobre 2019 10:37:52 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>>>> Any last words ?
>>>> 
>>>> On Tue, Oct 1, 2019, at 14:33, Thomas Guillem wrote:
>>>> > 
>>>>> 
>>>>> On Mon, Sep 30, 2019, at 21:52, Rémi Denis-Courmont wrote:
>>>>>> Le torstaina 26. syyskuuta 2019, 17.38.11 EEST Thomas Guillem a écrit :
>>>>>>> The highest decoder latency of all clocks will be used to setup the initial
>>>>>>> dejitter delay.
>>>>>> We cannot generally, or even usually, measure the decoder latency.
>>>>> I agree, but we the avcodec module can guess it, according to its 
>>>>> thread_count and fps. It's not perfect but it's sufficient to fix all 
>>>>> problems we have with low fps samples (when you have a CPU with lot of 
>>>>> cores).
>>>>> 
>>>>>> On top of that, even if we could measure it, it does not even seem to mean 
>>>>>> anything if the set of active ES changes, or if for any reason the ES are not 
>>>>>> in sync (input slaves, multiple RTP sessions, etc).
>>>>> Yes, this is why this function can fail. vlc_clock_SetDecoderLatency() 
>>>>> won't be able to handle a big delay ( > 300ms = file-caching) if a 
>>>>> video track is enabled midstream. Everything is handled in avcodec:
>>>>> cf. 
>>>>> https://code.videolan.org/tguillem/vlc/commit/38206d600fe2eba78a72cc4b19749db087b6a408
>>>>> 
>>>>> This is not a perfect solution but it will fix most issues we have with 
>>>>> normal media samples (video starting near the audio).
>>>>> 
>>>>>> -- 
>>>>>> レミ・デニ-クールモン
>>>>>> http://www.remlab.net/vlc-devel mailing list
>>>>>> To unsubscribe or modify your subscription options:
>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>> vlc-devel mailing list
>>>>> To unsubscribe or modify your subscription options:
>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>> vlc-devel mailing list
>>>> To unsubscribe or modify your subscription options:
>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>> 
>>> -- 
>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
>>> _______________________________________________
>>> vlc-devel mailing list
>>> To unsubscribe or modify your subscription options:
>>> https://mailman.videolan.org/listinfo/vlc-devel
>> 
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191003/e03fabc8/attachment.html>