So I am confused. Is it all working now with the most recent version of gstreamer?
Charlie
Upgrade the most recent patch:
http://www.wowza.com/devbuild.html
I believe it only works with the most recent version of GStreamer.
Charlie
How long does it take for it to go out of sync? RTCP is used to synchronize the video and audio but is only needed to initially sync the stream. MPEG-TS synchronizes the audio and video in the stream (all streams run on a 90KHz clock and are pre-synchronized). Not sure why your stream is going out of sync.
Charlie
- why do i need to restart the server after stopping and restarting the (publisher) streaming process ? Is there a workaround ? If i do not, the flash player only shows a black screen
It is because when the encoder starts/stop it changes the time basis which screws up Wowza Pro and Flash. There are two methods to work around this. Take a look at the sdpFileCheckFreqency and streamTimeout properties as discussed in the Native Real-time Transport Protocol (RTP) Streaming section of the User’s Guide. You can setup Wowza Pro to monitor the SDP file for date or size changes (sdpFileCheckFreqency) so the stream is restarted when the SDP file changes. You can instruct Wowza Pro monitor the stream for long breaks (streamTimeout) and restart the stream if needed. The streamTimeout is tricky to get right since if it is too short it will restart the stream when it first tries to connect if it can’t find a key frame quickly enough.
audio plays back faster
my audio tests samples (voice/claps) seem to have a direct effect on drifting speed ! If i speak longer, the desync comes faster !
This is a tough one. I just don’t have the resources to dig into gstreamer and debug something like this. I know there are plenty of RTP based encoders where there is no issue with AV sync. So it is most likely not a Wowza Pro issue. There may be rounding issues in GStreamer. I have seen this problem in other encoders where they don’t deal with timecodes properly and they calculate time differentials which insert small rounding errors that add up over time.
Charlie
Great!
Charlie
These type of issues are usually due to av sync issues. Take a look at this post to see if any of the suggestions here help:
http://www.wowza.com/community/t/-/57
Charlie
I have personally not had much luck with gstreamer. Other then what I have suggested I do not know any magic bullets.
Charlie
I changed the resolution to 640x480:
gst-launch-0.10 -vvv videotestsrc ! capsfilter caps=“video/x-raw-yuv, format=(fourcc)I420, width=(int)640, height=(int)480, framerate=(fraction)30/1” ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! udpsink port=5000 host=127.0.0.1 sync=false
Now i’m getting these messages (again, using systemclock sync):
DEBUG server comment - FU-A: end:false tc:3371173062 st:true
DEBUG server comment - rtp[video:212] {80 e0 05 8f c8 f0 04 c6 3f e9 f1 e0 5c 41 ee c5 }
DEBUG server comment - FU-A: end:true tc:3371173062 st:false
DEBUG server comment - rtp[video:14] {80 60 05 90 c8 f0 10 7f 3f e9 f1 e0 09 30 }
DEBUG server comment - SINGLE: end:false tc:3371176063 sz:2
DEBUG server comment - rtp[video:1400] {80 60 05 91 c8 f0 10 7f 3f e9 f1 e0 5c 81 9a d9 }
DEBUG server comment - FU-A: end:false tc:3371176063 st:true
DEBUG server comment - rtp[video:512] {80 e0 05 92 c8 f0 10 7f 3f e9 f1 e0 5c 41 7a e5 }
DEBUG server comment - FU-A: end:true tc:3371176063 st:false
DEBUG server comment - rtp[video:14] {80 60 05 93 c8 f0 1c 36 3f e9 f1 e0 09 30 }
DEBUG server comment - SINGLE: end:false tc:3371179062 sz:2
DEBUG server comment - rtp[video:1400] {80 60 05 94 c8 f0 1c 36 3f e9 f1 e0 5c 81 9a dd }
My questions are the following:
- can i assume that wowza is getting video frames correctly ?
- is it possible to get detailed comments/explanation about the debug messages ?
The SDP data does not contain the sprop-parameter-sets parameter. This line usually looks like this in the SDP data.
a=fmtp:96 packetisation-mode=0; profile-level-id=42801e; sprop-parameter-sets=Z01AHuigsPbB6kBAQGQkAAADAAQABX5BgAAHoQAAFuNm974PihM0,aP91IA==
Without this information Wowza Pro must hunt in the NAL units of the H.264 packets for this data. It can’t start video playback until it finds this information. This information is not always contained within the stream.
I really don’t have a specific answer for you. I just know that this is what it seems to be searching for.
Charlie
First, try it with Wowza Pro 1.5.1. You can download the upgrade patch here:
http://www.wowza.com/devbuild.html
If that doesn’t work, follow these instructions and send me the debug log files and the command line you are using:
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.
Charlie
Here is SDP data from Wirecast:
v=0
o=- 1798860268 1798860268 IN IP4 127.0.0.0
s=Wirecast
t=0 0
a=range:npt=now-
m=audio 5432 RTP/AVP 96
c=IN IP4 127.0.0.1
a=rtpmap:96 mpeg4-generic/32000/1
a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1288
m=video 5434 RTP/AVP 97
c=IN IP4 127.0.0.1
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=4D400C;sprop-parameter-sets=J01ADKkYKD9gDUGAQa2wrXvfAQ==,KN4JF6A=
a=cliprect:0,0,240,320
a=framesize:97 320-240
b=AS:200
It looks like the backslashes could be a problem. If you want me to look at debugs to see if it is a key frame problem, I can.
Charlie
Be sure you are properly setting the “M” bit in the RTP header of the video packets. We require this so we can identify the starts of packets.
Charlie
First, be sure to upgrade to the latest patch (patch33) from here:
http://www.wowza.com/devbuild.html
Next, send me the entire debug log so I can have a look at it (charlie@wowza.com).
Charlie
I don’t know gstreamer very well. Is this doing a transcode to H.264? What happens when you try to play this stream using VLC player. What is the type of the audio/video in the “Stream Media Info” dialog box in VLC?
Charlie
I think you have been contacting me directly over email. I suspect that the problem might be with gstreamer. The fact that you do not have a reliable stream working with VLC is suspect. I would work with the gstreamer team to try and get reliable playback with VLC first. Once you have this working then move on to Wowza Pro and Flash. I suspect that the audio packets are not properly formatted in the RTP packets. You might also see if there is an option to turn off the CRC byte. We have had problems in the past if the CRC byte is turned on.
Charlie
Then try changing the SDP data to this:
v=0
o=- 14770170187368070364 14770170187368070364 IN IP4 c3dpcws004
s=Unnamed
i=N/A
c=IN IP4 10.218.35.135
t=0 0
a=tool:vlc 0.9.6
a=recvonly
a=type:broadcast
a=charset:UTF-8
m=video 1234 RTP/AVP 96
b=RR:0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1
a=fmtp:96 profile-level-id=3;
We cannot handle the config data as it is presented in the SDP file. We should be able to extract this data from the stream if it is not present in the SDP file.
Charlie
GStreamer tends to use AUD NAL units. For some reason with this setup it is actually sending SPS NAL units which include video data. I have never seen this before. I will need to better understand this.
Charlie
I made a change that enabled it to work when using the test pattern. So in the most recent version the following gstreamer command line works:
gst-launch-0.10 -vvv videotestsrc ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! udpsink port=5000 host=127.0.0.1 sync=false
This continues to work for me. I have tried gstreamer in other situations where it does not work due to the problems I described above.
Charlie
