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.