Recording VGA output ?

I'm looking for a way to connect a VGA output to a system, so we can record whatever the user is doing. We would use a split-system to split between the user's own monitor (actually a beamer) and the recording system. However, we have no idea how to record a VGA signal. Can we use

3 analog inputs combined to reconstruct the image, then save it as a set of JPEGs ? Or are there easy conversion systems ? We would need to make it as small as possible, so PC/104 or similar formats are advisable.

Any help most appreciated !

Kind regards,

Wim

Reply to
Wim Godden
Loading thread data ...

You can use a VGA-to-NTSC converter and record it on videotape. However, it's much more efficient to record the operations of the device that's generating the VGA output, and reconstruct the output by simulation later.

Reply to
larwe

The idea is to record mutiple systems and store it on a computer system, so it can be downloaded by others on an intranet. Recording on the device is not an option, since there's several operating systems involved.

Any suggestions ?

Wim

Reply to
Wim Godden

Try using a VGA-to-composite converter and a video capture card. Or if you're lucky enough to be using a VGA chipset with TV-out, enable that feature.

But the quality will be rather low. The problem is that VGA - and I assume you probably mean something better than baseline VGA 640x480 HS=31.5kHz VS=60Hz with only two intensities per color component, too - has an awful lot of bandwidth. Yes, you could design a system to capture it, but it's a lot of work because you'll also need to compress it in realtime.

Reply to
larwe

Do you mean a real VGA or a computer system video o/p at ANY resolution?

Why would you need to show the recorder for?

Anyway screen capture even at a low res of 640x480x nbits is still RGB running NON-interlaced at 60Hz and just capturing it will use a lot of bandwidth (system and capture interface). Then displaying it SCALED on another monitor will use a lot of computation time and more system bus bandwidth continuously transfering to screen.

Then there is the computations to compress the data (continuously) and more system bus bandwidth used transferring the data to a storage device.

Real time video processing is HUGE amounts of data CONTINUOUSLY and systems from security surveillance to TV studios uses DEDICATED hardware especially when it comes to multiple sources.

OUTPUTs can be combined into a video signal NOT suitable for video recorders.

For EACH display that needs to be captured a separate SYSTEM would be required with a frame grabber SPECIFICALLY designed for that resolution RGB capture preferably with ONBOARD (to the frame grabber) compression HARDWARE!

That data is then transferred as compressed files to a storage device.

Even compressed you will need a VERY large storage device! Do the calculations to start off with RAW data at 640 x 480 x 24bits (what you would get from a frame grabber) repeated 60 times a second for 10 seconds and realise the MB that becomes

52.73MB per second uncompressed 527.3MB for 10 seconds uncompressed

Even if you manage a good compression of 1/4 it will still be large and a large computational overhead to compress it.

Alternatively as has been suggested do a lower resolution record to video recorder via a VGA to NTSC/PAL[1] converter to make a standard signal. The resolution will either be grainy or potentially distorted.

If this data is then to be transmitted over networks you will need SEPARATE networks as point to point for MULTIPLE grabbers if you want

60 frames per second. [1] Depending on where you are in the world.

Define as small as possible as the amount of data storage is huge, so will need some chunky storage means.

Alternatively work out how many updates you ACTUALLY need as a lot of the time the data will be the same! Consider either grabbing every 5th or 10th frame to store, to reduce overhead.

Consider that even time lapse recording uses special hardware to SWITCH between cameras to record multiple sources, and does NOT pass the video data through a computer at all!

Another alternative is to look at VNC type network software to capture the screen using forced to 8bit data and only sending CHANGED information, and writing your own software to process the data and store it.

Real time video processing is a lot harder than connecting a camera to a computer. There are serious bandwidth and computation overheads to be considered and NOT a single byte can be late or delayed.

One system I designed for 3D RGB processing had an effective 2.5GIPs continuous processing at upto 32 bits wide on each R, G and B with

48 multiplies 12 adds various pipeline stages (limits, rounding, LUT)

All happening on EVERY clock cycle! Total system delay time including conversion from interlace to non-interlace 19 PAL TV lines input to output! That is 19 x 64us = 1.216ms ! No PC/104 processor or many larger processors could achieve that.

If you are really serious and need design effort from someone with 20 years of working in real time video processing, to computer based image processing then email me. I think you have bitten off more than you can chew unless you have a more detailed specification already, a detailed specification and processing/bandwidth calculation needs to be done.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

It that case you will need multiple point to point networks or a very good streaming (multicast) protocol and client software to deal with it as the intranet will be maxed out easily if you use multiple sources.

JPEG or MPEG files are supposed to be operating system NEUTRAL!

You will need to store some of it somewhere to at least buffer it up before sending to the intranet.

It seems to me that either you send only one frame in 'n' or get some form of video distribution system installed.

How many is multiple?

How many updates a second do you need?

What resolution are ALL the outputs to be 'recorded' running at? This is VERY VERY important.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

I've always wondered why there isn't a record facility in a VNC client. VNC is available for most operating systems, and the protocol is documented, source code for both clients and servers is available. You might create a VNC recorder and make a few bucks!

Reply to
Clifford Heath

I've used a very nice system from MediaSite

formatting link
which records the VGA output and a video (composite/SVideo/Firewire/USB) feed from a camera, have a look at some of the show case presentations at the Mediasite Website.

The mediasite gear was all automatic, just point the camera at the presenter, connect the presenters Laptop (wheter it be Windows/Mac/Linux) into the VGA capture card, and press RECORD, an instant richmedia presentation.

The Mediasite gear used the following VGA capture card, check out

formatting link
this comes with software that detects changes in the picture and creates a new Jpeg slide. I think it even streams it to the web.

Alec

Reply to
sivadnz

The web conferencing companies have exactly this capability - whatever you "share" off your desktop for a web conference can be recorded and played back later, generally available as a freestanding file for use independent from their service.

It's common to record a training presentation & slide show with their tools and then use it elsewhere. IIRC, the file is in a standard format, so as long as a reader is available it can be viewed on multiple platforms. Java is often used for these client-side modules, so the recording might even support multiple platforms too.

Richard

Reply to
Richard H.

Exactly - we use them regularly. That has nothing to do with my comment that the open source tools should have a record and playback facility. They have all the hard stuff already!

Reply to
Clifford Heath

formatting link

or diy on AD9888

--
taa
Reply to
koko

Whilst it might do part of what the original poster wants, it may also be overkill for his application (in budget terms as well). Last time I was involved with Alacron was interface to MRI scanner for a hospital to use in a mobile unit (big bus). That was a few years ago, when I was working for a company that was selling Alacron kit in UK, and I wonder if some of the guys I knew then from their previous company still work there.

Be interesting to see how the original poster plans to proceed.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

Use a video surveillance box(video server) from TV out or similar Most should be able to output motion jpeg or mpeg2 or mpeg4 then just record on to a server. With mpeg4 it should be about

4-8 Mbps

Like an Axis 240 or 250

formatting link

Alex

Reply to
Alex Gibson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.