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
--
===
Chris Kennedy
[EMAIL PROTECTED]
-------------------------------------------------------
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
