On Thu, Oct 9, 2008 at 8:19 PM, Andy Walls <[email protected]> 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 have a Hauppauge PVR-150, with the S-Video input connected to an SD > > > DirecTiVo box. This is on a system running MythDora 5 -- "uname -r" > > > reports 2.6.24.4-64.fc8 and "ivtvctl --version" reports "ivtvctl > > > version 1.0.3 (tagged release)". > > > > > > 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/37377...@n00/2905480460/sizes/o/ > > > cc off: http://www.flickr.com/photos/37377...@n00/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. > > > > > > Ideally, I would like to have the VBI "junk" preserved and rely on > > > the monitor or player to handle the overscan, especially since I > > > already have to deal with that for my HDHomeRun. The next best thing > > > would for VBI removal (or whatever) to be done only once, yielding > > > the "cc off" picture. By the way, the MythTV WAF requires closed > > > captions to be preserved... > > > > > > 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). 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 > > I was wondering if any changes to these initialization values have been made. In particular, I'm considering whether to upgrade from MythDora 5 (2.6.24.4) to MythDora 10.21 (2.6.27.9). I tried to compare the relevant source code for both kernels -- it looks like the code was reorganized a bit, but I don't see different values being used. Of course I could be wrong.
Thanks, Jim
_______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
