i have a project where I am trying to reduce the latency on my current set up, which is leading to a bit of a rewrite. This project uses 3.6.1.
Currently, I am streaming 6x RTMP streams from an Avercaster encoder in one location, across the WAN to the WOWZA server at another location. From here, it publishes RTSP streams to Amino A140's on the LAN. It is working great, but there is a latency of 3-4 secs. i need this stream to be as close to live as possible 200-400ms would be acceptable. I should note, that i have tried all the Low-latency and buffer suggestions with this set up up to this point. The encoder manufacturer ensures me that that it will encode SD video at 200ms and HD video at around 2000ms. I am having difficulty proving this, so taking their word for it, i am assuming that the transcoding from RTMP to RTSP is making up the rest of the delay (allowing for a little delay accross the WAN - although it needs to be pointed out that this connection has been tuned to perform this task with a heavily configured static route from point to point, ping time is around 60ms).
So I am toying with the idea of encoding SD instead of HD via RTMP. This initial testing seems to have shaved a second or so off the time, however i am testing this with a return connection across the WAN with the lowest priority, so it is sketchy. I am waiting for confirmation from site as to actual timings.
While i wait, i have been considering the possibility of encoding the video as RTSP, then re-streaming that RTSP signal across the LAN. I am hoping (and i could be wrong!) that as there will be no transcoding, and there will be negligible latency added. I am also hoping that by doing this it maintains the least possible bandwidth between the 2 sites as i will have 6 unicast streams between the sites and then up to 20 unicast streams on the LAN from Amino box to Wowza (this infrastructure seems to have worked well with the initial config).
So, my issue - I can't seem to pick up the restreamed RTSP stream. I have it set currently that my StartupStreams.xml is grabbing the URL:
I can see from the log that it is successfully binding to that URL. Problem is, i can't seem to access it after Wowza. The test player wont find it and VLC wont find it so i presume that the URL i am using to get it is wrong. Anyone any ideas??
I have tried containing the URL in a .stream file and treating it like a camera stream, but it wont bind correctly i assume this is because of the SDP file it is trying to retrieve from the encoder.
Also worth noting that i can't seem to intercept the url from the encoder via VLC either. Can't be sure if VLC will handle the sdp file without modification.
I would really appreciate if someone could firstly tell me if i am doing the right thing to try reduce the latency, and secondly, how to get this RTSP re-streaming working!!
The RTSP playback clients also have a client side buffer. You will need to check what is the buffer size on the player running on your Amino A140 device. Usually the player buffer size is several seconds long. Can you try and decrease the client buffer?
In order to ingest an RTSP stream into Wowza, you must make sure that this stream is accessible by Wowza. If you are not able to play back that stream from your encoder, it is usually a strong indication that, once requested, the data packets are not reaching your server. It is possible that there is a firewall somewhere in between blocking the UDP traffic between the encoder and Wowza/VLC.
Also, in the StartupStreams.xml file, when connecting to an external source that is not a Wowza server, you should use the "rtp" MediaCasterType.
Zoran, thanks for the reply. I will change the mediacaster type.
2 questions though:
1. do you know for sure that the Amino A140s have a buffer, i have looked before and there is no sign of one, even in the FW? I am also seeing the exact same delay times via VLC locally and remotely on my laptop.
2. Is changing my input stream type to RTSP the right thing to do, to try and decrease the delay? it seems to increase CPU usage big time.