On Sunday 16 July 2006 18:08, Rich Kadel wrote:
> Hans,
>
> OK. You've confirmed what I had already believed. I've been using
> zvbi for a while for just that...software decoding the VBI. If I
> understand you, I assume this means I have not been using hardware
> decoding (I didn't think I was).
>
> And if that's the case, then as you said, Windows is using the raw
> VBI, and (I believe) I am using raw VBI on Linux, and using zvbi to
> slice and decode it.
>
> If the ivtv driver is working fine, then am I correct in concluding
> that zvbi is not as robust as the Windows decoders?
>
> I have stepped through zvbi in the debugger, but it's beyond my
> ability at this time to understand how it's reading the waveform,
> finding the right lines, and slicing it. I got lost pretty quick.
>
> Do I have this right, and do I now need to hand this problem over to
> the zvbi guys?
>
> Thanks,
> Rich
>
> Here's the command and output I've been getting by the way:
The --sliced option tells zvbi to use the sliced VBI (= hardware
decoding) mode. 'capture -d /dev/vbi4 --dump-cc' is the command to use
raw VBI (software decoding).
So if you've been using the --sliced option, then it's the hardware
decoding that is having problems. Check with the vbi tool in the test
directory of the ivtv driver if that gives the same errors as it can
also be caused by the zvbi sliced VBI handling (which isn't tested
much).
If you were using the raw VBI all the time, then you should probably
check with the zvbi author after checking again with osc: is the CC
data at the wrong line? Shifted? Not as clean as it should be?
Regards,
Hans
>
> [EMAIL PROTECTED] test]$ ivtv-tune -d/dev/video4 -c56
> /dev/video4: 415.250 MHz (Signal Detected)
> [EMAIL PROTECTED] test]$ capture -d /dev/vbi4 --sliced | decode --cc
> --xds CC line= 21 cmd 0x00 0x00 null
> CC line=284 text 0x6c 0x75 'lu'
> Parity error in CC line=21 >0xc0 0x40.
> CC line=284 text 0x77 0x67 'wg'
> CC line= 21 cmd 0x00 0x00 null
> Parity error in CC line=21 0x40 >0xc0.
> Parity error in CC line=21 >0xc0 >0xc0.
> Parity error in CC line=21 >0xc0 >0x00.
> CC line= 21 cmd 0x00 0x00 null
> Parity error in XDS data.
> Parity error in CC line=284 0xc4 >0x63.
> CC line= 21 cmd 0x14 0x26 roll-up caption ch=0 f=0 rows=3
> CC line=284 cmd 0x03 0x01 XDS packet start/continue
> Parity error in XDS data.
> Parity error in CC line=284 >0x63 0xec.
> Parity error in CC line=21 >0x5c 0xec.
> Parity error in CC line=21 >0x27 >0x30.
> Parity error in XDS data.
> Parity error in CC line=284 0xc7 >0x3f.
> CC line= 21 cmd 0x00 0x00 null
> Parity error in CC line=21 0x80 >0xc0.
> CC line=284 text 0x73 0x74 'st'
> Parity error in XDS data.
> Parity error in CC line=284 >0xf9 0x43.
>
> --
>
> Rich Kadel
> Know'bout, Inc.
> (858) 433-1747
> www.knowbout.com
>
> Do you know about Know'bout?
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Hans Verkuil
> Sent: Saturday, July 15, 2006 3:38 PM
> To: Discussion list for development of the IVTV driver
> Subject: Re: [ivtv-devel] VBI errors on NTSC Cable channels 56 and 57
> - ivtvproblem?
>
> On Saturday 15 July 2006 20:48, Rich Kadel wrote:
> > Hans,
> >
> > To clarify, are you saying that zvbi, by default, is using hardware
> > decoding for VBI, and that maybe I can resolve the problem by
> > turning off the hardware decoding? If so, does zvbi also provide
> > the software decoder, so I can just switch it and maybe get better
> > results?
>
> zvbi provides software decoding (that's the main use of zvbi in
> fact). Hardware decoding (sliced VBI) depends on the hardware used,
> and I suspect that the cx2584x isn't as good at it as the saa7115. I
> have some problems myself with certain channels where the first
> leading pulse of the last teletext line is half-height for some
> reason (clearly visible with osc). The hardware decoder misses that
> line in about 25% of the frames. Just to give you an idea of the
> problems that might be involved here.
>
> Sliced VBI however is the only way you can reasonably embed CC data
> into an MPEG stream. So in that case you would be limited to sliced
> VBI. There may be some tweaking that you can do by setting some
> cx2584x registers (see the datasheet, VBI registers) but that didn't
> have any effect on my teletext problem, so I'm not holding my breath.
>
> Hans
>
> > (Wishful thinking?)
> >
> > Thanks,
> > Rich
> >
> > --
> >
> > Rich Kadel
> > Know'bout, Inc.
> > (858) 433-1747
> > www.knowbout.com
> >
> > Do you know about Know'bout?
> >
> >
> > -----Original Message-----
> > From: Hans Verkuil [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, July 15, 2006 3:41 AM
> > To: [email protected]
> > Cc: Rich Kadel; 'User discussion about IVTV'
> > Subject: Re: [ivtv-devel] VBI errors on NTSC Cable channels 56 and
> > 57 - ivtv problem?
> >
> > On Saturday 15 July 2006 04:59, Rich Kadel wrote:
> > > OK. I verified that the PVR-500 does NOT have this problem in
> > > Windows Media Center.
> >
> > Under Windows only 'raw VBI' is used. That should work fine under
> > Linux too.
> >
> > > When I use zvbi to extract VBI closed caption and XDS
> > > information, I get constant parity errors on channel 56 (NTSC
> > > broadcast), making the CC data unusable. (I'm not sure a single
> > > character is right). On channel 57, I get frequent Parity errors
> > > (about every 10 Line-21's or so). Channels 54, 55, 58, and 59
> > > are very clean.
> >
> > Are you using 'sliced VBI' or 'raw VBI' with zvbi? That's a very
> > important difference. In any case, it may be useful to look at the
> > raw VBI data with the osc tool included with zvbi: you can use it
> > to check if the VBI wave form is somehow different or noisier in
> > the problem channels compared to the other channels.
> >
> > Hans
> >
> > > When I look at the video on channel 56, it appears OK.
> > >
> > >
> > >
> > > I am using ivtv 0.4.6.
> > >
> > >
> > >
> > > Is this an IVTV problem? Is it a known problem?
> > >
> > >
> > >
> > > It does not appear to be a problem with the card, since the card
> > > works in Windows.
> > >
> > >
> > >
> > > As mentioned in the thread below, this occurs on multiple Linux
> > > machines, in different locations (miles apart) but with the same
> > > cable provider.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Rich
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Rich Kadel
> > >
> > > Know'bout, Inc.
> > >
> > > (858) 433-1747
> > >
> > > www.knowbout.com
> > >
> > >
> > >
> > > Do you know about Know'bout?
> > >
> > >
> > >
> > > _____
> > >
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Rich
> > > Kadel Sent: Friday, July 07, 2006 6:19 PM
> > > To: 'User discussion about IVTV'; [email protected]
> > > Subject: [ivtv-devel] Problems with PVR-x/IVTV and VBI data on
> > > certainchannels
> > >
> > >
> > >
> > > Does anyone know why I get parity errors when trying to extract
> > > VBI data (e.g., closed captioning) on certain channels?
> > >
> > >
> > >
> > > For comparison, on a Windows PC, using a Conexant Falcon-II based
> > > card that appears to come from ASUSTEK (it was bundled in the
> > > Windows Media Center HP Pavilliion I got), the closed caption
> > > comes through Media Center "loud and clear".
> > >
> > >
> > >
> > > However, on Linux (Centos 4.3), using IVTV and the ZVBI library,
> > > I have not been able to read VBI on Channels 56 and 57. 55 works
> > > fine, as do many other channels. I have not tested exhaustively,
> > > but I think 70 worked fine too, so it doesn't appear to stop at
> > > the frequency for 55.
> > >
> > >
> > >
> > > I am seeing this problem with PVR-150, PVR-250, and PVR-500
> > > cards, in two different physical locations (miles apart), but
> > > using the same Time Warner cable provider (San Diego). It is
> > > consistent. No luck with those channels over the last 4 days.
> > >
> > >
> > >
> > > Is it the IVTV driver or the Hauppauge cards? I bought them all
> > > in the last 2 months, and there are a variety of tuners (TCL,
> > > Phillips, Samsung, and LG) on these cards. I believe I've tested
> > > with all of those varieties. The Tuner appears NOT to be the
> > > variable. The picture seems to be fine as well, using the
> > > Hauppauge cards.
> > >
> > >
> > >
> > > I have not yet tried one of the Hauppauge cards in Windows Media
> > > Center, so yes I will do that next and let you know.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Rich
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Rich Kadel
> > >
> > > Know'bout, Inc.
> > >
> > > (858) 433-1747
> > >
> > > www.knowbout.com
> > >
> > >
> > >
> > > Do you know about Know'bout?
> >
> > _______________________________________________
> > ivtv-devel mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel