What kind of IC(s) would I need to be able to receive and preferably decompress a 1024x768 signal, and then display it through a VGA cable?

 

Ethernet is a network and is used for packet data transmission. Can you be more specific as to the how the video signal is sent in the ethernet connection?

 

Video is usually encapsulated in a CODEC (Compressor/Decompressor) that both sides have, which runs over the TCP/IP protocol, which can run on about any physical medium (Ethernet, Token Ring, Fiber, etc)

More information is needed.

 

What is the source of the video?

 

Sorry for not being specific, I was more interested in how I would display any kind of video on the monitor, rather that how I would get it to the chip.

I hadn't thought of this before, but are there chips that are built to decompress/compress video?

 

You still aren't specific enough. Are you talking analog video or digital video? There's a huge difference in how it's processed.

 

You still aren't specific enough. Are you talking analog video or digital video? There's a huge difference in how it's processed.

Sorry I'm not just telling you guys exactly what I want to do, I feel like I have a really good idea and I don't really want to share it .

I want to be able to stream a digital video in 1024x768 over a local area network to a 'client' type unit and display it on a 1024x768 computer monitor
I can program all the networking, I just have no idea what to get so I prototype this.

 

Is the output direct digital?

The data rate you are talking about would need mild compression, something like This For video and one of these for audio. At each node. There would be extra support components required to run those chips, of course, and another for a VGA or DVI output jack.

It might be easier to do a webcast on the intranet, where everybody streams the broadcast at the resolution sent.

 

I believe that the op does not fully understand how the internet works. You cannot just purchase some chips, connect your video and audio source and drive it into a CAT-5 cable. It takes a lot more than that.

 

Thank you, thatoneguy.

Yes, I do understand how the internet works, but because you guys are more caught up on my knowledge, completely forget that I said anything about the internet.


So I have this project, it has a buffer that magically fills up with a digital video. How do I get that buffer on the screen?

 

...............

So I have this project, it has a buffer that magically fills up with a digital video. How do I get that buffer on the screen?

If you want analog VGA then you need to convert the digital video to analog and output it in the VGA format. If the digital video is in DVI-D format, then you could use a converter such as this.

 

Yes, I do understand how the internet works, but because you guys are more caught up on my knowledge, completely forget that I said anything about the internet.

So I have this project, it has a buffer that magically fills up with a digital video. How do I get that buffer on the screen?

I know you did not say internet, but you did say ethernet. When you said ethernet I assumed you meant a LAN, using TCP/IP.

Where is the buffer sitting?
What kind of cable is connected to the screen?

 

If you want analog VGA then you need to convert the digital video to analog and output it in the VGA format. If the digital video is in DVI-D format, then you could use a converter such as this.

So what kind of cpu clock speed would I need, for example, on an ARM processor to maintain the signal?
Or if there's a better architecture then ARM, what is it?

 

So what kind of cpu clock speed would I need, for example, on an ARM processor to maintain the signal?
Or if there's a better architecture then ARM, what is it?

It depends on the CODEC being used. There is an audio codec and a video codec, the data in the buffer would have some sort of compression.

You would then decompress the video and send it to the VGA/NTSC/DVI encoder for display on the screen.

 

It depends on the CODEC being used. There is an audio codec and a video codec, the data in the buffer would have some sort of compression.

You would then decompress the video and send it to the VGA/NTSC/DVI encoder for display on the screen.

So just for the video, I'd get the IC for which ever CODEC I decide on, then something like a xilinx spartan 3a for the vga/ntsc/dvi encoder?

 

Depends on what format comes out of the decompressor,

You'll need to generate timing signals for VGA or DVI

A PIC32 can do that, unless you are more comfortable with FPGA which is more spendy.

Will your output be CRT or LCD? For CRT, you need to keep in mind flicker and correct VGA timings that are "standard" for all CRT displays. For LCD, refresh is 60Hz, and 1024x768 is only a native resolution in older displays.

 

With a PIC I'd have to build extra circuitry, right? I was looking at this, and on page 3, it shows the logic diagram of the TDMS transmitter. I have a feeling that isn't in a PIC so I'm kind of curious if it would be cost effective to just get the FPGA.

I have a lot of programming experience, and a tiny bit of PIC8 experience so neither are easier to me unless I have to design and build something complicated for it to work with a monitor (a.k.a I'd rather do a lot of programming on a fpga, then have to build something for a pic)

Also, I said previously that I wanted to use VGA, but I realized DVI would be usable and it seems more doable with the digital data.

 

I was looking at the video compressors, and they're pretty expensive, and most of them have RISC based processors in them, so if I'm going to have to get another processor to handle the internet connection, should I just get one fast enough to decompress it? I know I'll have to look into which codec I need, but to me it seems pointless to use one risc to strip the tcp/ip headers and another for compression

 

Some of the newer Xilinx devices have an internal traditional processor in addition to the rest of their speed and options.

As for the codec, there aren't many that are open source, you'd need to ensure the video is recorded with a compression codec you have the source code for so you do not need to pay license fees for every decompression unit. The proprietary aspect of good CODECs is part of the reason the dedicated ICs have a somewhat inflated price.