On Tuesday 27 January 2009 02:47:54 Andy Walls wrote:
> On Mon, 2009-01-26 at 11:48 +0100, Hans Verkuil wrote:
> > On Monday 26 January 2009 04:38:17 Andy Walls wrote:
> > > In working on Sliced VBI for the cx18 driver, I've pared down and
> > > commented the "struct vbi_info" definition. Did I understand
> > > everything that's going on based on the revised definition below?
> >
> > See comments below.
> >
> > > (BTW the mini MPEG-2 PS parser function borrowed from ivtv to look
> > > for splice points was very elegant given the task it had to perform -
> > > impressive.)
> >
> > Thanks! But it's still an ugly hack.
>
> OK. On the macro level, splicing in one's own packets is a hack. :)
>
> > Although the cx23415/6 is supposed
> > to be able to insert the sliced VBI data into the MPEG stream by
> > itself, it created a corrupt MPEG stream when I tried that at the time.
> > However, I've never tried it with the latest firmware, so it might be
> > fixed by now.
>
> Did you always use the 10 bit VIP-1.1 mode of the digitizer, or did you
> also try VIP-1.0, VIP-2.0, BT.656 and 8 bit mode as well?
I never changed the mode of the digitizer. That wasn't the problem, from
what I remember. It's a long time ago, but as I recall the firmware
actually did get the VBI data right, but the splicing in the MPEG stream
was wrong, so the stream was unplayable.
> I did some reading on the checksum that's in the ancillary data. In
> 10-bit mode, it's a 10 bit value computed with all 10 bits of the values
> summed. I noted I wouldn't be able to check it, because I don't have
> access to the two LSB's after the binary point for all the values in
> question. It could be that Encoder firmware couldn't check the CS value
> in the ancillary data either. Maybe 8-bit mode would help. Maybe
> precisely controlling the value of the Task bit in the RP codes as one
> can do in VIP-2.0 mode, would help.
>
> > The cx23418 has a similar feature and I would certainly attempt to test
> > that first. It makes life a lot easier if the firmware can handle it
> > properly.
>
> I believe MythTV already understands the ivtv way of doing VBI. Since,
> I'm runinng out of time before Feb 17 to test analog CC over the air, I
> figured I get the ivtv way working first, since the code is mostly set
> to do that anyway and MythTV will be a test/verification tool.
Do you already have the PVR-350? If so, then I can provide you with both
NTSC and PAL recordings containing CC and WSS/VPS data that you can use to
play on the PVR-350 and feedback to the cx18. Unfortunately, you cannot
test teletext that way since it isn't possible to output that on the
PVR-350. This is how I test CC here in PAL country.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
