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/[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.
> >
> > 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
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
