Subscriber A/V synchronization fails in a live stream that is stopped and re-published.

[Andy--S]

When a publisher closes, reconnects and republishes, subscribers that remain connected will lose stream A/V synchronization. Synchronization will will resume after a measured amount of time.

Initially the subscriber will have synchronization. When the publisher stops, the subscriber stream buffer plays out as expected.

Lets call that 'segment_1'. The netstream time shows the duration of segment_1.

The publisher reconnects and begins to re-stream. The subscriber begins to receive 'segment _2'.

Synchronization will be bad for subscriber-X until the new segment_2 duration exceeds segment_1 duration.

I was able to get the client buffer to accept the clear ping, but I was not able to reliably clear pending messages. This means 1 in 3 re-published streams the client netstream time went back to zero, but immediately returned to the end value of segment-1.

Reproduction steps

1. Publish a stream to any application.

2. Subscribed to that stream with a flash client. Watch the stream for 20 seconds.

3. Stop publishing the stream, but keep the subscriber connected.

4. Publish the stream again and speak into the mic while facing the camera and simultaneously watching the subscriber stream. Do so for more than 20 seconds.

5. Observe the synchronization will be broken until 20 seconds have passed.

[Andy--S]

Correction: the player swf flash var for stream name is 'stream' .swf?stream={}&host={}&app={}

[mondain]

First mod comitted https://github.com/Red5/red5-server-common/commit/148c90186bf555cca79c02b756f26ead85d46712

[mondain]

This may have been a product of the bad or less than to-spec rtmp encoder/decoder