[gstreamer-bugs] [Bug 169383] New: gst sink clock vs external device clock drifting

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=169383
 GStreamer | gst-plugins | Ver: 0.8.8

           Summary: gst sink clock vs external device clock drifting
           Product: GStreamer
           Version: 0.8.8
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: analogfile-gst at kuva.it
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


simple: grab digital data from an external device that has a clock sligltly
faster than the one used by your rendering sinks. For me it's as simple as
chaining "dv1394src ! dvdec name=dec ! sdlvideosink  dec. ! ossink"

The camera sends a 25fps PAL DV stream. dv1394src reads it as an isocronous
stream and sends it out to the decoder (it has no clock and I've not checked how
the buffers are timestamped). The decoder decodes and demultiplexes. I checked
the source: it timestamps the buffers for the src pads according to the
framerate (pal/ntsc). Allright. But then the camera clock is a bit faster than
the clock used by the gst sinks. So i'm lagging behind.

I can accept a little delay. But not a monotonically increasing one. In my
system the camera is filming a stage and the stream is sent to both hard-disk
for recording and to a huge screen for the public to follow the live event even
from "behind the crowd".

I can think of many hacks. But I'm not sure what the correct approach would be. 
Therefore I'm asking here.

Thanks.
AF

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.