Understanding analog video signal

[jonen]

Hi,

I have to admit, I am fairly new to video signals. My goal is to generate some kind of video signal that is similar to a standard composite video signal but with a lower carrier frequency. ( since I am still new to this I might mix up some terms: with carrier frequency I mean the h ramp freq e.g. NTSC has 15.734 kHz, which translates to a period of 63.5 us (see picture below)).



Could I create a carrier frequency like in the picture above, just using a rectangular wave with an appropriate pulse width? ( let's keep it simple and stick to black and white)

Let's say I just want to draw a vertical black line in the center, can I simply multiply my carrier frequency with an appropriate signal? And if so, how do I preserve my sync tip and horizontal blanking and so on?

And for my understanding: The actual video information is transferred to the carrier frequency with some kind of 'partial AM'? Partial because only the 'Active Video' range (see picture) is AMed? Can I imagine it like that and how is it realized?

I am happy for links that would help me figuring that out too.

Thanks!

[daverj]

Composite video in it's black and white form does not have a "carrier frequency". If it is turned into an "RF" signal to broadcast it or send it into an antenna input of a TV, then the video and audio are modulated using carrier frequencies.

What are you trying to do? You can create non-standard video signals with horizontal and vertical frequencies that are different than normal video, but there's not much you can then do with that signal. Video monitors can handle small changes in horizontal and vertical frequencies, but not large differences.

[jonen]

I have an XYZ scope and am trying to run it with my soundcard, hence the lower horizontal frequency.

I have some difficulties understanding the signal that goes into the z axis. How do I achieve video information and sync on one channel? I guess I mixed up carrier frequency and sync frequency.

Can I use an existing video signal like NTSC and Pal and convert it to another sync frequency? I understand that I will lose much quality but that's not what I am after.

[lizlarsen]

Here's an article you may enjoy...
http://en.wikipedia.org/wiki/Slow-scan_television

You could do what you're describing using Processing or something similar to that, to get video out of a soundcard and onto a scope... maybe. Your pixel rate will essentially be the bandwidth of your audio interface's output. If we're talking 44.1KHz audio, that gives you a pixel rate just slightly above the horizontal line rate of NTSC/PAL video, which is about 1 pixel per 720 pixels of standard NTSC/PAL.

Converting existing video using this method is going to be very difficult, you'd need to write some more complex code for that.

If you're doing the XYZ stuff you don't need to worry about subcarrier frequencies, since all you want is the monochrome (black and white) information.

[jonen]

Thanks for the link, looks very interesting!

I guess now I understood what shape the z-signal should have. If I want to draw a vertical black line it should have some kind of minus pulse with a frequency equal to the y-frequency. The phase determines the position of the black line on the screen, right?

I am testing things with MaxMSP right now. I have some trouble producing good ramps for the horizontal lines although my soundcard supports 96kHz. But I guess high harmonies that are needed for ramp waves are cut off quite early. Is there a way to use sinus waves for the horizontal grid lines? This would make the z-signal awfully complex, right?

Edit:
This looks great:
[video][/video]

[lizlarsen]

Probably, this is a lot less complex than you are thinking.

For NTSC video it looks like this...
X = 15.734KHz sawtooth ramp
Y = 59.94Hz sawtooth ramp
Z = brightness (high = white, low = black)

The Y frequency divided by the X frequency gives you the number of scanlines (vertical resolution.) In this case it is 263.5 scanlines -- a full interlaced field.

The resolution/bandwidth of your audio interface determines the horizontal resolution (the X ramp.) If you try to do a 15.734KHz ramp out of a normal audio interface, it's really going to look more like a staircase or pulse (although it may get filtered out to something resembling a sine.)

So what you need to do first is determine a good horizontal resolution.
Maybe try 1KHz to start. That should give you 96 pixels per scanline in an ideal environment, with a 96KHz interface. Make sense?

Now you need a vertical resolution (number of scanlines) that is fast enough to not produce too much flicker in your display. If you do a 96 scanline resolution, your vertical ramp speed should be 10.41Hz (1KHz / 96 = 10.41Hz.) That's going to be quite flickery, but maybe decent enough. For comparison, low budget animated shows are around 12 frames per second (12Hz.)

So in order to do a 96 x 96 pixel display, you would have these speeds...
X = 1KHz sawtooth ramp
Y = 10.41Hz sawtooth ramp

So now, in order to display the actual video signal on Z, you need to output the brightness of the current pixel, for each "step" of the horizontal (X) sawtooth ramp.

You don't need to worry about embedding "sync" signals or pulses in your ramps or video signal. Those are for telling a normal display when to start the ramps -- but the X and Y ramps are generated internally on an analog TV. The sync (which is sent in the same signal as the actual video) just tells the display when to reset the ramps.

[lizlarsen]

If you're doing this all with code, your loop should look like this pseudocode...

AT THE BEGINNING OF EVERY PIXEL...
>Is X ramp value greater than 96?
>>If so, reset X to zero and increment Y ramp value
>>Is Y ramp value greater than 96?
>>>If so, reset Y to zero
>output Z pixel value (brightness of video)
>increment X ramp value


Or something like that.

[daverj]

If you are drawing things on an XYZ display you don't have to follow the rules of video.

To make something that looks like a raster you feed two ramps, one fast and one slow, to the X and Y inputs. The Z input is brightness. So as it gets higher (or lower in some Z inputs) the image gets brighter.

You can swap the fast and slow ramps between the X and Y inputs and the raster is rotated 90 degrees.

But if you are just drawing shapes then you can draw with vectors instead of a raster. So then you think of the two voltages to the X and Y inputs as representing an XY position on the screen. If you feed two sinewaves that are 90 degrees out of phase you draw a circle on the screen. If you put nothing out of one and put anything out on the other you get a line (horizontal or vertically, depending on whether the one with the signal is the X or the Y input).

It's even possible to make a raster using something other than fast ramps. For example if you make the vertical with a slow ramp and the horizontal with a fast triangle wave then instead of a normal raster where each line starts at the left and moves to the right, every other line moves right to left.

To change the brightness at different spots you need to imagine where the X and Y is at a given instant and that is a given spot on the screen.

[jonen]

Thanks for your help and your detailed description, that really made things clear for me.

I am now able to produce a good grid and draw a vertical line with a z-signal. It was only an easy example that helped me understand the system behind it.

I will now try to extract brightness value of every pixel from a picture or a movie and use this information for my z-signal. This may take some time because I am new to MaxMSP but it is definitely doable.

Thanks again, I will post my results here when I am done!

[i.m.klif]

i did something similar using maxmsp



it definitely shows lo res video on oscillocope. converting ordinary video signal to lo res is not a problem at all in max msp. resolution and framerates are completely arbitrary. trying to get higher resolutions/framerates will bend scanlines to unrecongisable mess - but it looks good.

i plan to share the basic patch, but i have to clean it tough. right now it's a mess.

[Matos]

I'd love to see the basic patch, messy or not. About a month into max msp and eager to learn from wizards like you!

[jonen]

Great!

I already did it though, gonna post a video later.

Matos, well there is not that much wizardry to it. You will just need two phasors for your grid and you want to use the same phasors to feed your jit.peek object! Thats basically it!

Klif, what do you think are the resolution limiting parameters? The horizontal ramp or the jit.peek? Do you know of any MaxMSP settings that would increase performance and accuracy?

My oscilloscope has a sawtooth out, I guess I am gonna try running the horizontal ramp with it, though that means no more rutt etra effect.

[i.m.klif]

you are right about jit.peek object. most difficult stuff happens automatically when you use it

concerning the resolution... hm, i'm just checking old threads like this one: viewtopic.php?t=60631&start=all&postday ... torder=asc

i'm sure dave and liz commented on resolution issues, but can't seem to find relevant info tough.

looking at the data above, i don't understand why resolution is so limited...

i don't remember exact resolution, but it's along what you can see in the video above. i did tweak my patch a lot since then, but didn't make any revelations concerning resolution.

i use arbitrary ramps, using really slow framerates and low number of scanlines, but i couldn't get higher number of scanlines without everything getting wiggly.

unfortunately i don't have my xy display at hand, so i can't try anything at the moment.

[daverj]

Remember that a full resolution video signal is up in the range of 5MHz-6MHz for the Z (pixel) information, even though the horizontal ramp is down at 15KHz. That's about 320-380 times faster than the horizontal scan rate. Since the visible portion of the scan line is about 81%, and a pixel can be the positive or negative part of a cycle, that results in about 520-620 pixels visible. (more if they don't go fully black to white)

