<br>In reference to this discussion:<br><br><a href="http://gstreamer-devel.966125.n4.nabble.com/Still-can-t-get-videomixer-to-do-live-video-at-full-frame-rate-td3748457.html">http://gstreamer-devel.966125.n4.nabble.com/Still-can-t-get-videomixer-to-do-live-video-at-full-frame-rate-td3748457.html</a><br>
<br>Here is a screenshot showing the the videomixer is not maintaining sync. Both capture cards are fed from the the same VCR via a distribution amp. Note the more than one frame skew in the gsttimeoverlay between the top on bottom images, also note the timecode overlaid on the original recording (using an HEI video inserter device). These should be the same in both frames.<br>
<br>At the start of the recording (first frame) the skew is zero (streamtime=0) and the HEI timecode matches. On the next frame the streamtime skew is 9 milliseconds and the HEI timecode matches. Slow the skew grows until a frame is dropped, an so on until another frame is dropped.<br>
<br>I can post the code if anyone wants to give it a try on maybe a newer gstreamer (I'm using Ubuntu 10.04, videomixer 0.10.21)<br><br>But you will need two V4l2 capture devices fed from the same source, and some other way to set the NORM and INPUT as the gst-tuner interface is clunky and not 100% reliable across the 7 or 8 capture devices I have access to, so I've ripped it out of this test version for simplicity. The error is subtle and unless you have some other independent way to detect that the top and bottom video frame have skewed, it will likely appear to be working "correctly" while recording with only the increasing streamtime skew as a clue on the output file.<br>
<br>I can post it or or Email it privately, its just a single file with a simple build command.<br><br>