PCR gap detection is not appropriate for streaming MPEG formats

src/input/clock.c currently detects PCR gaps only if the difference between two consecutive PCRs is greater than 22.222 seconds. This seems to be an empirical value - see [5000].

However, this has very bad sideeffects on network streaming. If the PCRs suddently jump e.g. 10 seconds, this change remains undetected and the reference clock gets invalid. The proper action in this case would be to immediately recompute the reference point.

MPEG-TS is required to have a PCR at least once per 100 msec and in case of RTP streams delivered by livedotcom, PCRs are computed from each RTP packet. So for these cases, 22.222 seconds is at least two orders of magnitude above the limit.

However, if other formats/containers need such high value, then perhaps cr_max_gap should be set apropriately by the demux and passed as parameter to clock.c functions.

It is also possible, that this high value is needed due to a bug somewhere else. For example, it seems suspect to me, that in case PCR gap is detected, the new reference point is not recomputed immediately, but only on next PCR arrival. During this time period, synchro state is SYNCHRO_START - meaning not valid.