We are still testing it, but the synch seems pretty good and stable. When the frame drop is too heavy , you can actually see the image "hop", but otherwise the synch is quite correct. We are talking about recordings of a couple hours in length, so a accumulative lag would be more than apparent.
The problem with Gstreamer is that each component does *exactly* what it is supposed to (provided you know how to use it correctly --1st problem), and *nothing else* (2nd problem). Combinating the simple elements in the right order to get the right result is certainly difficult at first. But I guess experience makes you go closer and closer. Good luck Rubén 2011/11/16 Edmore Moyo <[email protected]> > Hi Rubén, > > I will certainly give that a try. Is your output always 100% in sync? or > do you have the occassional 1second lag? > > Regards, > > Edmore Moyo > > UCT > > > > >>> Rubén Pérez<[email protected]> 11/16/2011 11:35 AM >>> > > Again, I suggest you to use a caps filter *after* the videorate > component, and not before. I think that fixing it in the camera may have no > or little effect. > > > I'm just guessing, though, but please give it a try, if you want. > > > Best regards > > Rubén > > > 2011/11/16 Edmore Moyo <[email protected]> > >> Hi, >> >> >> Thank you for the advice. We went ahead and made changes to our >> configuration: >> >> >> capture.device.Presenter.customProducer=v4l2src device=/dev/video1 ! >> image/jpeg,width=1280,height=720,framerate=15/1 ! queue ! jpegdec ! >> videorate ! ffmpegcolorspace >> >> capture.device.Presenter.flavor=presenter/source >> >> capture.device.Presenter.outputfile=Presenter.avi >> >> capture.device.Presenter.src=/dev/video1 >> >> capture.device.Presenter.type=CUSTOM_VIDEO_SRC >> >> >> This has given us an almost consistent output. Its not perfect but >> quite acceptable, there are 1 second lags between the Presenter and the >> Presentation on some parts when viewed using the engage player. The audio >> and the Presenter are totally in sync. The output auto corrects, usually >> towards the end. >> >> Is this the output you guys are getting? or is your output 100% in sync? >> >> >> Regards, >> >> >> Edmore Moyo >> >> UCT >> >> >> ### >> >> UNIVERSITY OF CAPE TOWN >> >> This e-mail is subject to the UCT ICT policies and e-mail disclaimer >> published on our website at >> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 >> 21 650 9111. This e-mail is intended only for the person(s) to whom it >> is addressed. If the e-mail has reached you in error, please notify the >> author. If you are not the intended recipient of the e-mail you may not >> use, disclose, copy, redirect or print the content. If this e-mail is not >> related to the business of UCT it is sent by the sender in the sender's >> individual capacity. >> >> ### >> >> >> _______________________________________________ >> Matterhorn-users mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> >> > > ### > > UNIVERSITY OF CAPE TOWN > > This e-mail is subject to the UCT ICT policies and e-mail disclaimer > published on our website at > http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 > 21 650 9111. This e-mail is intended only for the person(s) to whom it is > addressed. If the e-mail has reached you in error, please notify the > author. If you are not the intended recipient of the e-mail you may not > use, disclose, copy, redirect or print the content. If this e-mail is not > related to the business of UCT it is sent by the sender in the sender's > individual capacity. > > ### > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
