dinstun
30th May 2005, 20:18
This is a filter which might be used to stabilize some "jumpy" video sources. This was written for a specific problem I was having with a DV capture of a VHS source (actually a 6 year old SVHS-ET at EP speed). The VHS source was a recording of an interlaced 30fps NTSC broadcast (a football game). Throughout the video the odd-numbered lines would sporadically "jump" up or down, shifting vertically by one line in the interlaced field.
The filter attempts to correct this by examining the last few (10) lines of each interlaced frame, and finding the "end of signal" of the even and the odd lines, and deciding whether to "fix" the frame based on these two positions. The "fix" is to shift all odd lines up or down by one line in the field.
Maybe there is a better or easier way to do this already in existence, but I couldn't find it (if there is, let me know). Possibly this filter could be the start of a sort of software TBC, since that is what I think it is doing, although I don't really know the technical details of what hardware TBC does.
The filter takes three integer parameters (after the clip parameter):
fix: 0-fix, 1-don't fix
mark: 0-no mark, 1-color the two "end of signal" pixels with: green at even lines, yellow at odd lines of good frames, red at odd lines of bad/fixed frames.
debug: 0-no debug, 1-report "end of signal" positions on bad frames with OutputDebugString, 2-report position on all frames.
Here is an example "good" frame, left side is result of DeJump(0,1,0), right side DeJump(1,1,0). The bottom 10 lines are magnified. Since this is a good frame, no fix was made: http://www.frontiernet.net/~sbyrne/252444.png
The next frame is bad. You can see the original frame on the left, the fixed frame on the right: http://www.frontiernet.net/~sbyrne/252445.png
This is just a start. I believe it likely that some "good" frames will be "fixed" incorrectly, so be careful. Some refinements could be made to the filter to better determine good/bad frames.
A word of warning: the filter depends entirely on a fairly consistent pattern of what I call "end of signal" at the bottom of the frame, as you can see in the example frames. I don't know if these result from the broadcast or the vhs recording, and I don't know how common they are, maybe someone could explain. If these are not present, the filter will not work.
The filter attempts to correct this by examining the last few (10) lines of each interlaced frame, and finding the "end of signal" of the even and the odd lines, and deciding whether to "fix" the frame based on these two positions. The "fix" is to shift all odd lines up or down by one line in the field.
Maybe there is a better or easier way to do this already in existence, but I couldn't find it (if there is, let me know). Possibly this filter could be the start of a sort of software TBC, since that is what I think it is doing, although I don't really know the technical details of what hardware TBC does.
The filter takes three integer parameters (after the clip parameter):
fix: 0-fix, 1-don't fix
mark: 0-no mark, 1-color the two "end of signal" pixels with: green at even lines, yellow at odd lines of good frames, red at odd lines of bad/fixed frames.
debug: 0-no debug, 1-report "end of signal" positions on bad frames with OutputDebugString, 2-report position on all frames.
Here is an example "good" frame, left side is result of DeJump(0,1,0), right side DeJump(1,1,0). The bottom 10 lines are magnified. Since this is a good frame, no fix was made: http://www.frontiernet.net/~sbyrne/252444.png
The next frame is bad. You can see the original frame on the left, the fixed frame on the right: http://www.frontiernet.net/~sbyrne/252445.png
This is just a start. I believe it likely that some "good" frames will be "fixed" incorrectly, so be careful. Some refinements could be made to the filter to better determine good/bad frames.
A word of warning: the filter depends entirely on a fairly consistent pattern of what I call "end of signal" at the bottom of the frame, as you can see in the example frames. I don't know if these result from the broadcast or the vhs recording, and I don't know how common they are, maybe someone could explain. If these are not present, the filter will not work.