Screenshot showing how videomixer is not maintaining sync

[wally_bkg]

In reference to this discussion:

http://gstreamer-devel.966125.n4.nabble.com/Still-can-t-get-videomixer-to-do-live-video-at-full-frame-rate-td3748457.html

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.

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.

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)

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.

I can post it or or Email it privately, its just a single file with a simple build command.


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[wally_bkg]

Adding videoscale elements may have fixed the issue, or at least transformed it to a frame skew at start up, depending on the pair of capture devices used.

If its consistent for the capture pairings, I can try to arrange to use pairs without the skew, or use the v4l2src "device-name" property to drop the appropriate number of frames on startup.

Suggestions on which element might be used to drop the first "n" frames and pass the rest unchanged?


Any insights as to why

                link_ok=gst_element_link_many(source, colorspace, vrate, scale, I420filter, tover, queue, mixer, vqueue, NULL);
                link_ok=gst_element_link_many(source1, colorspace1, vrate1, scale1, I420filter1, tover1, queue1, mixer, NULL);



Crashed (SegFault) when set to Playing, while:

                link_ok=gst_element_link_many(source, colorspace, scale, I420filter, vrate, tover, queue, mixer, vqueue, NULL);
                link_ok=gst_element_link_many(source1, colorspace1, scale1, I420filter1, vrate1, tover1, queue1, mixer, NULL);

works?

I'm implementing in C a variation of the gst-launch pipeline in discussed here:
http://gstreamer-devel.966125.n4.nabble.com/Why-is-videobox-videomixer-dropping-frames-td3736107.html



Testing and analysis is tedious but I've captured and recorded a 1:18:08 video and at least one of my capture device pairing stays in sync the entire time meaning any drops or duplicates quickly average to zero.