Maker Pro
Maker Pro

Video SYNC'ing

Q

Quack

Jan 1, 1970
0
Hi,

I am thinking about ways to make a video switch that would switch more
cleanly (than just switching at random points within the signal).

After searching around, it appears to be quite a complex thing to
achieve.

The main method i have seen is to keep some kind of buffer of each
incoming signal to be used as slack to have each one sync'ed together,
so that when the output is switched, it doesnt break up the signal.

In my application, 4 inputs, 1 output - i dont see the need to have
each stream synch'ed together, why not instead switch 'just before' a
sync, would that not work ?.

for example,

if you had a PIC chip (or other faster processor) receiving commands
to switch, lets say its asked to switch to input 4.
It would then set itself up to monitor input 4, and wait for a SYNC,
once it gets a sync, it would then start counting, and just BEFORE a
new sync occurs (time based calculation), it would switch input 4 ON
(and the original input, whatever it WAS, OFF) - this would allow
input 4's SYNC to be the first thing OUT the output once switched
(**even though the last frame may not have been complete**).

Would this 'incomplete frame' of the previous signal cause much
disturbance in the process of video capture ?.
It seems logical that it would be less of a problem than getting half
of one frame, then possibly another half (or more than) another frame
etc due to random switching times.

Would the improvement be noticable/worth the effort ?

Currently the technique used is to switch at the time the command is
received and understood (whenever that may be in the signal). This
creates a SYNC problem in the video capture process, and the first few
frames after a switch are usually white/black/all over the place. As
you would expect.
To get around this, we insert a pause after a switch command in the
encoding process, so that we dont include these bad frames in the
end-encoded stream.

Using this 'switch just before sync' technique, would it atleat make
this pause time less ?


Perhaps im way off here, any opinions ? :)

After all that - i think my question boils down to something simpler;
whats better - a video signal with a frame thats too long (greater
than 625 scan lines) or a video signal thats too short (less than 625
scan lines), in between switching.


Alex.

PS: this is only in regards to PAL signals.
 
G

Glenn Gundlach

Jan 1, 1970
0
[email protected] (Quack) wrote in message news: said:
Hi,

I am thinking about ways to make a video switch that would switch more
cleanly (than just switching at random points within the signal).

After searching around, it appears to be quite a complex thing to
achieve.

The main method i have seen is to keep some kind of buffer of each
incoming signal to be used as slack to have each one sync'ed together,
so that when the output is switched, it doesnt break up the signal.

In my application, 4 inputs, 1 output - i dont see the need to have
each stream synch'ed together, why not instead switch 'just before' a
sync, would that not work ?.

for example,

if you had a PIC chip (or other faster processor) receiving commands
to switch, lets say its asked to switch to input 4.
It would then set itself up to monitor input 4, and wait for a SYNC,
once it gets a sync, it would then start counting, and just BEFORE a
new sync occurs (time based calculation), it would switch input 4 ON
(and the original input, whatever it WAS, OFF) - this would allow
input 4's SYNC to be the first thing OUT the output once switched
(**even though the last frame may not have been complete**).

Would this 'incomplete frame' of the previous signal cause much
disturbance in the process of video capture ?.
It seems logical that it would be less of a problem than getting half
of one frame, then possibly another half (or more than) another frame
etc due to random switching times.

Would the improvement be noticable/worth the effort ?

Currently the technique used is to switch at the time the command is
received and understood (whenever that may be in the signal). This
creates a SYNC problem in the video capture process, and the first few
frames after a switch are usually white/black/all over the place. As
you would expect.
To get around this, we insert a pause after a switch command in the
encoding process, so that we dont include these bad frames in the
end-encoded stream.

Using this 'switch just before sync' technique, would it atleat make
this pause time less ?


Perhaps im way off here, any opinions ? :)

After all that - i think my question boils down to something simpler;
whats better - a video signal with a frame thats too long (greater
than 625 scan lines) or a video signal thats too short (less than 625
scan lines), in between switching.


Alex.

PS: this is only in regards to PAL signals.

You're way off but at least giving it serious thought. The destination
devices fall into 3 basic groups as I see it. The simplest is a CRT
monitor. Causing a non-synchronous switch with your over or under
length frames will cause the monitor to roll vertically and
horizontally. The H rate from disturbing the H PLL in the monitor anf
the V rate from having vertical start at the wrong time. The next
group would be the VTR with the rotating drum. The drum is locked to
the vertical sync and disturbing that timing will take quite a while
to relock. The last group would be the computer type devices that
actually count lines. Non-sync switches here will result in PLLs
relocking, memory addressing out of range, etc. There is a reason for
genlocking and frame synchronizers to deal with this. Conceptually it
isn't too difficult but it does require a chunk of hardware to make it
work. TV is cool, huh? BTW, PAL vs NTSC vs SECAM vs anything else all
has similar issues.

Starting and stopping counters looks good on paper but would actually
be pretty tricky to get everything exactly on the right pixel.
GG
 
Q

Quack

Jan 1, 1970
0
Starting and stopping counters looks good on paper but would actually
be pretty tricky to get everything exactly on the right pixel.
GG

Oh well, i'll just stick with the pause. its the simplest solution.
This device is not worth the effort/expense of getting everything in-sync.

Thanks :)
 
Top