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 :
On Sat, 2008-07-12 at 22:11 +0000, Aurelien Grimaud (elzz) wrote:
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 http://bugzilla.gnome.org/show_bug.cgi?id=474016
This should fix it.
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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
