[vlc-devel] [PATCH 00/17] Fixing normal_time handling
remi at remlab.net
Thu Mar 11 15:28:22 UTC 2021
Le jeudi 11 mars 2021, 12:49:36 EET Francois Cartegnie a écrit :
> Le 11/03/2021 à 11:38, Thomas Guillem a écrit :
> > Here, DEMUX_GET_NORMAL_TIME = DEMUX_GET_TIME - i_scr.
> > The i_scr is not known from Control(), so it needs to be saved in an
> > intermediate variable. And it will be the same for all modules.
> > I can do as you say, but I prefer my way. Francois, what do you think ?
> Doing such math is impossible.
> I've already mentioned that Time and PCR lives in totally different
That's not really saying anything; it depends what is understood by timeline,
In practice they move at the same speed, which is to say the playback rate,
There are just two differences:
- PCR is reported in discrete steps, whereas NPT is continuous. The clock has
to be interpolated/extrapolated between PCR steps.
- They have an offset, and that offset may punctually change, e.g. upon title or
And my point is that we should just report that offset (second bullet point)
from NPT to PCR whenever it changes.
And the thing still is that GET_TIME and GET_NORMAL_TIME are the same thing. I
don't see how the GUI and the playback API could handle it otherwise.
That is not to say that an input media cannot have more than one playback
timeline, e.g. chapter time, title time, disc time... But there can only be
one time exposed by the demuxer to the input.
More information about the vlc-devel