Draft: Clock context to handle PTS/PCR discontinuity

Cf. discussion during Workshop 2021-12-06/07 #26378 (closed)

The issue

The goal is to keep the data related to the PTS as long as possible inside the playback workflow. To do that, the clock internal state needs to be kept through the whole pipeline, and not scratched synchronously.

As an example scenario: during a media player playback:

• a change in the clock (discontinuity) is performed
• currently, the clock internal state is reset, so every picture that has been decoded and not displayed has now an invalid PTS (because the PTS cannot be converted to the system time anymore). So they are discarded, or the output might wait a huge amount of time before displaying them (depending if the new PTS increase or decrease)
• however, if we could keep the current state for these pictures (and not for the future ones), we could be able to display them.

Sample with a PCR discontinuity: https://streams.videolan.org/issues/26378/intentional_pcr_discontinuity-short.ts

The solution

The es_out can trigger the creation of a new clock_context via vlc_clock_main_SetFirstPCR. For now, it is only triggered when the input_clock detect a discontinuity, but we could also let demux modules send a new es_out control to trigger it.

The clock_id will be propagated from the main clock owned by the es_out to the output modules, held by block_t or picture_t , and passed from packetizers to decoders to filters to outputs

TODO

It's a draft, if the solution is accepted, I will have to :

• Fix all decoders to forward the clock_id
• Fix all packetizers to forward the clock_id
• Handle clock_id in subpicture_t and spu renderer
• Fix some aout modules to send PTS directly from aout_TimingReport (and not a ts based on 0)
• Fix some aout modules to send the clock_id from aout_TimingReport