Web cams/streaming video/internet video...speed? limitations? and other ????'s

[Tunni]

Yet another bloody technology I nothing about!!! But I'll bet you guys can educate me. Could some one explain the basics of web cams and streaming video. I'm a TV cameraman and reasonably OK understanding tech stuff.

perhaps if I ask a few questions, you'll know where my lack of knowledge is.

If I feed a camera into my computer using firewire and get a picture on screen can I 'feed' these live pictures to anyone with a computer? (If I sound like a complete dummy with any of these questions, please just humour me with an answer) Assuming I can I bet there are a whole load of factors, involving frame rates, compression, speed (bandwidth?) etc that limit the whole process?

What happens if not one but several or loads of people needed to view this live footage...how does that work and what are the implications regarding the frame rates compression etc?

What if the feed was not live but a video recording...how does this fit into the set up....

I think you will see, where my lack of knowledge is from the type of questions I'm asking. If someone could enlighten me I'd be very grateful

phil

[Gary MacKenzie]

we don't use pc's to stream , we use tandberg 800 videoconferencing units.

whatever is being seen by the tandberg can be streamed from it ( we can feed video tape , video cameras , visualiser units , pc's vga output ), by calling up the tandberg by ip number i.e http://10.199.100.100 and the web server running on the tandberg then streams using a choice of file types.
realvideo
quicktime

this streams realtime , you can't timeshift.if you join 5 minutes late , you missed the first five minutes.

i , as the support tech , stream from the boxes to check what is outgoing and can also remote control those boxes from the webfrontend.

the advantage of this is that so far we havn't maxed out our streaming capability from one of these boxes.

using pure ip video conferencing there is a max no of connections.
using streaming we haven't maxed out yet.


if you tell us what you want to do , how much you are willing to spend , i'm sure people could come up with the best setup(or at least ones that work for them )

[ps]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Tunni:

If I feed a camera into my computer using firewire and get a picture on screen can I 'feed' these live pictures to anyone with a computer?


No. Firstly you need some software that can accept input from your firewire card and secondly encode the signal to a streaming format. Trying to pump DV footage out over a network would kill ya bandwidth. For stability you should really look for one of the specialist card, such as those from Osprey Video. (they have versions from composite, y/c, firewire up to SDI)

Encoding: All the card really does it gives the processor a signal. That then encodes it (this way you can easily upgrade your encoder software, no hardware changes!) Windows media encoder, Real encoder, Quicktime (encoder on a mac only). Then.....


Assuming I can I bet there are a whole load of factors, involving frame rates, compression, speed (bandwidth?) etc that limit the whole process?


Yes. Datarate, file format, bandwidth, multiple data rates, processor speed, unicasting, multicasting. Gets a little complicated here, but straight forward once you get the hang of it. There is no one solution, it depends on your source material and your output. If you can give more details we can give suggestions.


What happens if not one but several or loads of people needed to view this live footage...how does that work and what are the implications regarding the frame rates compression etc?


Quick explaination. Unicasting. 1 source to 1 client. If 2 clients, then multiply datarate by 2. If 50 clients, mulitply by 50 etc etc. It is a point to point method so not good for datarates when using a live source. This is where multicasting comes into its own. Basically it is like a TV broadcast. Lots of people all listening to 1 source. Upside is you only have 1 stream, so only 1 overhead on bandwidth. Downside. Your routers must support class D IP addresses and your network provider must support multicasting. Not all do this as it has to be set right to stop easy access to hackers. To really do it properly you also need to be able to do marked packets, whereby a video data packet is marked so that when it comes to a router it is immediately put to the top of the queue and non-time-vital traffic such as e-mail and file transfers have to wait. Bit like the emergency services going through traffic lights etc. Again I can explain more on this is you want. If you set up is anything like ours it can start to get very complex with multiple unicast and multicast streams depending on where a signal is going.


What if the feed was not live but a video recording...how does this fit into the set up....


It doesn't make any difference. You source can be from a camera, from a VCR, hell you "live" source can simply be a file on the encoders hard disk that is already encoded correctly and all machine is doing is pumping it out in real world time.

I can't think of any encoders of the top of my head that need a black and burst, so as long as it is downstream (though logic would say it is at the end), then it will work fine.


I think you will see, where my lack of knowledge is from the type of questions I'm asking. If someone could enlighten me I'd be very grateful

phil<HR></BLOCKQUOTE>

We use PCs to stream as opposed to tandbergs, but basically it is the same idea, just different hardware. The PC encodes the video and broadcasts it to a streaming server that simply sends it on over IP. Servers are controlled remotely over the web. The encoder is controlled by VNC. I believe there are remote ways of controlling the server, but VNC is fine.

Our system runs 23 sites and 1500 users and although we have lost sites before when the WAN connections have been overloaded by normal file traffic, on the whole it works well. I guess like the tandbergs, with our system it is irrelevant if you have 1 person viewing or 1500, it is still 1 stream of data

[This message has been edited by ps (edited 21 March 2003).]