input: es_out: reset buffering on PCR discontinuity

When PCR discontinuities happens, the whole pipeline is reset and it safely (though after a glitch) reset back to playback on what's visible after the PCR discontinuities, and restart buffering.

However, this PCR discontinuity currently happens only when not in buffering. When it happens during buffering, then:

• either the PCR value is much bigger than expected, and buffering will stop sooner than expected.

    | Buffer start      Buffer end    New PCR
    | v                          v    v
    | |------.-------------------|    |
    |        ^
    | Old PCR  |----------------------|
    |             Missing buffering
    +-- Resulting buffer after PCR jump to the future.

• or the PCR value is much smaller than expected, and the buffering is completely borked, the computed stream buffer duration is negative and it would buffer for the time of the

    | New PCR         Buffer start     Buffer  end
    | v               v                          v
    | |---------------|------.-------------------|
    |                        ^
    |                 Old PCR
    |
    |              Total buffering:
    |
    |  Buffering after the PCR jump
    | |------------------------------------------|
    |                    +
    |                 |------|
    |                 Previous additional buffering
    |
    +-- Resulting buffer after PCR jump to the past.

The second behaviour can be visible when disabling the __MAX for the caching progress value, leading to logs like:

[000055df326370e0] main input debug: Buffering 0%
[000055df326370e0] main input debug: Buffering 1%
[000055df326370e0] main input debug: Buffering 2%
[000055df326370e0] main input debug: Buffering 3%
[000055df326370e0] main input debug: Buffering 4%
[000055df326370e0] main input debug: Buffering 5%
[000055df326370e0] main input debug: Buffering 6%
[000055df326370e0] main input debug: Buffering 7%
[000055df326370e0] main input debug: Buffering -99%
[000055df326370e0] main input debug: Buffering -98%
...

Such scenario can be created by streaming a .ts file with the option --ts-trust-pcr on udp://127.0.0.1:1234 for instance, while running ffmpeg with:

ffmpeg -re -i input_file.ts -f mpegts udp://127.0.0.1:1234

During buffering, interrupt and restart the ffmpeg streaming command. The value in --network-caching can also be increase to ensure easier reproduction of the scenario.

Example of input PCR:

Instead, if PCR is going back to the past, flush the pipeline and reset the buffering back to zero to avoid waiting for the stream to catch-up with the old reference, and avoid buffering more than what we requested, which would shift the playback more from the live.

| - Step 1:
| New PCR         Buffer start     Buffer  end
| v               v                          v
| |---------------|------.-------------------|
|                        ^
|                 Old PCR
|
| - Step 2:
|                 Previous buffering is dropped.
|                 |------|
| |--------------------------|
| ^                          ^
| New PCR                    New buffer end
|
|
+-- New buffering behaviour when PCR jumps to the past.

Additional note: The goal in this MR is not to be able to play such files without issues and handling those discontinuities asynchronously to play the current buffer without issues, but only to prevent creating more issues than necessary with such input.