<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> It worked for me, with your application (recordogg.py) and cvs head with the patch 114460 Another thing you should try is block the tee src pad, not the videobin sink pad. It seems to work better this way. Request it when start the record Block it link unblock and play Release request src pad when your stop the record. Make also sure the pad is actually blocked before linking. wait your pad blocked cb to trigger, or block synchronous. For your second record, also send an eos to mux for it to stop and restart properly. your second application worked for me also. Aurelien Daniel Drake a écrit : <blockquote cite="mid:1216047322.22073.13.camel@olpc-desktop01.laptop.org" type="cite"> <pre wrap="">On Sat, 2008-07-12 at 22:11 +0000, Aurelien Grimaud (elzz) wrote: </pre> <blockquote type="cite"> <pre wrap="">tee element does not send new segment to new pad, and new_segment, is needed by videorate to work properly. In your application, when videobin is linked to tee and set to playing, the first buffer it receives has a timestamp of 5s. videorate wants its first buffer to match new segment start time (which is 0 in our case, we had no new segment). So, videorate will duplicate the first buffer 50 times to go from 0 to 5 secs with a 10/1 rate. Therefore you have a 5 seconds frozen video. Try patch from bug <a class="moz-txt-link-freetext" href="http://bugzilla.gnome.org/show_bug.cgi?id=474016">http://bugzilla.gnome.org/show_bug.cgi?id=474016</a> This should fix it. </pre> </blockquote> <pre wrap=""> Thanks for the patch. Unfortunately it doesn't fix it: the video still remains frozen. In this case, the video is not frozen for 5 seconds, it is frozen indefinitely. Daniel </pre> </blockquote> </body> </html>