[Openchrome-users] opechrome tv-output shuffles fields

[nico berndt]

Hello everybody!

I happily found the TV-Out of my VIA Epia EN12000EG to be one of the 
rare cases to provide me with an unscaled and very good looking 
PAL-picture. I was looking for such thing on a sbc for ages, since I 
depend on proper TV-Outputs for my work.
Sadly the TV-output is not all the way proper: It shuffles fields. Did 
anybody notice this? Terry Barnaby wrote about the field order possibly 
being changed, but it actually is worse.. I suppose you would not really 
see this on a regular tv set, but when captured again you do.

To explain a little deeper what I mean by shuffling fields:
Proper video consists of frames consisting of even and odd fields: 
[o1/e1] [o2/e2] [o3/e3] [o4/4] [o5/e5] [o6/e6]
For progessive content, such as most DVD movies, both fields within a 
frame sum up to a progressive frame again and the captured output should 
again look line described above. But it looks like this [o1/e1] [o2/e3] 
[o3/e3] [o4/e4] [o5/e6] [o6/e6]. I analyzed thousands of frames and 
there is no pattern behind it, totally not! I don't quite understand 
what is going on. I've seen video outputs mess up with the geometry and 
badly shuffling fields, even starting the next field right in the middle 
of another field, all torn, so this is not really a surprise. The 
surprise is that the odd and even fields _always_ come in the right 
order but from wrong frames! And that really bugs me, because I can not 
image how this is happening. It looks like the encoder chips were surely 
capable of doing everything right. One point that leads me to this 
conclusion ist the stubburn order of the fields. Since it never mixes 
up, I suppose the modelines to be very accurate. An often seen problem 
is that the vga chip uses a refresh rate that is not exactly 50.00 Hz 
(for PAL) and the encoder chip chokes up on trying to capture 50.10 Hz 
into 50 fields.

If tere is any interest I could privide my testvideo wich consists of 50 
different frames displaying photos and large numbers from 01 to 25. The 
position of the numbers changes all the time and there is also a stamp 
"odd" or "even". "odd" is stamped into odd lines only, and "even" 
accordingly. The whole thing comes as a dv type avi file, so the video 
is I-frame only and the fields are encoded seperately. Having this and a 
capture card one can spot errors immediately just by reading "number" 
and o/e.

So if there is any interest i'd provide this one and offer my help in 
thinking and testing. I am no coder, sorry, no...

Best regards and thanks to everyone involved building this driver!

../nico berndt