On Thu, 2008-10-09 at 23:19 -0400, Andy Walls wrote: > On Thu, 2008-10-09 at 17:01 +0200, Hans Verkuil wrote: > > On Thursday 09 October 2008 16:36:07 Jim Stichnoth wrote:
> > > I'm seeing a small problem where enabling closed captions causes the > > > top 10 or so lines to be cropped and the image shifted up, leaving > > > ~10 lines of black at the bottom. > > > > > > I took a couple of screen shots to show the problem more clearly. I > > > paused the input source, then ran either "v4l2-ctl -b cc" or > > > "v4l2-ctl -b off" to turn closed captioning on or off, and then > > > captured a frame using xine. If you flip back and forth between the > > > two images, it's clear that the first several lines are being cropped > > > and everything shifted up when cc is enabled. > > > > > > cc on: http://www.flickr.com/photos/[EMAIL PROTECTED]/2905480460/sizes/o/ > > > cc off: http://www.flickr.com/photos/[EMAIL PROTECTED]/2905480878/sizes/o/ > > > > > > I would assume that this has something to do with VBI > > > removal/cleanup. But it's interesting that even with the uncropped > > > picture, the VBI stuff has apparently already been removed. If I had > > > to guess, I would say that VBI removal is being done twice when cc is > > > on. > > > > > > > > > Any ideas on this? > > > > I know what this is and I guess I should pick it up again: when CC is on > > the vblank register of the cx2584x is changed. In my opinion this > > should not happen, but I need to verify this some more. If I recall > > correctly this problem does not occur with PAL/SECAM, it is NTSC > > specific. > > > > (For those who really want to know: it's register 0x474). > > Hmm. The difference between having 22 vs 26 half lines of vertical > blanking interval after the end of the vertical reset lines (lines 1-9 > in the first field). Moving thread to the ivtv-devel list Hans, I've been looking at this and thinking about it a little more. Is the change in VBLANK, with VBI enabled, to delay the V bit toggle in the EAV codes a little later so the encoder doesn't have to worry about different start and stop codes? Right now in ivtv-streams.c the ivtv driver uses Sliced VBI start (EAV) and stop (SAV) codes of data[3] = 0xB0F0B0F0; <--- EAV RP codes that start ancillary data data[4] = 0xA0E0A0E0; <--- SAV RP codes that end ancillary data But since the V bit is only allowed to toggle in an EAV code, the last line of Sliced VBI stuffed in as ancillary data in the horizontal blanking interval before the first line of active video could be framed with EAV HBlank SAV 0xFF000090 [anc data] 0xFF000080 0xFF0000D0 [anc data] 0xFF0000C0 or maybe their variants with hamming code : 0x9D and 0x80 or 0xDA and 0xC7 So using a little deduction from comments in the code, maybe the ivtv driver could use: data[3] = 0xB0F090D0; data[4] = 0xA0E080C0; to deal with the V bit toggling off in the EAV & SAV codes just before the first active video line, and not have to have the cx25840 driver extend the vertical blanking interval to control the V bit toggling. (There is a way to use the VBLANK656 reg to get manual control over the V bit toggle for the Video Output port and a setting for this to be used in VIP output mode. So even if the ivtv driver stayed the same, there is another method for delaying the V bit toggle.) Am I way off? I don't have my ivtv card in this machine to test with but cx18 raw VBI had me looking at this sort of thing anyway. -Andy > How strangely inconsistent of the cx25840 driver. > The challenge appears to be fixing it for NTSC-M and not breaking some > other bizarre 525 line or 60 Hz standard. > > > I'll have to look things up in my reference book at work, but IIRC for > NTSC-M: > > 525 lines per frame - 483 active lines/frame = 42 VBI lines/frame > > or 21 VBI lines/field > > 21 total VBI lines - 9 vert reset VBI lines > = 12 remaining VBI lines > > Those 12 lines must be lines 10 thru 21 in the first field. > > So: > > 22 half lines is 11 lines of remaining VBI lines > > 26 half lines is 13 lines of remaining VBI lines > > Neither value in the cx25840 driver seems right. :) > > Maybe we should use 24. > > > BTW: Reg 0x474 is a autoconfigured register that changes if you muck > with register 0x400 or video format detection mucks with register 0x400 > > Regards, > Andy > > > > Regards, > > > > Hans > > > > _______________________________________________ > ivtv-users mailing list > [EMAIL PROTECTED] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
