[vlc-devel] [RFC PATCH 09/13] FIXUP: implement audio/video/spu delay

[Denis Charmet]

On 2018-06-29 20:15, Rémi Denis-Courmont wrote:
>> Large delay is an issue that VLC always had and that is not fixed by
>> this set of patches. But I though  we would handle that case when we
>> replace the input clock / buffering, no ?
> 
> And for that to work, you need to correct the PTS before buffering.

Why not then just adjust the buffering without changing the PTS.

The main advantage to editing PTSes before decoding is that you can 
pass that to a sout and keep the delays. And that would be a really nice 
feature to have.

Now the issue is that, as Thomas said is that most of the hw decoders 
with which I've workded, do care about PTS to compute their own 
discontinuities/hurryup and other internal magics.

Do we apply said delays to dts?

And we need a way to let the clock know that a delay was introduced or 
I expect slope calculation errors. Having the clock handling that is the 
most robust way we found. I can't remember why we dropped the PTS 
changes to push it back to the clock.

I'll try that in the following days and see if I can come up with 
something that would work.

Regards,
-- 
Denis Charmet - TypX
Le mauvais esprit est un art de vivre