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

Rémi Denis-Courmont remi at remlab.net
Thu Oct 3 14:39:49 CEST 2019


Even a "moderate" increase in latency can break audio playback due to permanently too late buffers. 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.

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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191003/7474c6f0/attachment.html>


More information about the vlc-devel mailing list