We have tried different settings in Wirecast for frame size and changed it the browser too without much success. Any suggestions as we want to get crystal clear sharp live h.264 video. We moved wirecast to a quad core intel with 4 gigs so there’s no cpu load issue. If wirecast’s encoder is not up to what we need - what would be our best bet to get really sharp video live?
Hi ianbeyer and charlie,
The biggest hitch we’re running into is that we have to delay our audio 330ms (10 frames) upstream of the encoder for it to arrive in sync at the client. While this workaround generally works (and we need to make sure that any video content we play from within Wirecast is also delayed by 10 frames)
I can confirm out of sync issue with wirecast. Since we do not have any solutions at the moment (we have low experience with wowza at present time), I would kindly ask (ianbeyer) if you can share your workaround on syncing the audio/video which client receives. Can this be done within wirecast?
Best regards
Matej
Hi,
I am looking for information how to set up this new functionality (RTMP: Wirecast to wowza). Could you please redirect where can I find it? (I think the first forum post of this threat wasn’t updated with this information)
Thank you and best regards
The biggest hitch we’re running into is that we have to delay our audio 330ms (10 frames) upstream of the encoder for it to arrive in sync at the client. While this workaround generally works (and we need to make sure that any video content we play from within Wirecast is also delayed by 10 frames), at some point we’re considering offering a simultaneous Windows Media stream, which is perfectly in sync without the hardware audio delay.
FYI, I have the exact same A/V sync issue with Wirecast that you describe. Since it happens when streaming through QTSS, or even the built-in streaming server of Wirecast, it is NOT related to Wowza. I had reported it to Varasoft before Telestream took them over, but I haven’t reopened the ticket since then. We are currently using a Metric Halo MIO 2882 +DSP (lots of delay, and other audio processing power) to delay the audio before bringing it into Wirecast.
We’re using Wirecast to EC2, and generally we love how well it works. The biggest hitch we’re running into is that we have to delay our audio 330ms (10 frames) upstream of the encoder for it to arrive in sync at the client. While this workaround generally works (and we need to make sure that any video content we play from within Wirecast is also delayed by 10 frames), at some point we’re considering offering a simultaneous Windows Media stream, which is perfectly in sync without the hardware audio delay.
We’re running rtplive and pushing a 500K (nominal) stream at 15fps. The delay problem doesn’t seem to be related to the encoder hardware as it does the same thing whether I do it from our stream producer system at the office using Osprey capture, over the T1s or from a DVCAM deck into my laptop at home via Firewire over my cable modem.
Is there something I need to tweak in the AVSync config parameters, or is it something else?
I’m pushing the stream out over TCP via wirecast, and have the UDP range open.
We are experiencing the same problem with a similar setup. We stream from Wirecast to EC2 instance of Wowza and audio is ahead of the video for all clients. We also encode to disk in windows media format and audio and video are in sync in the resulting .wmv file. We would like a way to fix the delay without adding a pre-input delay which would put our locally encoded files out sync.
Has anyone found a solution to this issue?
Andrew
I have found that if I reduce the mpeg4 audio quality to 24kbs and 8kHz then it actually stays in sync. I have also started a thread over on the wirecast forums here:
http://forum.telestream.net/forum/messageview.aspx?catid=44&threadid=2383&enterthread=y
Hopefully Wirecast can address the issue so that we can increase our audio quality soon, but at least we can use this setup without another hardware device now.
Andrew
Telestream just released Wirecast 3.5 which includes native Flash support using RTMP. In my initial testing I am still seeing an audio sync problem, but I would like to confirm that I have modified the Wowza configuration correctly or if there is something else I should be looking at on the Wowza side. The only change from the instructions on the first page of this thread was that I set the stream type to rtp-live instead of live. I was able to get both audio and video using these settings but not in sync. I also tried changing RTP/AVSyncMethod to rtptimecode instead of senderreport which did not help.
Thanks for any suggestions you may have!
Andrew
It looks like Wirecast 3.5 is working for me now without the sync issues streaming from Vista SP1 32bit to an Amazon EC2 instance of Wowza. I am using the new native flash encoding presets in Wirecast to stream RTMP using H.264 video and AAC audio if you want to update the original tutorial post. See the linked thread above for more details.
Also, the new release of Wirecast lists the following fix among others:
Improved quality/data-rate handling of QuickTime H.264 on Intel machines
My video quality definitely looks much better now using the same encoder presets so those of you trying to do higher quality streams may want to check out the new version of Wirecast.
Andrew
RTSP is covered but RTMP using the new flash settings in Wirecast 3.5.1 is not covered yet. Charlie mentioned earlier he was going to update the tutorial, but here is a quick and dirty description of the steps.
Really the only thing you have to change from the defaults in the wowza application.xml file is the streamtype which should be set to “live”.
On the Wirecast side you can use one of the included Flash presets and then fill in your destination info in the following format and start streaming:
Address: rtmp://server.name:1935/streamname
Stream: myStream.sdp
Andrew
Thanks for the update. I will update the forum post for this new functionality.
Charlie
Any progress on getting the original post updated? The RTMP method is definitely much better than the RTSP instructions at the start of this thread.
Andrew
See previous post numbers 56 and 60 in this thread for the details, but the new 3.5.x version of Wirecast supports RTMP flash natively instead of via RTSP. Using the new method resolves the sync problem several of us were experiencing, but when I tested sync was still an issue using the old RTSP method.
Andrew
Thanks for that, I’m sure it will be helpful for new users trying to get started. Also thanks for the sortBuffer info. Our flow is currently working with RTMP, but it’s good to know about the possible sync fix on the RTSP side.
Andrew
It looks like you are using the wrong http url on the iPhone side. The url should be:
http://[wowza-ip-address]:1935/live/w.sdp/playlist.m3u8
Thanks, Charlie. That’s it. And, btw, it was super-freakin’ easy to get setup!
I start the encoder (Wirecast) and connect with Safari on an iPhone.
However, I get “stalled” segments about every 12 - 36 seconds, with the
“hang” lasting 10-20 seconds. I seem to see more dropouts when there
action in the shots (we’re wanting to stream live horse races). So, a
couple of 12 second stalls in the middle of a two minute race is a bit
unnerving.
I’m still using:
Wowza 2 Advanced Preview 6
Wirecast 3.5.4
I have 2 GB RAM on the development server. So I set JAVA_OPTS="-Xmx1200M" in startup.sh
and ulimit -n 20000 in the setenv.
I’ve bumped Wirecast down to a lower audio encoding rate, 12 fps
(quality medium) 320x240.
I also tried setting ModuleMediaCasterStreamManager in the
./applications/live/Application.xml file, but got this error and removed it:
[HTML]
ERROR server comment - loadModFunctions: java.lang.ClassNotFoundException: com.wowza.wms.plugin.mediacasterstreammanager.ModuleMediaCasterStreamManager[/HTML]java.lang.ClassNotFoundException: com.wowza.wms.plugin.mediacasterstreammanager.ModuleMediaCasterStreamManager
If anyone has any suggestions of things I should try, I’d appreciate it.
We’re supposed to do a “live demo” in 10 days, and I’d like to resolve
this issue with playback stalls before we do the presentation.
Thanks, folks.
-Kurt
Thanks rrlanham,
Setting keyframe=24 appeared to somewhat reduce the
occurrence of a stall --but not completely-- with these
settings in wirecast:
- 320x240 12fps, keyframes=24, medium quality
I was able to get a good 15 minutes of uninterrupted
video at one point. However, After restarting the server
and wirecast, the stalls reoccurred.
Thanks for the suggestion on the keyframe. I really appreciate it.
Just an FYI for anyone reading this, my “live” stream runs
50 - 60 seconds behind real time.
Next…
- Try some server tuning options, and
possibly move the encoder to a more powerful server. (?)
-
It would be a preferable to push a higher ‘quality’ image. try it.
-
get multiple bitrates to work and test
-
think about scalability
Thanks again, rrlanham. And, thanks a million to Charlie
and the other Wowza’s! I’ll keep on this and report
back.
-kb
Is it possible to (easily) encrypt rtsp streams (from wirecast or any ip camera) just like rtmpe does?
Does anyone know how to fetch the credentials sent by wirecast on the server side? It doesn’t seem to be mimicking correctly the netConnection#connect() method and parameters.
Let’s focus on rtmp for now. In wirecast there is an input box where I can enter login/password for getting authenticated on the server.
Now on the server side how do I fetch these credentials back? In IModuleOnConnect#onConnect I see an AMFDataList params, but the credentials are not in there.
So how does wirecast pass the credentials to the server and how to get them back on the server side? 
Thanks
Oh that seems complicated. I was simply expecting Wirecast to send the credentials down the Actionscript netConnection pipe with something like:
net_connection.connect(“rtmp://myserver.com/myapp/123”, “my_login”, “my_password”);
Unfortunately it doesn’t seem to be the case 
But people using wirecast in this thread do use authentication, so how do they handle it? Only by rtsp?