Richard Jones wrote:
CNN text crawler has classic field order jitter. Lips on speakers
likewise. Fast movement also shows bad jitter. Scene changes appear
to flick back briefly to the previous scene during scene change.
Couldn't that have different causes too, like wrong frame processing
sequence? (Since you say you're using code you modified yourself)
If you do receive a network with teletext I think that would offer
a much more reliable method for testing field sequence order. Get
libzvbi from http://zapping.sourceforge.net/ and execute in the
test directory: ./capture --dump-ttx; check the output if
teletext pages continue across field borders, e.g.:
WST 3 13 022 >.8 Schwiegersohn Daniel bietet ihr begeis-<
WST 3 14 319 >^/ tert eine Stelle in seiner Anlagebera- <
Here you see packet 13 in line 22/field A and packet 14 of the same
teletext page (since the word "begeistert" is continued) in line
319/field B. If the DMA bits were used wrongly you'd see the 2nd half
of the previous frame's teletext page in field B. Note that teletext
pages are allowed to have missing packets and may not always cross
fields, so you have to look at a larger number of pages to draw a
conclusion.
if ((status & 0x10) != 0x10)
> if ((status & 0x10) == 0x00))
> which isn't exactly equivalent.
Why not? The result of (status & 0x10) can have two values: 0 or 0x10,
since all other bits are masked out (set to zero). Hence if the result
is != 0x10 it must be == 0 so both checks are logically equivalent.
(...) but given that you mentioned the change conflicted with vendor
specified behaviour
Well, the same paragraph contains other inconsistencies, e.g. talking
about DONE_RA1..RA4 while at other places it's RA0..RA3. Also OE isn't
defined in the same chapter, but 2 pages earlier for a different
register... unfortunately there's always some room for interpretation
with specs like these.
-tom
