Re: video streaming

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Yossi Yosefi" wrote:
>
> Hi Jeremy,
>
> Thanks for the reply, it's very helpful.
>
> Here are some more specific info about the project.
>
> 1. There is a direct link between the compute (nic) and the camera, no
> sharing.
>
> 2. I choose gigabit for the same reasons you described.
>
> 3. The camera is using a specific video format for example
>
> packet
> -------------
> packet header
> line header, 16 bits pixels (data)
> line header, 16 bits pixels (data)
> ...
> ...
> line header, 16 bits pixels (data)
>
>
>
> packet header (max 8 or x lines)
> --------------------------------
> sync (0x55, 0xaa), frame count, lines in frame, line size,
> lines in packet, bits per pixel,
> first line count (incremented by x or 8), lines data (pixels)
>
> line header
> -----------
> sync (0x55, 0x33)
>
>
> btw, the camera hardware can't compress the data, so i have
> to handle all the ~18.5MB
>
> 4. There migth be an option that the camera will send the data using
> tcp.
>
>
> few questions
>
> 1. do u think i should use tcp instead of udp, if there is direct
> connection ?

If you're not going to be streaming over the Internet (and at that datarate,
there isn't a snowball's chance in hell, so perhaps this is a moot point),
then there's no compelling reason to use UDP.

If your network isn't lossy (like the Internet, wireless networking,
powerline networking, etc.), then there's no compelling reason to use UDP.

If I were you, I'd use TCP instead of UDP for the following reasons:

1. With TCP, in the very unlikely event of packet loss on your gigabit
network, you'll automatically retransmit the information with almost no down
time.
2. The latency of a gigabit connection over a LAN is going to be totally
besides the point; there's no need to eliminate TCP to minimize latency
issues.
3. CSocket is much, much simpler to use than an RTP library. You can
probably double your development time if you decide to go with JRTPLIB.
Alternately, were you to use a UDP socket, you'd probably be rebuilding a lot
of the functionality that TCP provides to ensure quality of service.


> 2. do u think i can hadle 50 frames per second (save & display) without
> loss of data at all.

Yes, so long as you have good NICs. Although gigabit's maximum throughput
is theoretically 100+ MB/sec, in practice people often get more around 20-35
MB/sec. Using good hardware generally gets you better throughput--using
jumbo frames generally nets you very good throughput, but you'll need jumbo
frame capable NICs and if you're going through a switch, that'll have to
support jumbo frames as well. You'll want Intel gigabit NICs (don't skimp on
your gigabit NIC--you'll be sorry), and make sure you have some beefy
processors (preferably hyperthreaded/dual core P4s or something similar) to
receive the stream, since parsing through that many TCP packets can be pretty
intensive.

Lastly, if you're planning on *saving* the stream, make sure you have a big,
fast hard drive. I'd recommend a 400+ gigabyte hard drive formatted with
NTFS (no FAT!). Even with that, you're going to eat up ~1.1 gig per minute.
It'll be half that if you do a conversion to 8 bpp, but even that is
ridiculously huge.

> btw, i have to proof possibility and then i can continue with the project.

I think the project is totally feasable; that being said, I really don't
understand the need to send uncompressed data over a network and it sounds
like you may be working with very little CPU on you camera--are you sure the
camera can sustain that datarate over the network, and does your camera have
a gigabit ethernet interface? If the camera doesn't have a gigabit phy, this
won't work...

And are you sure you can't run a JPEG library on the camera? Most network
cameras I've seen have at least enough processing power to do MJPEG, if not
MPEG2, MPEG4, and I've even seen WMV9. It seems sort of strange to make a
solution like this, given that it'll never function on anything but a gigabit
network.


> Any ideas of how to design & | implement & | refer to examples/links
> would be very nice.
> should i use multithreading, directx, directshow..... ?????

You don't need DirectShow for this. You could use DirectShow, but I think
it'd be much simpler to not involve it, since you'd have to write a custom
source filter containing your networking code. I'd imagine you can do
rendering with GDI or GDI+ if you wanted. If you want to re-encode the video
to something else, you'll probably have to use DirectShow or the WMFSDK.
Additionally, DirectShow provides some more advanced rendering capabilities
and provides video synchronization (based on the timestamps for the samples,
it'll automatically handle display for you).

For CSocket, see here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_MFC_CSocket.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Windows_Sockets_in_MFC.asp

A google search for GDI or GDI+ has an obscene amount of information.


> I have to solve this (my work depends on it)
>
> Thanks.

Just make sure your camera can actually output the video stream, and after
that, I'm positive that this is technically feasable. I'm still skeptical
that your camera hardware has gigabit ethernet and is capable of outputting
that much data, while not being capable of doing MJPEG compression. That,
and the whole project sounds suspect to me; I think there are plenty of
cameras capable of much better performance than the one you're using.

--
My Site (under construction): http://deepsea.no-ip.com/AV/



.

Relevant Pages

  • Re: Why cant I get my firewire IEEE 1394 to detect with Windows XP
    ... will just re-find it and reinstall the connection next time you restart. ... You can network via firewire...... ... >>> After all this I connected the Dv camera and suprise windows doesnt ...
    (microsoft.public.windowsxp.video)
  • Re: Utah Mine Disaster and Robots
    ... and promptly abandoned it when the camera they dropped down it didn't ... practical with a small flying vehicle. ... If I were designing such a robot for this job, ... network configures itself. ...
    (sci.electronics.design)
  • FAQ-What is a network camera?
    ... Network Cameras are vastly becoming the next generation in video ... Web camera, is best described as a camera without the need for a computer. ... A network camera can be administered and its images viewed using a standard ...
    (alt.security.alarms)
  • Re: Utah Mine Disaster and Robots
    ... and promptly abandoned it when the camera they dropped down it didn't ... If I were designing such a robot for this job, ... network configures itself. ... connected to a power and comm ...
    (sci.electronics.design)