Clock synchro redesign

We need to adapt the clock synchro to work better with BOTH files and streams.

added Severity::major label

• When a buffer underrun occurs, clock should stop
  • it eases recovering
  • we don't loose any part of the clip
• Caching system should be improved
  • prebuffering threshold should change depending on caching value
  • when we pause, we should not keep playing until buffer are empty, but stop right away

added Difficulty::guru + 1 deleted label

changed milestone to %0.8.5-final

changed milestone to %Features paradize

Also there are some streams which play without single sychro warning through live.com input but produce continuous synchro problems via standard VLC input...

Perhaps we need to implement clock synchronization based on RTP timestamps?

Here is what happens:

main warning: audio drift is too big (121949), dropping buffer
main warning: resampling stopped after 7329301 usec (drift: -42755)
main warning: buffer is 40992 late, triggering upsampling
main warning: resampling stopped after 11681543 usec (drift: -12159)
main warning: buffer is 41406 late, triggering upsampling
main warning: resampling stopped after 3013031 usec (drift: 10287)
main warning: buffer is 41295 late, triggering upsampling
main warning: resampling stopped after 4237543 usec (drift: -24767)
main warning: buffer is 41518 late, triggering upsampling
main warning: resampling stopped after 4021932 usec (drift: 4351)
main warning: buffer is 40541 late, triggering upsampling
main warning: resampling stopped after 812689 usec (drift: -12016)
main warning: output date isn't PTS date, requesting resampling (63655)
main warning: buffer is 40452 late, triggering upsampling
main warning: timing screwed, stopping resampling
main warning: buffer is 65397 late, triggering upsampling
main warning: resampling stopped after 13625783 usec (drift: -4295)
main warning: output date isn't PTS date, requesting resampling (43687)
main warning: buffer is 40083 late, triggering upsampling
main warning: timing screwed, stopping resampling
main warning: buffer is 58007 late, triggering upsampling
main warning: resampling stopped after 4667434 usec (drift: -52786)
main warning: buffer is 50834 late, triggering upsampling
main warning: resampling stopped after 2631843 usec (drift: -38816)
main warning: buffer is 41778 late, triggering upsampling
main warning: resampling stopped after 1050067 usec (drift: -11205)

Indeed, there is a huge difference between RTP timestamps and packet arrival times for this stream (livecaster MP3 audio):

• RTP timestamps have constant difference of 7053 units of 90 kHz clock (approx. 78 msec)

• time gap between packets varies between 40 and 150 msec.

live.com input uses RTP timestamps to reconstruct the clock (works fine in this case)

But the standard vlc input does not use RTP timestamps and the clock sychro gets highly confused by the big jitter.

For RTP and UDP network streams, some of the clock synchro problems were solved in:

[13191] [13192] [13195] [13272]

• Handle all caching at stream level (access->demux) with a varying amount depending on muxrate ?
  • Allows to get rid of the 4MB cache per track
  • Eases pause and buffer underrun handling
  • Get rid of the "two-buffers-out-of-which-one-is-not-configurable" mess

changed milestone to %0.8.6

added Component::Core: Input label

added Type::task label

Bah ...

changed milestone to %Features paradize

I would like to add: http://forum.videolan.org/viewtopic.php?t=23896&highlight=

The recap:

• I realise that a PROPER fix for this requires a big rewrite and lots of work etc. But right now, VLC will often just stop playback with messages like 'late picture skipped (2688000)'.. waiting forever for the sync to catch up.

• My suggestion: just build some temporary fix that will reset the PCR, reboot vlc, or quit vlc (so the shell can restart it) if the desync hits some optional limit!

See my forum topic for more details/suggestions. Please guys, even a temp fix is worth implementing because:

• For serious use (a video stream server/transcoder you want to turn on and run forever) vlc is useless, it will just stop. You need someone to sit next to your server permanently and restart now and then!

• For normal users who just want to watch a video a 'hiccup' (freeze, continue) is annoying but acceptable. A permanent pause is not they will switch to a 'better' player.

• A lot of players (windows media, real, quicktime) also do the same, they just need to 'rebuffer' .. riight.

Replying to [comment:14 puntloos]:

I would like to add: http://forum.videolan.org/viewtopic.php?t=23896&highlight=

This is probably ticket #424 (closed)

It is possible that it is related, however Ive heard of more situations (not network-related, but DVD playback with a scratched DVD for example) where a very similar situation happens.

So I essentially would generalize this to:

• If the source is not perfect (enough) in some way, VLC sometimes stops decoding

• If VLC stops, it will idle forever

• If a source is 'bad' a user will often prefer a player that 'does its best, retries' over a player that 'gives up'.

added Difficulty::medium label and removed Difficulty::guru label

assigned to @fenrir

Also #424 (closed)