i still have the solution to stream to both quicktime media server and wowza from wirecast 
the problem with player upgrade is that it will not work if the user dont have admin privileges (ie at office, and it s often the case in large companies )
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.
designzoo, it sounds like you’re pushing it out over DSL… While your upstream is nominally 768K, the realities of consumer-grade (and SOHO-grade) DSL is that you can’t count on that upstream to be consistent enough to push a stream.
Using the latest AMI yesterday, it’s still desynced. I’ll try the config settings you suggested.
Load on the encoder is around 30-40%. We’re also recording a stream to disk, and sometimes that will cause the frame rate to drop below nominal 15fps, even though CPU isn’t maxed, but it causes a “max headroom” effect on the clients. I suspect this is in part due to using TCP vs. UDP, but on UDP I expect the effect would be dropped audio rather than hearing the same audio sample repeated a few times.
Is setting up in an edge/repeater likely to help or exacerbate the problem?
Charlie, The sorting doesn’t seem to have had any effect.
I am not sure I really understand the question.
Forget about this, I’ve done this using their C# API :
1/ Prepare all the medias in WC GUI,
2/ Get them in a C# app,
3/ Select first one then start broadcast,
4/ Add a timer which duration is media length,
5/ Switch to next media when timer ends,
6/ And so on until all medias are played, then get back to 1st one.
With C# app, I can alter “playlist”, even switch to “real” live feed from capture card …
Problem is WC encoding is really really poor, VLC is much better. I need WC transitions and VLC encoding
We’re using wirecast 3.5.5 (11826) and Wowza Media Server Pro10 1.7.2 build12107
I dont have a metadata event fired so that is impossible to know what the size of the incoming video is. I read that this was fixed in patch19 but it seems not be the case.
Thanks,
Joe
We setup wowza EC2 and downloaded Wirecast, we have tried streaming at h.264 at 100kbps,200kbps and 300kbps, they quality is terrible at the low data rates yet the higher bit rate streams are stuttering.
Our internet connection is about 6MBs download, 0.6mbs upload rate so should handle it no problem.
How can this issue be resolved? We need the highest quality stream we can get, we have used both a webcam and a dv camera as the input device.
Please reply.
Hi Charlie - We made the changes and saw about a 1-2 sec improvement but still quite a delay. The wirecast machine runs around 69 to 84% load in Vista. Any further ideas?
So let me understand. You think the out of sync issue is due to the Wirecast encoder, correct? What is the cpu load when you run the encoder?
One thing to try is to install the most recent patch from here:
http://www.wowza.com/devbuild.html
Then in conf/[application]/Application.xml add these properties to the properties:
<Property> <Name>sortPackets</Name> <Value>true</Value> <Type>Boolean</Type> </Property> <Property> <Name>sortBufferSize</Name> <Value>250</Value> <Type>Integer</Type> </Property>This will sort the packets server side before sending them to the Flash client. With this in place you should see a log entry that looks like this:
sortPackets[stream-id]: sortBufferSize:250
Charlie
Charlie we got Wirecast and Wowza working now in live stream with about 1-2 secs delay. So thanks! Now my question is - how can get the video clear? I have tweaked settings on wirecast from medium to high quality and on key frame and other such settings. It seems no matter what we try - the picture seems fuzzy and on edges for objects a bit pixelated. In the wirecast preview desktop it looks sharp. Any suggestions?
As a separate question - do you think delay will be gone with flash 10 gpu acceleration?
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
