Axis has a new H.264 camera. They say it is mpeg4 part 10. Is there any reason this wouldn’t work with a Wowza server?
Camera link: http://www.axis.com/products/cam_p3301/index.htm
Thanks,
Mat
Axis has a new H.264 camera. They say it is mpeg4 part 10. Is there any reason this wouldn’t work with a Wowza server?
Camera link: http://www.axis.com/products/cam_p3301/index.htm
Thanks,
Mat
As long as it can stream over either RTP or MPEG-TS then it should work witih Wowza Pro. We are trying to get our hands on this camera as well.
Charlie
Hmm, I will have my business partner check.
Charlie
Seems like it might not work. I would expect the camera to require an RTSP session to keep streaming.
Charlie
Install this patch. It should fix the problem:
WowzaMediaServerPro1.5.3-patch12.zip
I have not posted it on the dev builds page so let me know if it fixes the problem for you. There is a buffering fix that should make a difference.
Charlie
Take a look at this post. It included a stream name alias plugin that should do the trick.
http://community.wowza.com/t/-/47
Charlie
There should be no difference. Be sure it is running the correct version when started as a service.
Charlie
We do not have a way to specify this information through this method. I can add it in a future release but it will be a few weeks. Is there a way to turn off authentication in the mean time. Also, you will want to install this patch to get a consistent stream:
WowzaMediaServerPro1.5.3-patch19.zip
Charlie
We do not support RSTP/RTP tunneling when re-streaming RTSP. We do support RTSP/RTP tunneling when using an RTSP/RTP encoder such as Wirecast or Quicktime Broadcaster.
We do now support authentication with the most recent patch. The url format is:
rtsp://username:password@domain:port/streamname
If you use the stream name alias package you can hide the username and password behind an alias:
http://community.wowza.com/t/-/47
Charlie
Try these instructions:
http://community.wowza.com/t/-/53
It should just work. You don’t need an SDP file. Wowza Pro can pull the stream directly from the camera over RTSP. I have tons of people doing it this way with this exact camera.
Charlie
Use the rtp-live-record stream type.
Charlie
You have to rename it after the recording has completed.
Charlie
Not yet. We are working with the Axis folks to get one. I don’t think they are publicly available yet.
Charlie
Explain in detail how you are trying to connect to the camera. The SDP data looks fine except there is no port number in this statement:
m=video 0 RTP/AVP 96
Charlie
The encoder is most likely pinging Wowza Pro to keep the RTSP/RTP connection alive. Wowza Pro does not respond correctly. Try applying this patch to see if it fixes it. I have attempted to blindly add support for this method of keeping the connection alive:
WowzaMediaServerPro1.5.3-patch17.zip
If not, contact me offline (charlie@wowza.com) and I might work out a time where you can make the encoder available to me on the Internet so I can debug the problem and add the proper response.
Thanks,
Charlie
The rtmp url would be:
Server: rtmp://[wowza-ip-address]/rtplive
Stream: [rtsp-url-to-camera]
Really no difference. Just that localhost is replaced by the ip address of the server running Wowza Pro. If you want to hide the camera’s rtsp url then take a look at this package:
http://community.wowza.com/t/-/47
Charlie
Try following these instructions to install a jitter buffer and log packet loss:
http://community.wowza.com/t/-/51
See if after you do this you see an improvement in the frame rate and/or you see packet loss statements in the log file.
Charlie
Other than packet loss I have not idea why the frame rate would be any different when played through Wowza Pro. We are not doing anything to modify the frame rate. If you want, contact me off list and send me an RTSP url to try so I can see the problem (charlie@wowza.com).
Charlie
Are there settings that influences output framerate for this setup? Framerate of direct Axis rtsp source is good, while the relayed result (rtmp stream) has got a very low framerate.
Using Wowza Media Server Pro10 1.6.0 build9490
Solved. FlushInterval had a (rediculous small?) value of 5, changed when I was experimenting with low latency settings before.