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

bugzilla-daemon at widget.gnome.org bugzilla-daemon at widget.gnome.org
Thu Mar 13 06:43:13 PST 2003


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	Thu Mar 13 09:43:13 2003
+++ shadow/108301.tmp.6467	Thu Mar 13 09:43:13 2003
@@ -0,0 +1,38 @@
+Bug#: 108301
+Product: GStreamer
+Version: cvs
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: major
+Priority: Normal
+Component: gst-plugins
+AssignedTo: rbultje at ronald.bitfreak.net                            
+ReportedBy: rbultje at ronald.bitfreak.net               
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: 0.6.x
+URL: 
+Summary: source element synchronization (clock)
+
+Video and audio (realtime) source elements should syncornize themselves to
+the GstClock that's leading the element.
+
+Let's assume a situation where we want the audio to be master and the video
+slave (i.e. audio sets the clock, video synchronizes according to it),
+osssrc (or alsasrc, or ...) should set the clock. Besides that (in case
+this fails!), it should also test whether the clock was actually set and if
+not, it should resample internally to make sure that it reaches the
+requested audio playback rate. v4l*src should drop/insert frames to reach
+the requested fps (25/PAL or 29.97/NTSC) and should also correct for lost
+frames. QoS might also be used here (FIXME: how?).
+
+Billy (vektor) disagrees here, btw, he thinks video should be the master.
+Another option here is to just set a different framerate (tell the
+following elements that we're actually 25.02 fps or so) and not drop/insert
+frames at all... this might get messy, though, most files 'just' set 25fps
+and you want to try to reach that framerate yourself too...
+
+All of this together means, though, that the output framerate/samplerate of
+v4l*src/audio*src, the timestamps used on the buffers and the one given in
+the caps/_convert() functions should match, which currently is not the case.





More information about the Gstreamer-bugs mailing list