Video Design to an ethernet 10/100 4

[DanielJackMorley]

I am looking to have a video chip (MT9V032) to a coldfire processor (66mhz) which is connected to a 10/100 Ethernet port. I am trying to develop a system to display this image onto a web page. It needs to be at least 60 frames per second. I have little familiarity with video and am worried that the 100 Mbit/s limitation would impact the upload speed to the computer screen.

 

[IRstuff]

Just compress the video. We've run 30-Hz video on as little as 900 kbps, but it will be severely compressed. You need around 200 Mbps to transmit uncompressed VGA.

TTFN

FAQ731-376

 

[DanielJackMorley]

Sorry to sound stupid but how does one compress video? Is this a firmware procedure.

 

[zappedagain]

Firmware or hardware. Google for 'image compression' or maybe 'video compression', MPEG, MP3, etc.

John D

 

[IRstuff]

It can be either firemware, hardware, or even software, assuming your processor is fast enough, and isn't too busy.

TTFN

FAQ731-376

 

[MacGyverS2000]

IR's comment about 900kbps for 30 fps video is also based upon a specific frame size... smaller picture, reduced bandwidth requirements. I've done some amazing video using wavelet compression and only a couple hundred kbps, but it required a lot of horsepower at the transmission end (significantly less at the receiving end).

If you have to ask about it, hardware is your only choice as software is going to be way out of your league. Have you thought about how you intend to wrap the video? You can't just send raw data to a webpage an expect video to pop out... you need something like a Quicktime wrapper, or an MPEG decoder. Since you're not capable of writing the software portion of it, the choice of wrapper will dictate the type of hardware compression you use.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[VEBill]

What you're asking about is to encode and stream the video. For a one-off project the simplest way to accomplish this is to purchase the $100 box that does the job. Hardware solutions will often be expecting analog video input. But it really sounds like your situation is not quite the same.
But that leads to the questions. Does your system start with a camera? If not, then why are you creating video and sending it? Why not just send the data? If there is a camera (real video), then why not skip the processor and just encode the video? Are you overlaying text onto video? If so, the more modern approach is to insert metadata into the stream. Then the overlay text can be selectively displayed by software at the far end.

Depending on exactly what you're doing, there may be much simpler approaches. Apologies in advance if I've misunderstood.

H.264 gives very good picture quality (for NTSC video) at 2 Mbps. It even looks good on a laptop screen (blown up 4:1 by pixels). We don't see any compression artifacts, except (obviously) when the signal drops out.

 

[DanielJackMorley]

I am trying to send an image to a PC for a web page. The chip a am looking at for the sensor is MT9V032. I have a processor for other applications unrelated to the video. My current solution is to use the Ethernet port on the chip to send bit data It is possible that I could use another method to send the bit data directly to a router. But the hardware/web interface is already realized and that would be the ideal solution.

I am mostly a hardware guy but I do have the IP/stack already written by a third party. The web page hardware interface already works and the video design and web software engineering is new to me(computer end not firmware).

Is the wrapping done in the firmware or in the PC?

The Ethernet port ideally can handle 12.5 MBytes an sec. I am using other features so I need a little room for other features (although not much). The chip I am looking at has 360,960 pixels.

I need a steady image because I am trying to remotely pilot through the internet. The size and the resolution I am still trying to understand. I think I need a tutorial on video design. I believe 60 frames per sec is needed. How to get from 360,960 pixels to frames I don't know.

 

[MacGyverS2000]

You probably only need 30fps for remote piloting underwater (you're not moving THAT fast). The PC hardware is going to expect data in a specific format... since you've already chosen it, the determination of what wrapper to use has already been made. It will be done at the robot end as that's the transmitter.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[VEBill]

For remote piloting, make sure you pay attention to end-to-end latency. If it's not considered, then it can build up to unacceptable delays.

Reading between the lines, are you conceptualizing "inserting" the video "into" the webpage at the ROV / server end? As you may already know, the video is normally streamed separately, and the webpage just contains an HTML chunk to make that happen. By way of clarification, the webpage is normally TCP, while the video stream might be better transported as UDP. Apologies in advance if that's already clear to you.

If so, then you're back to simply trying to encode and stream the video. The processor at the ROV end shouldn't get involved in processing the real-time video bits. But absolutely might be involved in multiplexing and transporting the packets (probably enough to keep it busy).

 

[DanielJackMorley]

I can see the advantages of using a UPD. (no handshaking means more information that can be sent). The system is already set for IP. I guess what I need right now is how to model the data stream and pro's and con's regarding compression techniques. 360,960 pixels can translate to three times that value per sec. This device is not operate underwater so picture quality is not as important as frames per sec. I would like to have the maximum picture quality with the frames per second being adequate. Correct me if I am wrong and what factors I am not thinking about.

non color

360,960 x 1 = 360,960 bits per sec

360,960 per 60 frames = 21,657,600 bits a sec


color 3x 21,657,600
64,972,800 bits per sec

which trans late too 8 Mbytes and 2.7 Mbytes per sec.

How much I loss if I use UPD verses IP.

 

[VEBill]

For TCP/IP compared to UDP/IP, see:

http://www.skullbox.net/tcpudp.php

For your own point-to-point wired LAN, data loss even with UDP/IP should be essentially zero.

The assured delivery "advantage" of TCP/IP only helps if you buffer data to span the gaps while it tries again. Buffers are latency. Latency bad. Variable latency is even worse.

 

[IRstuff]

You are off by a minimum of a factor of 8, i.e., mono 60Hz video ==> 752*480*60*8 = 173 Mbps

RBG is 3 times that.

TTFN

FAQ731-376

 

[benta]

Look at Conexant, they have hardware MPEG-2 encoder chips that I have seen in action, they work very well.
For a 720x480, 30 fps in full colour, they will compress down to 6 Mbps.

Benta.

 

[VEBill]

There are similar H.264 video encoder chips that provide what appears to be excellent video quality at 2Mbps (+/- depending on settings).

If this is a one-off project or a prototype, then it might be a good first step to use an Ethernet security camera for the initial integration. Insert an Ethernet switch or router into the LAN, plug in the Ethernet camera, and start playing. POE would simplify the wiring. This would get the concept up and running in an easy afternoon, and probably save time and money in the long run.

 

[MacGyverS2000]

So far I'm failing to see where a COTS product is not the correct solution... webcams are dirt cheap, high-resolution, 60fps, and they often have compression built in. You're going to spend a ton of time dealing with just one on those issues when the product that uses the ready-to-go camera will be done in the same time period.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[DanielJackMorley]

I am going to be doing other things besides the web cam. But this is by far the biggest bottle neck.

 

[DanielJackMorley]

Ok, I think I understand the issue better. My current solution to this issue is to have a DSP between the VGA sensor and my processor to do a MPEG-4 compression.

New questions

How does this compression affect the 173 Mbps?

Why are DSP's so expensive and is there a cheaper solution?

Is there a dedicated chip that can do this?

 

[IRstuff]

A DSP may, or may not, be the appropriate choice to do video processing. A Texas Instruments C67 DSP, has gobs of throughput, but does not have sufficient I/O bandwidth to process video because it was actually designed for a relatively low I/O rate with lots of number crunching.


TTFN

FAQ731-376

 

[DanielJackMorley]

If not a DSP then what would you recommend?