> So, does live555 support flow control?
I’m not sure exactly what you mean by this, but I think the answer is “no”.
The server transmits data at its natural rate - i.e., whenever it obtains it.
If your stream is exceeding the capacity of your network, then you need to
lower its bitrate a
Hi Ross,
Thanks for quickly response.
1. We are very sure the fPresentationTime are accurate.
We guess the video block issue. It will happen heavy video bitrate on low
upload bandwidth.
So, does live555 support flow control?
2. Yesterday, we set up a VGA@1fps MJPEG to do streaming.
It
> Thank you for your reply. I have one other question: what format should the
> back-end stream url be?
Whichever URL works for you! You can test this first with a regular RTSP
client application - like “testRTSPClient”, “openRTSP”, or “VLC”. Whichever
URL works with a RTSP client application
Hi Ross,
Thank you for your reply. I have one other question: what format should
the back-end stream url be? I guess, the
"http://192.168.1.201/axis-cgi/alwaysmulti.sdp?camera=1"; is not correct?
I expect something like "rtp://239.238.62.24:5" or am I wrong?
Best regards,
Frank van Eijk
> Now, we use H264VideoStreamDiscreteFramer to do live streaming, it is better
> than before.
> And we sure the timestamp is correct and sync with “wall clock time”.
> But, we still have some questions, need your help.
> 1. Now, H264+AAC is working well.
> After playing about 3 hours, audio is
I assume that you are referring to the proxy server’s ‘back-end’ stream
(because the ‘front-end’ streams are always unicast).
The proxy server can access ‘back-end’ multicast streams in exactly the same
way as ‘back-end’ unicast streams - i.e., using the same API.
You can verify this by running
