I have at least 6 or 8 customers with this camera. I have taken a close look at it. It uses its own packetization scheme. Sony provides the specification. I don’t think we will have a chance to create the depacketizer until the beginning of next year. We are very focused on getting Wowza Media Server 2 done before the end of the year.
Charlie
Wowza and Flash does not support AMR.
Charlie
Hi,
Note: By default Wowza Pro streams using UDP on ports 6970 - 9999 and TCP port 554. This can be a problem if you are streaming to a Wowza Pro server or Oscar that is behind a firewall on which these ports are blocked. To resolve this issue, you need to open up the UDP port range 6970 - 9999 and TCP port 554 on any firewalls between the Oscar encoder and Wowza Pro. You may also need to adjust the [oscar-ip-address] if the Oscar is behind a router that has provided a NAT address for the device.
Is there a way to change the UDP port range mentioned above? We have an Axis cam that responds that it is streaming its data on very high ports:
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.359 - - - - - - - ModuleStreamNameAlias.onAppStart: streamNameAliasFile: C:\Program Files\Wowza Media Systems\Wowza Media Server Pro 1.7.0\conf\StreamNameAliasMap.txt
INFO application app-start 2009-06-16 12:52:56 - - - - - 2487.375 - - - - - - _definst_ rtplive/_definst_
INFO session connect-pending 2009-06-16 12:52:56 1074742433 193.138.250.6 - 3760 3073 0.235 - - - - - - 193.138.250.6 -
INFO session connect 2009-06-16 12:52:56 1074742433 193.138.250.6 - 3760 3073 0.235 - - - - - - 193.138.250.6 -
INFO stream create 2009-06-16 12:52:56 1074742433 193.138.250.6 - 3809 3361 0.0 - 1 0 0 - - - -
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.406 - - - - - - - ModuleStreamNameAlias.streamNameToAlias: streamName:webcam1 alias:{pattern: "webcam1" alias:"rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp" wildcardMatches:null} result:rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.422 - - - - - - - ModuleStreamNameAlias.play: webcam1=rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.422 - - - - - - - MediaStreamMediaCasterPlay: startPlay
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.422 - - - - - - - RTPMediaCaster.create
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.422 - - - - - - - RTPMediaCaster.init
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.422 - - - - - - - RTPMediaCaster.Reconnector: start
INFO server comment 2009-06-16 12:52:56 - - - - - 2487.453 - - - - - - - RTPSessionTracker.add[rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp]: 1
INFO server comment 2009-06-16 12:52:57 - - - - - 2487.828 - - - - - - - RTPSessionDescriptionDataProviderBasicRTSPWorker.buildSDPData: sessionId:3B8E60DC sessionTimeout:60000
INFO server comment 2009-06-16 12:52:57 - - - - - 2487.953 - - - - - - - RTPSessionDescriptionDataProviderBasic.getStreamInfo: RTSP/RTP re-streaming. Success, received SDP data.
INFO stream create 2009-06-16 12:52:57 - - - - - 0.0 - 1 0 0 - - - -
INFO stream create 2009-06-16 12:52:57 - - - - - 0.0 - 1 0 0 - - - -
INFO stream publish 2009-06-16 12:52:57 - - - - - 0.0 rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp 1 0 0 - - rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp -
INFO server comment 2009-06-16 12:52:57 - - - - - 2487.953 - - - - - - - RTPSessionDescriptionDataProviderBasicRTSPWorker.sessionStart: PLAY: rtsp://user:pass@XX.XX.XX.XX:554/axis-media/media.amp
INFO server comment 2009-06-16 12:52:57 - - - - - 2487.953 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:55320
INFO server comment 2009-06-16 12:52:57 - - - - - 2487.953 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:55321
INFO server comment 2009-06-16 12:52:57 - - - - - 2487.953 - - - - - - - RTPMediaCaster.Reconnector: stop
These ports (55320 and 55321) obviously lay beyond the default range which Wowza supports.
We are able to watch the direct H.264 URL of the cam (rtsp://XX.XX.XX.XX:554/axis-media/media.amp) using QuickTime player.
Regards,
Rudo
JetStream BV
Hello to everyone,
I followed this instruction in detail BUT 
I am working on a fresh install virtual machine with Win2K sp4, all drivers and codec installed.
WowzaMediaServer 1.6.0 and patch12 applied, examples installed.
(streamType in application.xml in rtplive folder is set to rtp-live)
I’m tryin to connect with a 2N video door phone wich has rtsp protocol with h.264.
Wowza server on ip 192.168.3.54
Video door phon on ip 192.168.3.53
With VLC I can use rtsp://192.168.3.53 as address and the streaming is OK
Opening LiveVideoStrem client example and using
SERVER: rtmp://192.168.3.54/rtplive
STREAM: rtsp://192.168.3.53:554
Wowza server console report the following messages:
INFO stream create - -
streamName: rtsp://192.168.3.53/video
playStart: -2.0
playLen: -1.0
playReset: 1
INFO server comment - MediaStreamMediaCasterPlay: startPlay
INFO server comment - RTPMediaCaster.create
INFO server comment - RTPMediaCaster.init
INFO server comment - RTPMediaCaster.Reconnector: start
ERROR server comment - RTPSessionDescriptionDataProviderBasicRTSPWorker.processR
esponse: CSeq less than zero
INFO server comment - MediaStreamMediaCasterPlay: close
The WowzaMediaServer network sniffing (wireshark) is
DESCRIBE rtsp://192.168.3.53:554 RTSP/1.0
CSeq: 1
Accept: application/sdp
User-Agent: Wowza Media Server Pro (Wowza Media Server Pro10 1.6.0 build10546)
RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 284
Server: HIP1.1.0.117.0
v=0
o=- 0 0 IN IP4 192.168.3.53
s=HeliosIP Streaming
c=IN IP4 192.168.3.53
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://192.168.3.53/audio
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42E01E; packetization-mode=1
a=control:rtsp://192.168.3.53/video
SETUP rtsp://192.168.3.53:554/rtsp://192.168.3.53/audio RTSP/1.0
Transport: RTP/AVP;unicast;client_port=6970-6971
CSeq: 2
User-Agent: Wowza Media Server Pro (Wowza Media Server Pro10 1.6.0 build10546)
RTSP/1.0 404 Not Found
Server: HIP1.1.0.117.0
TEARDOWN rtsp://192.168.3.53:554 RTSP/1.0
CSeq: 3
User-Agent: Wowza Media Server Pro (Wowza Media Server Pro10 1.6.0 build10546)
RTSP/1.0 454 Session Not Found
CSeq: 3
Server: HIP1.1.0.117.0
The main difference with vlc stream is in this rows:
WOWZA:
SETUP rtsp://192.168.3.53:554/rtsp://192.168.3.53/audio RTSP/1.0
Transport: RTP/AVP;unicast;client_port=6970-6971
CSeq: 2
VLC:
SETUP rtsp://192.168.3.53/audio RTSP/1.0
CSeq: 9
Transport: RTP/AVP;unicast;client_port=1162-1163
Where I am wrong? 
I am not able to figure it out.
Help please.
Hello,
Is there any way to pull multiple RTP streams from Axis cameras using a server-side configuration? We don’t want to expose original stream URL to clients. The only way to do it I have found so far is to use live.swf from examples, which tells the server about where to get the stream.
Thanks.
Note: By default Wowza Pro streams using UDP on ports 6970 - 9999 and TCP port 554. This can be a problem if you are streaming to a Wowza Pro server or Oscar that is behind a firewall on which these ports are blocked. To resolve this issue, you need to open up the UDP port range 6970 - 9999 and TCP port 554 on any firewalls between the Oscar encoder and Wowza Pro. You may also need to adjust the [oscar-ip-address] if the Oscar is behind a router that has provided a NAT address for the device.
This note seems to imply that Wowza Pro’s UDP streams can be reconfigured, is that true? Is it possible to configure Wowza to re-stream RTSP/RTP streams over a single port, or a smaller set of ports? Opening a large port range on a Windows server is a real hassle (ports must be individually typed in, or the process scripted). Plus, I’ve head that port connection performance is improved in Windows Server 2008, which should make having many simultaneous connections on a single port less of a performance concern.
Second, I’m not sure what an “Oscar encoder” is, I tried googling the term but the results were minimally helpful. I’m trying to re-stream an RTSP stream coming from a Sharx SCNC2607 IP camera, and both the server and webcam are located behind the same router. Might the IP camera be using an “Oscar encoder”, or is that something else entirely? I’m just trying to troubleshoot why it’s not working with the camera, even though I’ve confirmed the stream coming from the camera is works fine in VLC (though VLC doesn’t support the .3GPP audio).
Server: rtmp://192.168.1.40/live
Stream: rtsp://192.168.1.9/live_mpeg4.sdp
Here’s what I see in the Wowza access log, when I try to start the server (with the server’s firewall temporarily disabled, to prevent it from causing any issues):
INFO application app-start 2009-05-04 12:27:15 - - - - - 2133.332 - - - - - - _definst_ live/_definst_ INFO session connect-pending 2009-05-04 12:27:15 1119359289 192.168.1.12 - 3325 3073 0.456 - - - - - - 192.168.1.12 - INFO session connect 2009-05-04 12:27:15 1119359289 192.168.1.12 - 3325 3073 0.458 - - - - - - 192.168.1.12 - INFO stream create 2009-05-04 12:27:15 1119359289 192.168.1.12 - 3397 3361 0.014 - 1 0 0 - - - - INFO server comment 2009-05-04 12:27:15 - - - - - 2133.394 - - - - - - - MediaStreamMediaCasterPlay: startPlay INFO server comment 2009-05-04 12:27:15 - - - - - 2133.417 - - - - - - - RTPMediaCaster.create INFO server comment 2009-05-04 12:27:15 - - - - - 2133.417 - - - - - - - RTPMediaCaster.init INFO server comment 2009-05-04 12:27:15 - - - - - 2133.422 - - - - - - - RTPMediaCaster.Reconnector: start INFO server comment 2009-05-04 12:27:15 - - - - - 2133.642 - - - - - - - RTPSessionDescriptionDataProviderBasicRTSPWorker.buildSDPData: sessionId:8708767888840351 sessionTimeout:0 INFO server comment 2009-05-04 12:27:15 - - - - - 2133.729 - - - - - - - RTPSessionDescriptionDataProviderBasic.getStreamInfo: RTSP/RTP re-streaming. Success, received SDP data. INFO stream create 2009-05-04 12:27:15 - - - - - 0.0010 - 2 0 0 - - - - INFO stream create 2009-05-04 12:27:15 - - - - - 0.037 - 2 0 0 - - - - INFO stream publish 2009-05-04 12:27:15 - - - - - 0.049 rtsp://192.168.1.9/live_mpeg4.sdp 2 0 0 - - rtsp://192.168.1.9/live_mpeg4.sdp - INFO server comment 2009-05-04 12:27:15 - - - - - 2133.866 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6970 INFO server comment 2009-05-04 12:27:15 - - - - - 2133.866 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6971 INFO server comment 2009-05-04 12:27:15 - - - - - 2133.867 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6972 INFO server comment 2009-05-04 12:27:15 - - - - - 2133.868 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:6973 INFO server comment 2009-05-04 12:27:15 - - - - - 2133.87 - - - - - - - RTPMediaCaster.Reconnector: stop INFO server comment 2009-05-04 12:27:15 - - - - - 2133.893 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6970 WARN server comment 2009-05-04 12:27:15 - - - - - 2133.922 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:15 - - - - - 2133.955 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2133.96 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:16 - - - - - 2133.961 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2133.961 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:16 - - - - - 2133.962 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:16 - - - - - 2133.974 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B INFO server comment 2009-05-04 12:27:16 - - - - - 2133.975 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6972 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.035 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.036 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.135 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.139 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:16 - - - - - 2134.14 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.255 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.448 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:16 - - - - - 2134.449 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.627 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.627 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:16 - - - - - 2134.737 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:16 - - - - - 2134.929 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.034 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.036 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.044 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.124 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.128 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.128 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.248 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.259 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.262 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.276 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.276 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.334 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.397 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.4 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.428 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.428 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B WARN server comment 2009-05-04 12:27:17 - - - - - 2135.431 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-24 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.452 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: MTAP-16 WARN server comment 2009-05-04 12:27:17 - - - - - 2135.456 - - - - - - - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B ...The error log looks almost the same, but only contains the WARN messages.
Note: By default Wowza Pro streams using UDP on ports 6970 - 9999 and TCP port 554. This can be a problem if you are streaming to a Wowza Pro server or Oscar that is behind a firewall on which these ports are blocked. To resolve this issue, you need to open up the UDP port range 6970 - 9999 and TCP port 554 on any firewalls between the Oscar encoder and Wowza Pro. You may also need to adjust the [oscar-ip-address] if the Oscar is behind a router that has provided a NAT address for the device.
I wrote this little batch script to make it easier for Windows users to open these ports on their system. I’ve tested it pretty well. I’m not sure it makes sense to open these ports this way on Windows, there may be another way of doing it that makes more sense. YMMV.
@ECHO OFF
SETLOCAL
SETLOCAL ENABLEDELAYEDEXPANSION
REM Specify port range to open with RANGESTART and RANGEEND.
REM Note: Windows 2000, XP, and 2003 systems can only open one port at a time, so opening
REM a large range of ports at once may take a while. Windows Vista and 2008 can only open
REM up to 1000 ports at once, using the method below. Thus, make sure RANGEEND - RANGESTART < 1000.
REM If necessary, run this batch multiple times to open larger port ranges on those systems,
REM though it may make more sense to instead open all ports for the Wowza Media Server program
REM or service.
SET RANGESTART=6970
SET RANGEEND=7969
REM Detect Windows version.
ver| FINDSTR /C:"Version 5" 1>NUL 2>NUL
IF 0 == %ERRORLEVEL% (GOTO 2000_XP_2003)
ver| FINDSTR /C:"Version 6.0" 1>NUL 2>NUL
IF 0 == %ERRORLEVEL% (GOTO VISTA_2008)
ver| FINDSTR /C:"Version 6.1" 1>NUL 2>NUL
IF 0 == %ERRORLEVEL% (GOTO WINDOWS7)
ECHO "Current Windows version is not supported by this script."
GOTO END
:2000_XP_2003
FOR /L %%A IN (%RANGESTART%,1,%RANGEEND%) DO (
REM Open one port at a time on Windows 2000, XP, and Server 2003.
netsh firewall add portopening name="RTP UDP %%A" protocol=UDP port=%%A 1>NUL
IF !ERRORLEVEL! NEQ 0 ( ECHO Failed to add UDP port %%A. ) ELSE ( ECHO Added UDP port %%A. )
)
GOTO END
:VISTA_2008
REM Open up to 1000 ports at once on Windows Vista, Server 2008.
SET PORTLIST=
FOR /L %%A IN (%RANGESTART%,1,%RANGEEND%) DO (SET PORTLIST=!PORTLIST!%%A,)
netsh advfirewall firewall add rule name="RTP %RANGESTART%-%RANGEEND% (UDP-In)" protocol=UDP dir=in action=allow description="Allows Wowza Media Server RTP restreaming." localport=%PORTLIST%
IF !ERRORLEVEL! NEQ 0 ( ECHO Failed to add UDP ports %RANGESTART%-%RANGEEND%. ) ELSE ( ECHO Added UDP ports %RANGESTART%-%RANGEEND%. )
GOTO END
:WINDOWS7
REM Open the specified port range on Windows 7, in a single command.
netsh advfirewall firewall add rule name="RTP %RANGESTART%-%RANGEEND% (UDP-In)" protocol=UDP dir=in action=allow description="Allows Wowza Media Server RTP restreaming." localport=%RANGESTART%-%RANGEEND%
IF !ERRORLEVEL! NEQ 0 ( ECHO Failed to add UDP ports %RANGESTART%-%RANGEEND%. ) ELSE ( ECHO Added UDP ports %RANGESTART%-%RANGEEND%. )
:END
PAUSE
Hey all,
I’ve followed the instructions closely, and I can’t get this to work. I started with a fresh 1.7.2 install, copied the files from the dev branch, created the folders, copied and edited Application.xml, and ran startup.sh from bin/, then opened the Live Video Streaming test.
Server: rtmp://localhost/rtplive
Stream: rtsp://192.168.1.16:554/oscar
No video or audio. No error messages from wowza. Any ideas?
Pastie of logs and server output: http://pastie.org/611818
Thanks in advance.
Hi Folks.
I too am looking into connecting an AXIS camera with h264 to a Wowza server for streaming live through Flash.
Does anyone have any live examples, and specifications on what they’re using (eg uplink speed/server setup) in order to gauge what performance we can expect? What sort of frame rates should one expect at certain sizes?
Given I’ve never actually seen one in action, if anyone has some URLs that I could see, that would be a great help to ‘really’ know that it’s being done, and done well, before I really sink my teeth into this…
Many thanks.
FW
Hi all. Am still getting up to speed with h264/AXIS cameras/RTSP and Wowza.
AXIS released their first PTZ camera this year with h264 support - the Q6032-E.
http://www.axis.com/products/cam_q6032e/index.htm
It’s the only PTZ camera I could find so far which has h264 and RTSP support which I am planning to use with a Wowza server. The problem is that is has no audio capabilities whatsoever, unlike models such as the Q1755 which has been mentioned on this forum as one that works. You can get a third party pan/tilt solution for a Q1755 but it’s not what you would call ‘discrete’.
So I am having to go with the Q6032-E for a client, but I need to also provide audio in this solution as part of the stream. Synchronised (it will include people talking).
Can anyone provide any wisdom on how this could be done so that video and audio are sync’d up when they get to a Wowza server for delivery? AXIS have a ‘box’ planned in Q4 of this year which does exactly this for cameras which don’t have audio support, but I need to provide a solution sooner than later.
Hope someone can provide some pointers on this.
Many Thanks!
FW.
(please let me know if this should be in another part of the forum)
Hi,
I am evaluating Wowza Media Server Pro for a SaaS solution. But I got some troube when streaming from a AXIS 207MW camera. Iam using Wowza Media Server Pro 1.7.2 + WowzaMediaServerPro1.7.0-patch21.zip and added the property’s described in this thread.
First I tried to stream via vlc using rtsp (vlc rtsp://172.16.10.51:554/mpeg4/media.amp), this works perfectly. But when I try to stream to Wowza I don’t see the live video. (Iam using the LiveVideoStreaming example.)
Server: rtmp://172.16.9.140/live-stream
Stream: rtsp://172.16.10.51/mpeg4/med
I got the following output:
(forceInterleaved -> disabled / Only a snippet, cause’ many thousand lines, This seems like stream data, but dunno)
DEBUG server comment - checkFlush[true,false,50]: tc:1250597684125>1250597684105 || rt:1250597684144>1250597684042
DEBUG server comment - flush: notify:false tSize:1 dataObjs:72 time:152 tOffset:-89
DEBUG server comment - writePacket[vid]: sz:19478 tc:1250597684125:1120469521:1250597684144 key:false
DEBUG server comment - checkFlush[false,false,50]: tc:1250597684125>1250597684175 || rt:1250597684145>1250597684194
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 30 42 c9 4b 69 43 3b 77 83 00 00 01 b6 }
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 31 42 c9 4b 69 43 3b 77 83 f8 1c 50 14 }
DEBUG server comment - STAP-A: end:false tc:1120488297
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 32 42 c9 4b 69 43 3b 77 83 8c 30 6f 18 }
DEBUG server comment - SINGLE: end:false tc:1120488297 sz:1460
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 33 42 c9 4b 69 43 3b 77 83 60 14 ad b0 }
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 34 42 c9 4b 69 43 3b 77 83 02 9f 05 51 }
DEBUG server comment - SINGLE: end:false tc:1120488297 sz:1460
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 35 42 c9 4b 69 43 3b 77 83 30 bc 95 3c }
DEBUG server comment - SINGLE: end:false tc:1120488297 sz:1460
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 36 42 c9 4b 69 43 3b 77 83 29 22 7a d2 }
DEBUG server comment - SINGLE: end:false tc:1120488297 sz:1460
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 37 42 c9 4b 69 43 3b 77 83 21 4a f8 38 }
DEBUG server comment - SINGLE: end:false tc:1120488297 sz:1460
DEBUG server comment - rtp[trackID=1:1107] {80 e0 65 38 42 c9 4b 69 43 3b 77 83 59 3b 58 c9 }
WARN server comment - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B
DEBUG server comment - nalUnit: hdr:24 sz:1459:13750 typ:DPC
DEBUG server comment - nalUnit: hdr:b1 sz:1460:13750 typ:17
DEBUG server comment - nalUnit: hdr:d3 sz:1460:13750 typ:AUXILIARY_SLICE
DEBUG server comment - nalUnit: hdr:c2 sz:1460:13750 typ:DPA
DEBUG server comment - nalUnit: hdr:10 sz:1460:13750 typ:16
DEBUG server comment - nalUnit: hdr:b sz:1460:13750 typ:END_STREAM
DEBUG server comment - nalUnit: hdr:11 sz:1460:13750 typ:17
DEBUG server comment - nalUnit: hdr:81 sz:1460:13750 typ:SLICE
DEBUG server comment - sliceType:1 frameType:3
DEBUG server comment - nalUnit: hdr:d sz:1460:13750 typ:SPS_EXT
DEBUG server comment - nalUnit: hdr:a9 sz:571:13750 typ:AUD
DEBUG server comment - writePacket[vid]: sz:13755 tc:1250597684264:1120482037:1250597684184 key:false
DEBUG server comment - checkFlush[true,false,50]: tc:1250597684264>1250597684175 || rt:1250597684184>1250597684194
DEBUG server comment - flush: notify:false tSize:2 dataObjs:73 time:40 tOffset:-188
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 39 42 c9 63 dd 43 3b 77 83 00 00 01 b6 }
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 3a 42 c9 63 dd 43 3b 77 83 d3 07 bb 58 }
DEBUG server comment - SINGLE: end:false tc:1120494557 sz:1460
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 3b 42 c9 63 dd 43 3b 77 83 bd 80 37 04 }
WARN server comment - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: FU-B
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 3c 42 c9 63 dd 43 3b 77 83 d9 ac 5d 20 }
WARN server comment - RTPDePacketizerRFC3984H264.handleRTPPacket: Unsupported packet type: STAP-B
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 3d 42 c9 63 dd 43 3b 77 83 b0 06 21 60 }
DEBUG server comment - SINGLE: end:false tc:1120494557 sz:1460
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 3e 42 c9 63 dd 43 3b 77 83 1c c1 b3 e0 }
DEBUG server comment - FU-A: end:false tc:1120494557 st:true
DEBUG server comment - rtp[trackID=1:1472] {80 60 65 3f 42 c9 63 dd 43 3b 77 83 80 e3 6d 62 }
DEBUG server comment - rtp[trackID=1:1397] {80 e0 65 40 42 c9 63 dd 43 3b 77 83 c8 60 8d ec }
DEBUG server comment - SINGLE: end:true tc:1120494557 sz:1385
DEBUG server comment - nalUnit: hdr:8c sz:1460:7320 typ:FILLER_DATA
DEBUG server comment - nalUnit: hdr:2 sz:1460:7320 typ:DPA
DEBUG server comment - nalUnit: hdr:30 sz:1460:7320 typ:16
DEBUG server comment - nalUnit: hdr:29 sz:1460:7320 typ:AUD
DEBUG server comment - nalUnit: hdr:21 sz:1460:7320 typ:SLICE
DEBUG server comment - sliceType:1 frameType:3
DEBUG server comment - writePacket[vid]: sz:7325 tc:1250597684333:1120488297:1250597684261 key:false
DEBUG server comment - checkFlush[true,false,50]: tc:1250597684333>1250597684314 || rt:1250597684261>1250597684234
DEBUG server comment - flush: notify:false tSize:1 dataObjs:73 time:77 tOffset:-180
(forceInterleaved-> Enabled)
]DEBUG server comment - RTPSessionDescriptionDataProviderBasicRTSPWorker.send(open): command:GET_PARAMETER
DEBUG server comment - cseq: 4
DEBUG server comment - uri: RTSP/1.0 200 OK
DEBUG server comment - protocol: RTSP/1.0
DEBUG server comment - status: 200
DEBUG server comment - response: OK
DEBUG server comment - cseq: 4
DEBUG server comment - *** RTSPMessageReceive ***
RTSP/1.0 200 OK
response: OK
protocol: RTSP/1.0
cseq: 4
status: 200
uri: RTSP/1.0 200 OK
DEBUG server comment - RTPSessionDescriptionDataProviderBasicRTSPWorker.processResponse: command:GET_PARAMETER response:RTSP/1.0 200 OK status:200 handled:false
DEBUG server comment - send[1139941015]: size:0 filter:7 time:252 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:251 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:252 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:250 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:253 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:251 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:252 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:258 tOffset:0
DEBUG server comment - send[1139941015]: size:0 filter:7 time:246 tOffset:0
hi charlie
my self venkat from mascon global limited,I have facing RTSP Streaming problem.The problem statement is as follows
My camera pushing data in the form of rtsp(rtsp://172.16.50.11/12345)i want to retransmit using WowzaMedaiServer ,I have installed the trail verssion of the server.i found some of the example were there in installation package,i picked the"Live streamvideo "example,in that example it is picking up only rtmp url as an input not rtsp.how to retransmit the RTSP stream again using WowzMediaServer?
please help us
Thanks in advance
Thanks
venkat
I’m having a disconnect on where to point to the stream to use when using the flowplayer or JW viewer.
I was able to get our axis live stream to work using the the live.html example, but I typed in the stream name to the camera directly into the .swf just at the bottom of the wowza viewer.
how do i associate this with the JW or flowplayer viewer? By “this” i mean the stream name rtsp://[camera-ip-address]:554/axis-media/media.amp as an example. Obviously i’ll update our camera ip address in the stream name. Is this defined somehwere in the application.xml?
We have the streaming of video working properly. Is there a trick to stream the sound and play in jw player?
Hi, Charlie,
I tried the instructions in this article step by step, but got this in the error log:
RTSPCore.handleMessage: java.lang.NullPointerException
Could you tell me what’s wrong with it?
regards
Chen Fan
Step by step instructions for Re-streaming and RTSP stream through Wowza Pro.
Download and install Wowza Media Server Pro (version: Wowza Pro 1.7.0 or greater is required)
Download and install the most recent patch to get RTSP/RTP interleaving feature: http://www.wowza.com/devbuild.html
Create a new Wowza Pro application for streaming (may already exist if examples installed)
Create the folder [install-dir]/applications/rtplive
Create the folder [install-dir]/conf/rtplive
Copy the file [install-dir]/conf/Application.xml into this new folder [install-dir]/conf/rtplive
Edit the newly copied Application.xml and make the following changes:
Change Streams/StreamType to rtp-live
Add following properties to Streams/Properties container (there are several containers, be sure to add to correct container)
<Property>
<Name>sortPackets</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
<Property>
<Name>sortBufferSize</Name>
<Value>500</Value>
<Type>Integer</Type>
</Property>
Add following properties to MediaCaster/Properties container (there are several containers, be sure to add to correct container)
<Property>
<Name>forceInterleaved</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
Startup the Wowza Pro server
To play the stream, double click [install-dir]/examples/LiveVideoStreaming/client/live.html enter the following information and click the Play button:
[b]Server[/b] to [b]rtmp://[server-ip-address]/rtplive[/b]
[b]Stream[/b] to [b][noparse]rtsp://[encoder-ip-address][/noparse][/b] (Example: [noparse]rtsp://192.168.1.8:554[/noparse])
Where [server-ip-address] is the ip address of the server running Wowza Pro and [encoder-ip-address] is the ip address of the RTSP device.
Note: Some cameras do not support RTSP/RTP interleaving (sending the RTP packet data over the RTSP TCP connection) If this is the case then set the forceInterleaved property above to false, restart Wowza Media Server and try to play the stream.
Note: Some cameras do not send RTCP packets. If you see the warning log message:
Edit [install-dir]/rtplive/Application.xml and change the RTP/AVSyncMethod to systemclock.
Note: If you are re-streaming an H.264 stream from an Axis Communications camera such as the following models (which natively support H.264): M1011(-W), M1031-W, P3301(-V), Q1755, Q6032 the RTSP url take the form:
where [camera-ip-address] is the ip adress of the Axis camera.
Note: By default Wowza Pro streams using UDP on ports 6970 - 9999 and TCP port 554. This can be a problem if you are streaming to a Wowza Pro server or Oscar that is behind a firewall on which these ports are blocked. To resolve this issue, you need to open up the UDP port range 6970 - 9999 and TCP port 554 on any firewalls between the Oscar encoder and Wowza Pro. You may also need to adjust the [oscar-ip-address] if the Oscar is behind a router that has provided a NAT address for the device.
Note: Many players will not accept stream names that look like urls. You can use the stream name alias package to create an alias for the stream name url. This package can also be used to secure Wowza Pro so that it will only be able to restream urls that you specify. This package can be downloaded from here: StreamNameAlias.
Note: There is an issue when re-streaming an RTSP/RTP stream that is hosted by Quicktime Streaming Server (Darwin, QTSS) that after 2 minutes of streaming the stream will be dropped by QTSS. This is caused by the fact that Wowza Pro does not send RTCP Receiver Report packets back to QTSS. This causes QTSS to timeout and disconnect the stream based on the rtp_timeout value defined in streamingserver.xml. The current workaround for this issue is to set the rtp_timeout property in QTSS to 0 (zero) which will disable this timeout feature. We are investigating supporting RTCP RR packets in a future release of Wowza Pro.
Note: If you experience problems getting either the audio or video to play through Flash, double check the version number of the Flash player (Flash player version 9.0.115.0 or above is required). If you still have problems, turn on Wowza Pro debug logging (edit [install-dir]/conf/log4j.properties and change the log4j.rootCategory on the first line from INFO to DEBUG), try the encoder several more times, zip up and send your [install-dir]/logs folder along with screen shots of the encoder setup screens and the LiveVideoStreaming player screen and send a detailed description of your problem to support@wowza.com.
See this post for troubleshooting tips:
Troubleshooting live streaming issues
Charlie
HI,
I managed to stream video from a rtsp stream, but I can not get audio … my test is: www.meway.it/clienti/genius
With vlc I can receive audio and video from the address rtsp://212.103.211.83:554/geniustv_live
I hope you can help me!
Hi, also wanted to use your WOWZA server to test our AXIS camera stream with the streaming server. So i installed the Wowza Media Server Developer on my machine, configured it like in the first post.
When i run examples/LiveVideoStreaming/client/live.html and put the URL for the axis cam:
rtsp://CAM-IP:554/axis-media/media.amp
There is no output 
when i use the same URL in the VLC player it runs!
Is the wowza server version wrong(developer) ? any ideas?
My last ouput in the console which is running:
INFO vhost comment defaultVHost Bind attempt ([any]:1935:4)
INFO vhost comment defaultVHost Bind successful ([any]:1935)
INFO vhost comment defaultVHost Bind attempt ([any]:8086:1)
INFO vhost comment defaultVHost Bind successful ([any]:8086)
… by the fact that Wowza Pro does not send RTCP Receiver Report packets back … We are investigating supporting RTCP RR packets in a future release of Wowza Pro.
Have RTCP Receiver Reports been implemented? I am not seeing any RTCP RR packets coming back from Wowza. I am using the latest Developer install for testing.
Wowza Pro does not support live pause. So the pause button in the FlowPlayer player will not work properly. This is most likely the issue. Only play and stop are going to work correctly with live video.
Charlie
© 2007–2024 Wowza Media Systems™, LLC. All rights reserved. Security & Privacy PolicyLegalSystem Status