Camera stream time synchronization

[ArtemM]

trafficstars

Is your feature request related to a problem? Please describe. I'm trying to stream feed from IP webcam to html page, though often video stream starts to fall into the past as per Input RTSP stream timing is fine (checked with vlc on the same machine). Local clock is fine (in sync with input stream). Browser does not buffer - checked both by evaluating in JS video.buffered.length (which is 0) and by reloading page (which obviously resets video buffer client-side). Most probably CPU can't handle stream server-side and application starts "buffering" output. That is totally reasonable behavior but not applicable for real-time monitoring - here it is reasonable to just "fast-forward" to the end of the stream skipping any video frames application was not able to process. Maybe there is any existing solution to instruct the application to stick with end of stream and skip missed parts?

Describe the solution you'd like Command line/configuration flag which instructs application to abandon any frames which not processed and move to the end of input.

Describe alternatives you've considered Initially tried to manage this with VLC sout, it works in the similar way in terms of described issue and I did not find a workable option to force frame abandonment so tried webrtc-streamer (which generally behaves significantly better by the way).

Additional context Not likely relevant but just in case here is output https://gist.github.com/ArtemM/d6bdbc134336cf05d1edf49f23bbecfb and command line

 docker run -p 8000:8000 -p 3478:3478 -it mpromonet/webrtc-streamer  "rtsp://admin:[email protected]:554" -T0.0.0.0:3478 -tturn:turn@$192.168.1.197:3478

[mpromonet]

Hi,

I will takes more time to read in details, but by default configuration use RTP over TCP, this in order to works with more stream, using RTP over UDP may improve this.

Increasing the log level should allow to understand if the VideoDecoder::DecoderThread queue in increasing (this should also makes the memory of the application to grow)

The turn external url seems strange turn:turn@$192.168.1.197:3478 should probably be turn:[email protected]:3478 but this is not impacting the streaming delay.

Best Regards, Michel.