[Gstreamer-bugs] [Bug 108301] Changed - source element synchronization (clock)

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=108301

Changed by rbultje at ronald.bitfreak.net.

--- shadow/108301	Sun Mar 30 16:14:26 2003
+++ shadow/108301.tmp.22463	Wed Apr  2 09:21:47 2003
@@ -43,6 +43,26 @@
 
 
 ------- Additional Comments From rbultje at ronald.bitfreak.net  2003-03-30 16:14 -------
 Created an attachment (id=15316)
 try #2 - also redoes state changing a bit
 
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2003-04-02 09:21 -------
+Now that audio is done, here's what's to be done for video:
+
+<BBB> I make a property use_fixed_fps
+<BBB> (boolean)
+<BBB> if TRUE, we try to drop/insert frames to keep as close to the
+framerate that we're supposed to give out (25fps/29.97fps) and report
+that framerate on _convert() and _query()
+<BBB> if FALSE, we just insert frames for lost ones (to prevent sudden
+glitches) and don't do any further processing (so no framedrops) and
+report the framerate at which we're actually giving out frames
+<BBB> in the first case, the timestamp is just num_frames * GST_SECOND
+/ fps
+<BBB> the fps is fps
+<BBB> in the second case, this is tricky
+<BBB> we do gst_clock_get_time() and substract the time when we went
+from PAUSED->PLAYING (this gets even more tricky when we go from
+PLAYING->PAUSED and back, but that should be fixable too)
+<BBB> the fps is num_frames * GST_SECOND / that