Hi.
I’m trying the development version of Wowza with RTP stream from native encoder located on another machine in same LAN.
The problem is, that after a few seconds of correct work, the fps seems to drop. Then, after I stop and start the JWPlayer again, it works fine for several more seconds. Same happens to Wowza rtplive sample application.
If I switch the JWPlayer to 0 buffering, the stream will work fine, with the usual frame-rate problems of 0 buffer.
Any idea why this happening?
Thanks.
Most likely the bit rate of the stream is too high for the network.
Richard
Richard,
Seems a little like the problem I have been chasing. I sent an email in to your support address a little while ago regarding this Axis streaming via 3G cellular ghost we are chasing…any chance you could take a look at it?
Involves this comment by Axis Dev:
When RTP is tunneled over RTSP or HTTP, the video streaming performance can be considerably improved if the Blocksize header in the RTSP SETUP is set to 64000 instead of the default value 1400.1 With this setting, the product will be able to handle more simultaneous video streams and, as a bonus, the network performance will improve. Note that the size of the tunneled RTP packets increases and that the client must be prepared to receive these larger packets. Axis has implemented this in AXIS Media Control and strongly recommends the same method for all clients that tunnel RTP over RTSP or HTTP.
I do not see Blocksize in your SETUP string for RTSP…could this be causing the video stream to just stop sporatically as we are seeing when streaming via RTP/RTSP with Axis?
Richard also
We currently do not have a way to add headers values to the RTSP negotation. We will consider adding this but need more information as to specifically which headers need to be added to which RTSP statement/command to increase this value.
Charlie
Can you turn on debug logging (edit conf/log4j.properties and change the log level on the first line from INFO to DEBUG), reproduce the problem and send me the logs. I would like to see what is going on. Try to delete the log file before collecting the debug data to reduce the amount of junk that is irrelevant in the log file.
The main reason we would shutdown the connection is if the stream timed out. This means we did not receive any video/audio for longer then the streamTimeout value. We also shutdown the connection if we get an TCP acception. The debug logs should indicate why.
Charlie
It might be something else, but what I mean by “network” is everything between your computer and the server, not the server’s nic.
256 kbs is not very high, but it might still be more then your network can handle. It sounds like what happens when the bit rate is too high. If you put the buffer to 0 and you have plenty of bandwidth it should play okay.
Using the bandwidth checker would give you a better idea of what your network capacity is. Also double check assumption about the total bit rate of the stream is.
How is your Application.xml setup? Did you follow a particular guide?
Ricard
You can use bandwidth checker to get an idea of what your network capacity is.
And you can use the SimpleVideoStreaming example and uncomment this line so you can watch the buffer and fps:
// uncomment this to monitor frame rate and buffer length
// debugInterval = setInterval(updateStreamValues, 500);
Richard
Hi.
Most likely the bit rate of the stream is too high for the network.
Richard
Stream of 256Kbps, Lan of 100Mbps - so I don’t this this is the reason.
Any other idea, or means how to pinpoint the source of the issue?
Hi.
How do I check the received bandwidth on the Flash payer side? Are there any tools for this (I know NetLimiter, but it seems overkill for such testing).
The Application.xml is the default one from rtplive sample application.
Maybe it should be tuned somehow to support such cases?
Thanks again.
We currently do not have a way to add headers values to the RTSP negotation. We will consider adding this but need more information as to specifically which headers need to be added to which RTSP statement/command to increase this value.
Charlie
To avoid taking up unnecessary space on the forum I sent the information that Axis Dev provided me to support@wowza today. I also included the setup strings.
Axis AMC SETUP is
SETUP rtsp://IP/axis-media/media.amp/trackID=1?videocodec=h264
RTSP/1.0
CSeq: 2
User-Agent: Axis AMC
Blocksize: 65535 <--------------BLOCKSIZE
Transport: RTP/AVP/TCP;unicast
RTSP/1.0 200 OK
CSeq: 2Session: B58B7EBD; timeout=60 <--------------TIMEOUT
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=7FF55105;mode=“PLAY”
SETUP rtsp://IP/axis-media/media.amp/trackID=1?videocodec=h264
RTSP/1.0
Transport: RTP/AVP/TCP;interleaved=0-1
CSeq: 2
User-Agent: Wowza Media Server Pro (Wowza Media Server Pro10 1.7.2 build12264)
RTSP/1.0 200 OK
CSeq: 2
Session: 9A06A246; timeout=60 <--------------TIMEOUT
<--------------NO BLOCKSIZE
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=BD3FFBFE;mode=“PLAY”
I would love to hear that anyone else is orginating IP video and transmitting it via cell without this problem…
Charlie, is it possible that this could be the key to the freezing up of the video when transported via cellular? I thought it surely was the “keep-alive” timeout function but seems Wowza acts just as Axis on this per the WS output.
Please take a look at the email. I can provide any further information you need.
R
We continue to have problems keeping a stream up with Wowza (and other viewers) orginating from an Axis IP camera transmitted over cellular link using RTP/RTSP. It is sporatic at best. No problems if it is http tunneled or sent mjpeg to another viewer or software.
When viewing the stream through Wowza on a client flash player and observing the stream in WS, immediately when the video freezes, Wowza sends a RTSP TEARDOWN command to the camera, or possibly vice-versa.
Reviewing the sequence of packets just prior to the command being issued, there is no indication of a problem and the video looks great. We see no packet losses reported at the time the video freezes either as per the Wowza log.
TCP jt400 > rtsp [ACK] Seq=3178 Ack=1279962 Win=65535 Len=0
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3143, Time=2137502535, Mark
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3144, Time=2137514547, Mark
TCP jt400 > rtsp [ACK] Seq=3178 Ack=1280292 Win=65205 Len=0
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3145, Time=2137523556, Mark
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3146, Time=2137532565, Mark
TCP jt400 > rtsp [ACK] Seq=3178 Ack=1280557 Win=64940 Len=0
RTSP TEARDOWN rtsp://68.25.195.214:554/axis-media/media.amp?videocodec=h264 RTSP/1.0
From Wowza’s side, could you please explain the exact criteria that Wowza “sees” for it to issue the RTSP TEARDOWN command, which obviously terminates the session?
Is it a timing sequence, a flag from the camera, etc? Maybe that could help us diagnose further and solve the problem.
Thanks
Can you turn on debug logging (edit conf/log4j.properties and change the log level on the first line from INFO to DEBUG), reproduce the problem and send me the logs. I would like to see what is going on. Try to delete the log file before collecting the debug data to reduce the amount of junk that is irrelevant in the log file.
The main reason we would shutdown the connection is if the stream timed out. This means we did not receive any video/audio for longer then the streamTimeout value. We also shutdown the connection if we get an TCP acception. The debug logs should indicate why.
Charlie
The requested information has been forwarded to you at support@wowza.com thanks for your continued support.
Richard
© 2007–2024 Wowza Media Systems™, LLC. All rights reserved. Security & Privacy PolicyLegalSystem Status