Re: other computer to video output (besides Firewire/DV)

On Mon, 11 Jul 2005 18:42:04 -0700 Richard Crowley <richard.7.crowley@xxxxxxxxx> wrote:
| phil-news-nospam wrote ...
|> Martin Heffels wrote:
|> | phil-news-nospam wrote:
|> |
|> |>What other means of computer to video output exist and/or are in common
|> |>usage, besides DV over Firewire. Also, I would not be interested in any
|> |>computer video graphics (e.g. SVGA, etc) scan converters.
|> |>
|> |>Something that lets my software generate the entire video stream,
|> including
|> |>all sync pulses, and various vertical interval data coding, would be of
|> |>interest.
|
| i.e. write you own driver for a video card. But you'll end up with
| unusable garbage if you get very "creative" with the sync pulse timings.
| :-)

The kind of video cards normally used for computer graphical displays
is not very welcoming for writing a driver. For NTSC, all I really
need is a fast buffered serial transfer to appropriate D/A converters.
Firewire/DV is much like that (with a bit of unneeded complexity added
due to the Firewire, and the decompression done with the D/A).


|> | A video-card with S-Video/composite output. You can set them up as
|> | dual-screen, and output your video to the second screen, which then
|> | goes out via the videocard.
|>
|> What kind of interface between the hardware and software is used?
|
| The standard Windows video driver?

Actually, this will be on Linux. But both systems suffer from bloat
and slow down when going through the software graphical interfaces.
Graphical windowing systems are designed to be more effective at
things like filling in solid areas, patterns, line drawing, moving
stacks of windows around. It is not effective at dumping continuous
data through.


|> I do not want to be using the kind of interface that is used for
|> typical computer graphics cards. If a dual-screen just means use
|> the same graphics buffer and a scan converter produces it as NTSC,
|> then that's what I want to avoid.
|
| Then you are talking about something rather esoteric. Playing peek-
| aboo with your actual requirements likely won't get you very far and
| will annoy a lot of people, some of whom may have had valuable input.

It's not very esoteric. It is very basic. A simple serial transfer
going to a set of D/A converters. Such things already exist for SDI
output by replacing D/A converters with bit stream serializers for the
SDI data stream. I just want an analog equivalent driving D/A converts
instead of SDI.

It will need to also do conversion to 3.579545 MHz modulated NTSC
composite video, which is best done in analog after D/A.


|> I'm wondering if there is anything that can take the DV data stream
|> directly, but without using Firewire.
|
| How do you propose getting to the "DV data stream" to your mystery
| device without using Firewire? If you have some device that does this,
| then you will have to design a custom interface (hardware and software)
| for it. Likely an interesting topic for a graduate course in interface
| design, but hardly a DIY project. Also not clear what the issue would
| be with going with the standard Firewire implementation?

A plain serial interface, without all the overhead of Firewire, would
do the trick. Interfaces for this already have been done for other
kinds of purposes. I may not even need to write a driver at all as
an HSSI/DMA driver will probably do the job (the kind used to transfer
data at speeds of 4 gbps and more).


|> Alternatively, raw YUV samples would be workable.
|
| Again, how do you propose transporting your YUV samples?
| Interface to whatever this YUV output device is. (This is roughly
| the definition of a computer video card, but you have already
| ruled that out for whatever reasons.)

As a serial device. Instead of laying out pixels in a 2 dimensional array,
and hoping you aren't crossing over where the scanout is working which can
result in a wipe or blink effect, what would be done is simply pump out a
serial data stream directly from the stored file.


| If you are still worried about genlock, then you could investigate
| the video cards designed to sync to genlock. They likely come with
| drivers already written for you. :-)

I've got enough experience with the software interfaces for computer
graphics cards to know they don't tend to have the kind of software calls
I need to do video streaming very effectively. The driver and windowing
system will end up spending enormous amounts of CPU massaging images into
buffers to be displayed as graphics, and just complicate all the interfacing
for something that simply doesn't need anywhere near that complexity.

NTSC, PAL, etc, are basically serial waveforms. In digital form, a series
of N-bit values can represent the voltage level value of that waveform.
For video components like RGB or YUV, that would be just 3 such values in
parallel, which can be easily interleaved. A 4-byte word can contain 3
10-bit values for Y,U,V channels. That would drive 3 10-bit 13.5 Mhz DAC
chips, which in turn would feed through a YUV to NTSC chip. The driver
would simply start DMA transfers of large blocks of data and the 13.5 MHz
clock in the device would pace the transfer from DMA memory as needed. A
dual DMA register configuration would ensure no missed bits. Or that
could be dealt with by having some ring buffering in the device between
the DMA transfer and the DACs. The driver would then present a serial
device to the system. My software running as a program would open that
device and (after reading the data from where it comes, such as the disk
file, would call the write() system call to output a buffer to the device
driver). It really is way simpler and faster. This can be done at speeds
of 60 megabytes per second even on older slower PCs, which is plenty for
a 4:4:4 pixel structure at 13.5 MHz.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
.

Relevant Pages

  • Re: Firewire vs USB2 for multichannel in?
    ... Firewire implementation that does not meet the specs. ... That, in short, is what happens when you violate the published interface ... the host or the audio device) or a driver problem. ...
    (rec.audio.pro)
  • Re: Additional channels RME
    ... Firewire, ASIO, and mixing products is ... Cubase wants to use ASIO, ... their Universal ASIO driver that allowed you to consolidate Firewire ... anyway) into what appeared to Windows like a single ASIO interface. ...
    (rec.audio.pro)
  • Re: Firewire vs USB2 for multichannel in?
    ... USB2 audio interfaces are still relatively new and were pretty slow getting off the block. ... The advantage of Firewire is not in the throughput of the interface but that it takes less computer resources to move data. ... Firewire devices require their own driver, and if someone comes up with a Firewire interface that wasn't accommodated in the audio interface manufacturer's driver, it probably won't work until he updates his driver. ...
    (rec.audio.pro)
  • Re: other computer to video output (besides Firewire/DV)
    ... > |>computer video graphics ... i.e. write you own driver for a video card. ... > What kind of interface between the hardware and software is used? ... > directly, but without using Firewire. ...
    (rec.video.production)
  • Re: other computer to video output (besides Firewire/DV)
    ... |>computer video graphics ... What kind of interface between the hardware and software is used? ... typical computer graphics cards. ... directly, but without using Firewire. ...
    (rec.video.production)