Chris,
A very good source for raw VBI testing and information is the libzvbi library
(http://sourceforge.net/projects/zapping). Especially the test/osc tool which
shows the contents of the VBI area realtime.
I've run nxtvepg with this patch for awhile without any dropped frames. In
what circumstances and how often do you see missing characters, etc? I'm not
aware of any problems in that area.
Hans
On Tuesday 09 August 2005 21:47, Chris Kennedy wrote:
> Hans,
>
> Ah, that's a good thing then, although you hadn't included the patch
>
> :). One question then is if it loses characters ever in teletext mode
>
> like in CC mode, I thought the missing characters were from this
> timestamp insert, maybe part of it at least, although I see what your
> saying and it brings up the question of what is going on (is it just CC
> and line 21 corruption, bad signals, low signals, affecting all services
> for any lines). So sounds like the patch should be no problem then, I
> think I had made it able to split up the buffers and still insert those
> right still, so I think that problem should be solved, but interested in
> seeing the patch to make sure and apply it :).
>
> Also if you have any links to sources of slicing raw VBI, stuff I could
> look into this with to know more about the sliced and raw, getting it
> from raw to sliced, and able to get a better grip on how the raw data
> could be missing chunks and understanding of exactly what we are doing
> to convert lines to the 2 bytes or however big of payload for the data
> service. I would be interested in any information you may have or where
> to look for that, would be very helpful in understanding it more.
>
> Thanks,
> Chris
>
> Hans Verkuil wrote:
> >Chris,
> >
> >This really isn't a problem. The raw VBI parsers don't care if the VBI
> > lines are offset by a random amount of bytes (within limits, of course.
> > If it's off by more than 100 bytes you might get into trouble). The
> > start-stop codes are ignored anyway.
> >
> >At least alevt and nxtvepg rely on the frame counter being part of the raw
> > VBI data and will fail to work if it is absent. So it really must be
> > present.
> >
> > Hans
> >
> >On Tuesday 09 August 2005 21:06, Chris Kennedy wrote:
> >>Hans,
> >>
> >>This was commented out becasue upon further inspection of the raw VBI
> >>data I found that the stop/start codes it is trying to overwrite are not
> >>always there, basically the raw VBI alignment in the chips buffers are
> >>*not* perfectly aligned to the stop/start codes. It's as if we really
> >>have to parse the start/stop of each packet and fixup the raw VBI data
> >>ourselves. If you check the Windows drivers output of raw VBI it is
> >>trimmed and clean for each packet, sets the Firmware API size to 1456
> >>while gets 17280 bytes per packet (for NTSC mode) of 12 lines each line
> >>being 1440 in length. So in the Windows driver they go into the raw
> >>packet and take each line and chop it up to 1440 and put the whole
> >>packet back together without stop/start codes and what seems to be 4
> >>extra bytes of data.
> >>
> >>I dont' know enough about raw VBI formats and how it should be to know
> >>the proper trimming, but do know the current method is like russian
> >>roulette and we just are throwing in a 4 byte chunk of data randomly
> >>into the VBI stream (had code checking if we were really overwriting the
> >>stop/start codes and showed this fact too, although also just reading
> >>the buffers you see it get's offset sometimes in-stream and then every
> >>data read is off and not exactly upon packet boundrys, and seems to vary
> >>by 16 bytes when it does this).
> >>
> >>Thanks,.
> >>Chris
> >>
> >>Hans Verkuil wrote:
> >>>(Sourceforge seems to have eaten this mail, so I'm mailing it again)
> >>>
> >>>This patch fixes alevt & nxtvepg support: alevt expects a sequence
> >>> number at the end of the raw VBI data. This was commented out by
> >>> someone and has been reinstated at the proper place.
> >>>
> >>>Also, the alevt patch now also fixes an alignment problem for 64-bit
> >>>systems.
> >>>
> >>>Regards,
> >>>
> >>> Hans
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>>Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> >>>Testing & QA Security * Process Improvement & Measurement *
> >>>http://www.sqe.com/bsce5sf
> >>>_______________________________________________
> >>>ivtv-devel mailing list
> >>>[email protected]
> >>>https://lists.sourceforge.net/lists/listinfo/ivtv-devel
> >
> >-------------------------------------------------------
> >SF.Net email is Sponsored by the Better Software Conference & EXPO
> >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> >ivtv-devel mailing list
> >[email protected]
> >https://lists.sourceforge.net/lists/listinfo/ivtv-devel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
