Hi Richard.
Thanks for that. I’m halfway there in that I can connect remotely to an AXIS Q1755 (which is connected to a 3G router), and watch the live h264 RTSP stream using QuickTime Player which is fantastic.
I had already opened up port 554 to the camera; you mentioned needing to open up ports 6970-9999 for UDP. Why is that? And what port should that rout to on the camera?
Thanks again.
FW
Hi Charlie.
Thanks for that. I was guessing that’s what you’d say.
At present AXIS can’t offer PTZ/h264/audio/RTSP in a single package. However I have found this brand/model which does:
http://www.omconcctv.com/900IPS.html
Have you heard of these, and has anyone used one of these with a Wowza server?
I might try to get my hands one on…
Thanks Charlie.
Hi Charlie.
Thanks for that.
One other question I have (if you’ll excuse my possible ignorance) - I have read on this forum a recommendation of using a dedicated server for using Wowza. And that makes sense. But then I am guessing it really relates to the load requirements. If I had a 250kbit/sec stream and no more than 10 simultaneous users, what sort of server spec should I allow for? Are many people using VPS’s, or mainly all dedicated servers?
Could you also give me an idea of what processing the server actually has to do - I assume it’s not re-encoding h264 or anything like that, but rather adapting the stream from RTSP to be RTMP. What sort of processing power are we talking about per user - assuming a 256kbit/sec stream as well?
Thanks Charles.
Hi Folks.
A little while back Richard replied to one of my posts, saying:
“Wowza Pro streams using UDP on ports 6970 - 9999 and TCP port 554. They should be open on your router if you are using it and on your server…”
I’m currently doing h264 tests with a Billion 3G router and an AXIS Q1755, and whilst it allows you to specify a range of incoming port numbers together, you then have to provide a single internal port number for the device that those ports are being forwarded to. What should the resulting UDP port be for an AXIS camera therefore? I already have 554 working ok. I’m assuming this all needs to be in order before it’ll work with Wowza…
Many thanks.
FW.
Hi Richard.
Thanks for your reply. I’m a bit confused though. When allocating an IP address to forward an external port to, I also need to tell the router what port number of that device the assigned port numbers need to go to.
Eg, for 554 the router is port forwarding to port 554 on the AXIS camera.
I’m in the process of waiting for a colleague to setup our first Wowza server, but want to ensure that I have everything in place at my end, which is the AXIS camera, router and a 3G uplink. This is all working well when connecting remotely via QuickTime or VLC to get an RTSP stream. But I want to just make sure I have everything setup correctly in readiness for Wowza interoperability.
Apologies if I seem to be misunderstanding all this.
Thanks again.
FW.
Thanks Richard.
What probably happens with a Linksys router is that when you allocate that range of port numbers, it in turn automatically forwards them to the same port numbers on the device (IP address). I know Netcomm routers do this too, and with the industrial 3G routers we use we can actually allocate an external range of ports to a completely different range of ports locally if we want to.
But with the Billion router, you can assign a range of external ports (6970 - 9999), but only then forward them onto 1 port on a local device. Is this going to cause a problem for our initial testing of a Wowza server and an AXIS Q1755?
Thanks again.
FW
Yes, the Billion router has a DMZ setting, where I can specify an IP address.
Did some quick reading on what DMZ means, and if I understand correctly it means that all ports on the device I specify are open and accessible (ie whatever the Wowza server needs from the camera). Is that correct?
Thanks Richard.
FW
Last word on this: I connected to the Billion router remotely, assigned the DMZ to the AXIS camera’s IP address, and them promptly lost access to the router (which was on port 81). But the camera’s working ok.
And this makes sense because from what I’ve read the idea of a DMZ is to make it so that any would-be hackers can only see whatever is specified in the DMZ. Nothing else.
Thanks for your help Richard.
FW.
Hi.
Any chance Wowza will support MPEG4-2 video re-streaming?
This will not work of course with Flash, but will be supported by QuickTime, VLC and a lot of mobile players out there. This will solve the issue of having another (QT server for example) server just for support of older MPEG-4 encoders.
Any idea?
Regards.
I have a task to connect RTMP and RTP through Wowza. RTMP side implemented with JW Player folowing this topic
http://www.wowza.com/community/t/-/33
RTP stream made by VLC player ( http://wiki.videolan.org/Documentation:Streaming_HowTo/Easy_Streaming )
All is situated at localhost. RTP from VLC have no error, after tuning RTMP from this topic (using /usr/local/WowzaMediaServerPro-1.7.0/examples/LiveVideoStreaming/client/live.html to start) Wowza report like this
INFO session disconnect 1416139784 -
INFO session connect-pending 127.0.0.1 -
INFO session connect 127.0.0.1 -
INFO server comment - sortPackets[2]: sortBufferSize:500
INFO stream create - -
INFO server comment - MediaStreamMediaCasterPlay: startPlay
INFO server comment - MediaStreamMediaCasterPlay: close
INFO stream destroy rtps://localhost:7777 -
INFO session disconnect 21562135 -
INFO server comment - RTPMediaCaster.shutdown: rtps://localhost:7777
INFO server comment - RTPMediaCaster.disconnect
INFO server comment - RTPMediaCaster.Reconnector: stop
INFO application app-stop definst rtplive/definst
and using this script
I am using this method to grab a RTSP stream from Darwin/QTSS and re-stream it through Flash. I have encountered a few issues:
I had to set “forceInterleaved” to false – otherwise I just got blocky black video.
The audio and video easily lose sync, even though I have tried the following (restarting the server after each change):
added the “sortPackets” properties and the RTP jitter correction
used all the different AVSyncMethod values
watched using both the LiveVideoStreaming player and the JW Player
It seems like they start out in sync, but anything I do in the browser (switch tabs, call up a menu) causes the video to slow down for a moment while the audio keeps going. I am seeing packet loss in the logs, but I am basically on a LAN with the server, and the BWChecker application regularly shows 40 Mbps connection speed. The stream itself is only 15 fps, ~500 kbps. Darwin reports 0.0% packet loss for its connection to Wowza. Firewall is disabled.
Just curious if this is normal, or if you have any other suggestions. (I had more success relaying a stream from Darwin to Wowza, but it seemed to be a lot more complicated that simply pulling the RTSP stream. Is there a technical reason why this method would be more volatile?)
EDIT: I’ve witnessed the video slowdown on both a Mac and PC, with Safari, IE, and Firefox. This is what appears in the Wowza error log:
packetLoss[trackID=2]: last:97333 curr:97335
So only the second track (video) is suffering… audio plays through fine, thus gets ahead of the video.
You have covered just about everything I would have thought of. I assume you are on the latest patch and have tuned the server?
Yes, latest patch and server tuned.
My initial tests were with H.264/AAC live streams, coming from SDP files on the Darwin server, but the same problems occur when streaming archived MOV files in a similar manner. (Obviously I don’t plan to stream archived MOV files in this way, but I thought I would try it as a troubleshooting step.)
Anybody else here using Wowza to pull and re-stream live RTSP from Darwin/QuickTime Streaming Server?
(Or, on a related note, anybody relaying a large number of live RTSP streams from Darwin/QuickTime Streaming Server to Wowza? I am not opposed to using that method, but it seems to be a bigger hassle to configure and doesn’t look very efficient.)
Well, it turns out I misspoke when I said that relaying the streams from Darwin worked fine – the same problem happens (video slows down and falls behind audio as you toggle fullscreen or do other tasks in the browser).
I will post a new topic on this issue, since it doesn’t seem to be related to this method…
Sync issue fixed!
In QuickTime Broadcaster, uncheck the “Frame Reordering” option under the Video tab.
when I try to restream rtsp from windows media server i get this error message.
WARN server comment - Failed to find an appropriate depacketizer for this track
(x-wms-rtx): You may not have the proper software license to use this feature. P
lease contact sales@wowza.com for more information.
I tried to do it through videolan player aka vlc but no sound only video.
this is the command i used for vlc
vlc -vvv rtsp://127.0.0.1/stream --sout "#transcode{venc=x264 {keyint=60},vcodec=x264,vb=500,scale=1,acodec=mp4a,ab=32,channels=2,samplerate=22050}:rtp{dst=127.0.0.1,sdp=file://C:/Program Files/Wowza Media Systems/Wowza Media Server 2 Preview 4/content/rtplive.sdp}
-Zeshan
Hello,
I did a try with a WMV RTSP stream and I had these warnings :
WARN server comment 2009-07-31 22:47:26 - - - - - 119.969 - - - - - - - Failed to find an appropriate depacketizer for this track (x-wms-rtx): You may not have the proper software license to use this feature. Please contact sales@wowza.com for more information.
WARN server comment 2009-07-31 22:47:26 - - - - - 119.969 - - - - - - - Failed to find an appropriate depacketizer for this track (x-asf-pf): You may not have the proper software license to use this feature. Please contact sales@wowza.com for more information.
WMV format is not supported, is it ?
Thanks
Trying to restream from an IP Camera following the instructions in this thread. I’m stuck now though, it seems like everything is configured perfectly. All error messages resolved but I’m getting blank video.
Server: rtmp://192.168.1.5/rtplive
Stream: rtsp://192.168.1.8:554/live
Screenshot of my Wowza console
Camera is turned on and working. VLC shows the stream when given the same stream URL.
Any ideas what I should be checking next?
Hi,
you were right the camera only support mpeg-4 and motion jpeg.
Thanks.
I’ve been searching for a solution all day, so I decided that it’s time to ask around, if someone can help me with my problem.
We are trying to connect a Dallmeier IP Camera DF3000IP-PoE with Wowza Media Server Pro 1.7.2.
The tutorial I am using is the first post, written on the first page of this thread.
My computer address is: rtmp://computer/rtplive
The camera address is: rtsp://camera/
I can access the rtsp stream via VLC just fine, but with Wowza, that’s an entirely other problem.
After some time I got rid of the Unsupported Package Type errors (I switched the IP camera to MPEG 2 encoding, MPEG 4 just doesn’t seem to work).
I cannot figure out, why I am getting the IP as 0.0.0.0, which can be seen below.
No, I am not running any other streaming software besides Wowza.
Please help me.
IINFO server comment 2009-08-27 15:53:43 - - - - - 3.375 - - - - - - - MediaStreamMediaCasterPlay: startPlay
INFO server comment 2009-08-27 15:53:43 - - - - - 3.375 - - - - - - - RTPMediaCaster.create
INFO server comment 2009-08-27 15:53:43 - - - - - 3.375 - - - - - - - RTPMediaCaster.init
INFO server comment 2009-08-27 15:53:43 - - - - - 3.391 - - - - - - - RTPMediaCaster.Reconnector: start
INFO server comment 2009-08-27 15:53:43 - - - - - 3.422 - - - - - - - RTPSessionTracker.add[rtsp://camera/encoder1]: 1
INFO server comment 2009-08-27 15:53:44 - - - - - 3.61 - - - - - - - RTPSessionDescriptionDataProviderBasicRTSPWorker.buildSDPData: sessionId:0000002a sessionTimeout:0
INFO server comment 2009-08-27 15:53:44 - - - - - 3.672 - - - - - - - RTPSessionDescriptionDataProviderBasic.getStreamInfo: RTSP/RTP re-streaming. Success, received SDP data.
INFO server comment 2009-08-27 15:53:44 - - - - - 3.672 - - - - - - - sortPackets[1]: sortBufferSize:500
INFO stream create 2009-08-27 15:53:44 - - - - - 0.016 - 1 0 0 - - - -
INFO stream create 2009-08-27 15:53:44 - - - - - 0.016 - 1 0 0 - - - -
INFO stream publish 2009-08-27 15:53:44 - - - - - 0.032 rtsp://camera/encoder1 1 0 0 - - rtsp://camera/encoder1 -
INFO server comment 2009-08-27 15:53:44 - - - - - 3.704 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6972
INFO server comment 2009-08-27 15:53:44 - - - - - 3.704 - - - - - - - RTPSessionDescriptionDataProviderBasicRTSPWorker.sessionStart: PLAY: rtsp://camera/encoder1
INFO server comment 2009-08-27 15:53:44 - - - - - 3.719 - - - - - - - RTPMediaCaster.Reconnector: stop
INFO server comment 2009-08-27 15:53:44 - - - - - 3.719 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6973
INFO server comment 2009-08-27 15:53:44 - - - - - 3.719 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6971
INFO server comment 2009-08-27 15:53:44 - - - - - 3.719 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6970
INFO server comment 2009-08-27 15:53:44 - - - - - 3.75 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6970
INFO server comment 2009-08-27 15:53:44 - - - - - 3.829 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6973
INFO server comment 2009-08-27 15:53:44 - - - - - 3.829 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6972
INFO server comment 2009-08-27 15:53:44 - - - - - 3.829 - - - - - - - RTCPHandler.sendFirstRTCPRR[278051076,6973,/10.41.1.236:34005]
INFO server comment 2009-08-27 15:53:44 - - - - - 4.313 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6971
INFO server comment 2009-08-27 15:53:44 - - - - - 4.313 - - - - - - - RTCPHandler.sendFirstRTCPRR[83560667,6971,/10.41.1.236:34003]
Charlie & others:
So, if we would like to use Wowza Media Server for streaming our video from a RTSP compatible IP camera, it would have to support H.264/AAC, nothing else is an option?
Is RTSP the best option for streaming from an IP camera to Wowza or do you recommend any other protocol/codec/etc.?
Which good IP Cameras do you know of/recommend that can be used for low-latency streaming?
Thank you for answering.
© 2007–2024 Wowza Media Systems™, LLC. All rights reserved. Security & Privacy PolicyLegalSystem Status