> You may want to simply turn off b-frames at 1fps to reduce the latency.
> Two b-frames between i/p frames will introduce a latency of around
> 3 seconds at 1 fps no matter how much you optimize at the encoder.
OTOH, making every frame a key frame will significantly increase the stream’s
bit rat
Also:
> I assume the registerStream user password should be NULL, even though our
> streams require a user password.
Err, no. If the RTSP stream (the one that you are calling “REGISTER” for)
requires a username+password, then you need to pass those strings as parameters
to your call to “regis
Your problem is that you are trying to REGISTER a stream that the WebRTC server
cannot access.
What you are trying to do will work, ***provided that*** it is the back-end
RTSP server itself - *not* a third-party - that sends the “REGISTER” request,
and that it does so requesting streaming over
Hi Patrick,
On 13.04.2017 21:22, Weber, Patrick wrote:
note that encoding is going to create some latency
that might not be noticed in 30fps applications, but when dealing with
1Hz frame rates a lag of two or three frames is very apparent!
You may want to simply turn off b-frames at 1fps to re
Error: Inaccessible or unsupported back-end RTSP stream.
I believe I have implemented the registerStream. I followed the example on the
site.
We have a custom proxy (based on the proxy example). It works well for us, I
added the code to registerStream and also changed to using the
RTSPServ
> Just a quick follow-up to let you know that live555 works quite well
> distributing low frame-rate high resolution video. My application gets bitmap
> images from a panoramic camera at a frequency of between 1 and 4 frames per
> second. I convert these to RBG24 “frames”, pass them into the FFM
Just a quick follow-up to let you know that live555 works quite well
distributing low frame-rate high resolution video. My application gets bitmap
images from a panoramic camera at a frequency of between 1 and 4 frames per
second. I convert these to RBG24 "frames", pass them into the FFMPEG enco
> The key point is server side always use same port to handle RTP/RTCP packet.
That’s not true at all. If multiple (unicast) clients access a RTSP server,
then the server will use different RTP/RTCP port pairs for each.
You must therefore have modified the supplied code, and can therefore expec
Hi Ross
Thanks for your reply.
After past few days struggling, I think we found the key point.
The key point is server side always use same port to handle RTP/RTCP packet.
Transport:
RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=46774-46775;server_port=6970-6971
Server alw
