"www.hiebun.com" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Hi,
> I posted as below.
>
> >Hi all,
> >I programed to send compressed video data from a network camera to a >PC.
> >The network camera system sends in real-time a 11KByte video frame and
This I can buy into -- it's a pretty good rate
> >ten 500Byte video frames a second
I find this hard to believe even with a 1 bit (b&w) image. Are you
sure this is all you're sending? I _must_ be missing something.
> >So it sends data less than 200 Kbps in transport layer level (UDP
> >protocol).
Ah, but it's _compressed_ data. What codec?
> >But on Ethernet it consumes almost ten times bigger bandwidths.
In what sense and how do you know?
> >I can not hook more than two network cameras on 10 base Ethernet and
> >more than 10 network cameras on 100 base T Ethernet.
Remember, all this steady, unrelenting video stream is battling for
network resources with everything else (and each other) on the network
-- and it must squeeze through a router or switch. Also, any device
that operates in half-duplex will halve the nominal throughput on
average. The path from video cam to monitor must maintain full-duplex
operation at every link.
> >
> >If I am not wrong, Ethernet has too much overheads to transfer data.
Web cams routinely transmit video across the globe over the internet
and eventualy streams it through end-pipes much narrower than 10Mbs.
UDP minimizes the overhead. Ethernet simply frames the data given to
it and couldn't care less or help in any way what's sent. It's a
_shared_ media with managed _contention_.
> >Did I miss something or have mis-configurations?
> >
> >Any idea to optimize them?
> >
> >Regards,
> >bkna.
>
> Now I found some.
> Even 14 cameras are sending to one monitoring PC, network is not over full.
Still not sure what you mean by these network usage references.
> If this 100 base Ethernet network has 7 network camera then works well
> without any video image missing.
>
> I splitted them has half like 7 cameras on each two different networks
> (192.168.0.xxx and 192.168.1.xxx).
> But still the monitering PC miss packets. So some video image are
> missing on screen.
Packets are being dropped because they are piling up in a queue
somewhere faster than the device (router? switch?) can dispatch them.
You may have to monitor every link to find the pinch point(s).
> I first time guessed that PC need more computing powers.
> But CPU on PC has more than 50% idle (3Ghz Intel CPU).
>
> So now I think network and PC's computing powers are not the point.
> Then PCI bus has overheads?
>
> How can I solve it?
>
> bkna.
Think you'll have to look at your router/switch docs to see how they
can most efficiently handle a video stream -- will likely require some
trial & error configuring to handle contention/usage patterns. You
may have to place the video steams on their own subnet or even their
own network.
Network RSVP (Resource Resevation Protocol) with IPv6 is usually
required to get QoS that is fairly dependable across varying
conditions. Video and VoIP are the two that need it the most. With
as many cams as you're trying to feed into a monitoring station,
you'll need a big league routing protocol and very fast hardware in
your network devices.
Or only send still frames every 3-5 seconds (or some other reduced
rate delivery means).
You might want to google to try to find some pointers for what you're
trying to do with the equipment you have to work with.
hth,
prg
email above disabled
|
Similar Threads
Linear Mode
