QuickTime Broadcaster Error - Is it the Broadcaster or QTSS or network?

Question

Level 2

325 points

QuickTime Broadcaster Error - Is it the Broadcaster or QTSS or network?

I have a Xserve G4 (dual 1 Ghz) running OSX.4 Server. The ONLY thing this computer is doing is running QuickTime Broadcaster. It has a IEEE-1394 (firewire) media bridge (Canopus) attached which Broadcaster is using for an AV source. I am attempting to stream (automatic unicast over TCP/IP) a single 300k H.264 stream to Darwin Streaming Server (multi-caster) on a dedicated T1 line. The trouble I am having is keeping Quicktime Broadcaster running for long periods of time. It seems to crash or go stale after a certain amount of time. Sometimes it's hours, sometimes minutes. The only error message I get is "Broadcast Error - Disconnected (-3285)" . I have to restart the program half the time after these, the other times I just have to restart the broadcast. Any help would be great. Anyone ever seen that error message before?

Albook G4-1.25ghz, Mac OS X (10.3.8)

Posted on Sep 18, 2006 9:01 AM

Reply

Answer 1

Scott Maiden Author

Level 2

325 points

Sep 18, 2006 6:27 PM in response to Scott Maiden

Update: I am having some success since unchecking the "broadcast over tcp" option on the Network tab in QuickTime broadcaster. I'm not concerned with firewalls. I'm unicasting to a Darwin server. They turn it around in TCP through port 80 past most firewalls for me. Good service. Anyways, I can't see any reason to use TCP/IP except for firewalls. So I'm using UDP now I guess since the TCP option is now disabled. UDP is more stable for streaming right? Maybe this has explained why it was crashing so often. So far, it's been running for 12 hours now. But it's done that before. We'll see....

Reply

Answer 2

Scott Maiden Author

Level 2

325 points

Sep 19, 2006 7:00 AM in response to Scott Maiden

Update 2: Nearly 24 hours up time now using UDP instead of TCP. Not quite ready to say this problem has been "solved" but close. It seems TCP is just not robust enough for long term streaming demands.

Reply

Answer 3

MacLemon

Level 2

455 points

Sep 19, 2006 1:34 PM in response to Scott Maiden

In my experience Broadcaster goes belly up if the input source video does not change or an extended period of time. I did some live streaming this weekend from a heart operation. We used one stream from a camera source and another one from the echo-scanner display. When the echo-scanner's image was frozen on the machine and I got a still-picture for some time Broadcaster would break the upstream to our QTSS.

I was using TCP for the upstream. With 768kbit/s of video and CD quality audio on the camera stream. (Scanner stream didn't carry audio)

I've also experienced that network condition and load does severely affect Broadcasting reliability even if you use less than 1Mbit/s of stream on a 100Mbit/s switched network.
MacLemon

Reply

Answer 4

Scott Maiden Author

Level 2

325 points

Sep 19, 2006 2:59 PM in response to MacLemon

Very interesting observations... Thanks! Well, after about 28 hours, my QuickTime Broadcaster finally crashed. I got that weird discconected error message again. Had to restart the program. I too have noticed some trouble with static images. I found I could not test the stream with standard "Bars and Tone". This seemed to create erratic behavior. I wonder if this type of thing is actually a problem for the DV bridge. Maybe we're just having a glitch with that instead. I still think the UTP vs. TCP could be helping a bit. More tests will confirm. I may also test with different DV bridges too. So far the only thing I have ruled out is the format. I get crashes with MPEG-4 and h.264 of various but rates. Hummmmnnnnn.....Any thoughts?

Reply

Answer 5

MacLemon

Level 2

455 points

Sep 20, 2006 2:35 AM in response to Scott Maiden

We were using two Canopus ADVC110 Video converters as I have medical use which is allowed for these devices. This is also the reason I cannot use other video converters at the moment. We were streaming H.264 only as plain MPEG4 would not have met our bandwidth restrictions without serious danger of massive dropouts. (A different story, not QuickTime's fault.)

With a Testbild (bars and tone) I actually didn't have a problem, even for prolonged periods. Maybe because the Testbild was came from the SONY betacam we used. Quality was nothing short of stunning. 🙂 With the ultrasonic echo-scanner image locked I experienced problems with the upstream breaking after a few minutes. Maybe also because this stream was video only.

I'll try and experiment with UDP upstreaming if that helps with the disconnects.
MacLemon

Reply

Answer 6

Scott Maiden Author

Level 2

325 points

Sep 21, 2006 7:30 AM in response to MacLemon

We are using the exact same Canopus encoders. Hmmmmnnn. Maybe I will try to use a DSR-11 of a while and see if that crashes too. DSR-11's are far to expensice to dedicate to something like this project though. I'm not sure if UDP is the protocol used if the TCP/IP option is disabled tough. I think RTSP may be the exact format. Kinda surprised folks have not jumped on this thread. There has to be more people using Quicktime Broadcaster out there. If not, what other apps are people using to stream h.264 in real time? I can't even find dedicated hardware to do this. QTB and a Mac seem like the only option.

Reply

Answer 7

MacLemon

Level 2

455 points

Sep 21, 2006 7:59 AM in response to Scott Maiden

I also had expected more feedback here, but maybe folks will jump on the thread later. Let's hope so.

I don't know of any dedicated streaming hardware for H.264. But there is an alternative Product to QT-Broadcaster called WireCast. It is actually a complete digital director's studio which works extremely well. The price is not too steep for the things it does and there even is an educational discount which brings the price to a very attractive low.
MacLemon

Reply