Mailing List Archive

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/37377999@N00/2905480460/sizes/o/
> cc off: http://www.flickr.com/photos/37377999@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).

Regards,

Hans

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

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/37377999@N00/2905480460/sizes/o/
> > cc off: http://www.flickr.com/photos/37377999@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



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Thu, Oct 9, 2008 at 8:19 PM, Andy Walls <awalls@radix.net> 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/37377999@N00/2905480460/sizes/o/
> > > cc off: http://www.flickr.com/photos/37377999@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

On Sat, 2009-03-21 at 14:59 -0700, Jim Stichnoth wrote:
> On Thu, Oct 9, 2008 at 8:19 PM, Andy Walls <awalls@radix.net> 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/37377999@N00/2905480460/sizes/o/
> > > cc off:
> http://www.flickr.com/photos/37377999@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
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Sat, Mar 21, 2009 at 4:34 PM, Andy Walls <awalls@radix.net> wrote:
> 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
>

Interesting. It sounds like at the very least it would be worth
trying a test install onto a USB thumb drive to see if anything
changes in my setup.

Thanks,

Jim

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Sun, Mar 22, 2009 at 12:11 PM, Jim Stichnoth <stichnot@gmail.com> wrote:
> On Sat, Mar 21, 2009 at 4:34 PM, Andy Walls <awalls@radix.net> wrote:
>> 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
>>
>
> Interesting.  It sounds like at the very least it would be worth
> trying a test install onto a USB thumb drive to see if anything
> changes in my setup.

I installed MythDora 10.21 onto a spare hard drive, but there were no
changes in the cropping behavior (as I think everyone here suspected).

Jim

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users