Screenshot showing how videomixer is not maintaining sync

[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.


--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Screenshot-showing-how-videomixer-is-not-maintaining-sync-tp3753595p3756218.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.