The video (pixel) information has to happen at a multiple of the horizontal rate. To get 100 pixels on a scan line you need to be able to move the Z output up and down more than 50 times faster than the horizontal ramp (50 times faster than the part of the ramp you see, so actually about 62 times faster).

So if the DAW can output 20KHz, if the Z output is at full speed (20KHz), to get 100 pixels per line the horizontal ramp would need to be down around 320Hz. To get 100 scan lines the vertical ramp would then need to be 100 times slower than the horizontal.

That's already going to flicker a lot. To get even more resolution you need to go even slower. So it becomes a compromise. You speed up the ramps and get less flicker, but give up resolution.

MAX/MSP supports external hardware being added to it. It should be possible to build an output device with D-As for MAX that can output signals faster than 20KHz, and therefore increase the scan and pixel rates.

[i.m.klif]

i understand why Z axis needs lots of bandwidth.

i don't understand why i can't get clean scanlines above 30-40. first, they start tearing, and then with higher values "folding" (like at 1:45 in my video above).

theoretically i should be able to get NTSC/PAL raster without problem. in practice it doesn't seem to work.

[lizlarsen]

A sawtooth ramp at 15.734KHz being played at 44.1KHz sampling rate is basically a square wave. That's 2 pixels per line. As your ramp gets faster, it will "fold over" from waveshaping as it moves from a sawtooth to something more resembling a square. So that's why you can't get NTSC/PAL raster out of your audio interface.

This also could have to do with the bandwidth of the display you're using. (Or that could be a factor, anyway in seeing the image "fold.") For example the Vectrex display doesn't have enough bandwidth for an NTSC raster.

[daverj]

A digital interface running at 44KHz will have an anti-aliasing filter that kills everything above 22KHz. So a 15,750Hz output signal is going to be pretty close to a sine wave. That means that instead of going left to right and suddenly jumping back at the end, like a ramp would do, it will move across and move back (fold over) smoothly.

You need to make the frequency much lower to get anything close to a ramp from an audio interface.

[i.m.klif]

ah, that makes sense.

i must say i didn't see significant difference when trying 96khz setting for audio card. (but i usually tested using low end audio interfaces, i guess that counts as well)