I've been cleaning up the tvp5158 drivers, both kernel and user space, to suit my needs. I'm at the point now where I have valid 8 bit BT.656 data coming in, but it is not synchronized on a vblank. I checked the vpfe and tvp5158 registers countless times, but came up with nothing.
With that in mind, I went back to the older dvsdk and added some debug output in the demux provided mcvip driver.
I found that it is not syncing on vblank either, at least with the UDWORKS DVR hardware which I have.
Here's an example of what would happen, and the mcvip demux would happily eat it up:
+------------------------------+
| |
| Bottom of field 0, frame 2 |
| |
+------------------------------+
+VBLANK VBLANK VBLANK VBLANK +
+------------------------------+
| |
| |
| Complete field 1, frame 3 |
| |
| |
| |
+------------------------------+
+VBLANK VBLANK VBLANK VBLANK +
+------------------------------+
| |
| Top of field 0, frame 3 |
| |
+------------------------------+
The final frame constructed by the mcvip_demux would use the lines from the bottom of field 0 frame 2, the complete field 1 from frame 3 and the top of field 0 from frame 3. The final frame might appear correct, but it's not. There's a good chance of tearing.
Any thoughts on what I am missing? Should the first line of each embedded frame in the super frame start at 0? If so, why doesn't the internal vsync of the BT.656 signal line up with the vblank lines of the embedded frames?
