Field synchronization signal for 625/50/i systems per itu-r.
bt.470, not for system N, with h=H/2 one half line period:
total vertical blanking = 50h,
odd field, fsync is line 1, image at line 23.5:
5h fsync + 5h equ + text,white,text,WSS + 575h image + 5h equ,
even field, fsync is line 313.5, image at line 336:
5h fsync + 5h equ + bk,text,white,text + 575h image + 5h equ.
The decoder vertical reset ends synchronous with the trailing edge
of the field sync. So the image begins after a delay of
total_vblank-equ-fsync=50-5-5=40h or (23.5-1)-fsync/2h=20 lines.
The code cx25840-core.c initializes vblank656=40 which works with
firmware 2.05.032.
bt.656
Each field is 576h long and the line number changes at hblank start.
Thus the analog line number lags the digital line number. A word
stream consisting of one frame gives a timing for the odd field:
A--- 40h delay ---------------------------->
A <--------- line 23 -------->
S____.v.------------------..h____...--wss------image--..h
D <--------- line 23 -------->
D--- 39h delay ------------->
D--- 38h delay >
+----------------------------------------------------------- time ->
and for the even field:
A--- 40h delay ---------------------------->
A <-------- line 336 -------->
S------------fvh____fv.------------------f.h____f..-------image------f.h
D <-------- line 335 --------><-------- line 336 -------->
D--- 39h delay ------------->
D--- 38h delay >
+----------------------------------------------------------- time ->
with f=field, v=vertical blanking, h=horizontal blanking.
odd image at line 23 up to 311 --> delay 39h --> vblank= 38 or 37,
even image at line 336 up to 624 --> delay 40h --> vblank= 39 or 38.
Thus vblank=38 for a frame consisting of 576 lines. The decoder
requires 4h of preceding data. Increasing the vertical active time
to 580h results in vblank=38-4=34.
The decoder autoconfig defaults to vblank=34 and vblank656=38 which
works well with firmware 2.06.039.
However, cx25840-core.c std_setup() sets vblank=36 which shifts the
field capture window 2h or 1 line down.
The resulting frame has 2 bottom lines of vsync, like in
http://picaros.org/xorg/v36-40.png .
The bottom left white halfline is line 336+(575h-1h)/2h=623.
Hence setting ctl_crop_top/cur_val to -2 solves the problem, see
http://picaros.org/xorg/v34-38.png .
The encoder firmware now generates the last frame line from previous
lines so the white halfline 623 dissapears.