On Sat, 2009-03-21 at 14:59 -0700, Jim Stichnoth wrote:
> 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.
The cx25840 module code has been reorganized, but the reorganization
should not have mucked witht these values at all.
I can tell you that I have done major rework of the VBI line settings in
the cx18 driver that you may find inseresting. The A/V digitizer in the
CX23418 is *extremely* similar to the stand alone CX25843.
Anyway, if you look in linux/driver/media/video/cx18/, the files
cx18-av-core.c and cx18-av-vbi.c
should look very similar to
cx25840-core.c and cx25840-vbi.c
in linux/drivers/media/video/cx25840/ except with updated values for
NTSC and comments that you may find helpful.
The problem with putting the "right" values in the cx25840 module, is
that the changes will ripple through the VBI handling in the ivtv
module.
For the cx18 module, changes in cx18-av-*c, for VBI, rippled through
cx18-driver.h cx18-streams.c and cx18-vbi.c
in a non-trivial manner.
I did a lot of research and experimenting to figure out how then encoder
was packing in the raw samples (for both sliced and raw VBI) from the
digitizer. The important thing is a) capturing the right amount of
lines and b) knowing the number of the first line the encoder is sending
you as VBI when you twiddle the line count values in cx25840-*.c
digitizer setup.
I needed a copy of the VESA VIP 2 standard (which has BT.656 field
diagarms in it) to figure it all out. :P
Regards,
Andy
> Thanks,
>
> Jim
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
