GNOME Bugzilla – Bug 169383
[dv1394src] Should provide a clock
Last modified: 2010-04-29 21:56:16 UTC
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
Quick hack: dv1394src ! queue leaky=1 ! { dvdec name=dec ! ... } The correct approach is to have dv1394src provide a clock (and also to make it work with foreign clocks). For timestamps, it could either parse packet headers or query the downstream decoder. If the assigned clock != provided clock, we'll need some interaction between source/decoder to make sure timestamps match the actual clock. Note that this would still have issues because sink/source clock matching is sometimes painful. See bug #148609 for an example. That is a separate issue that we need to solve as well.
Yep. I've been thinking about that. But I was steered away when I checked the clock on sdlvideosink and seen a null. See Bug 169396: clock api broken by GstVideoSink However there's more to it. dvdec (and I suspect ffmpeg demuxing/decoding too) will ignore the timestamps dv1394src provides and regenerate them. This would become a problem in cases like a ieee1394 device that's intentionally playing fast (jog control). Not the issue I'm having now. But still something to think of.
This issue is being addressed fully in 0.9/0.10 as part of planned work. The chances for it getting fixed within 0.8 at this point is very small so I am closing this bug.
This bug has not been adressed in 0.9 yet.
dvsrc is live and should provide a clock. Since the clock is provided by a source element, it will be prefered over the alsasink clock. Alsasink will slave its clock to this clock and will adjust its rate to it.
So to fix this bug in 0.10 one would do as Wim says, and make dv1394src provide a clock. Updating the version.
this is not really an enhancement because without it, things just don't work properly.
disabling sync with the sync=false option on the sinks will work around the problem and will make the sinks follow the rate of the source.
*** Bug 343581 has been marked as a duplicate of this bug. ***
Andrea, does this still fail when using wim's instructions from #8 ? Also, re-assigning to good (where dv1394src lives).
(In reply to comment #10) > Andrea, does this still fail when using wim's instructions from #8 ? > > Also, re-assigning to good (where dv1394src lives). > Sorry Edward but the system I had developed was not a commercial product: it was a multimedia installation that have lived for about an year and then it was dismantled. Besides I'm no more doing SW development (now I'm doing technology consulting for a movie producer and am more concerned with video production and post production, than with video and media fruition). Therefore I'm no more in the position to check this (maybe mere curiosity may someday push me into trying some gstreamer pet project on a Mac, however). Maybe someone that is currently working with gsteamer, has a firewire port and has a DV camcorder could try it for you. I remember being able to see the problem with the very simple chain in the OP. Even by setting it up with the command line tool (sorry, do not remember what that's named, but you know what I mean). Run it and then let it run for a few minutes: if the clocks are even a little bit out the displayed image will noticeably lag behind after a while (lag slowly but monotonically increasing over time).
*** Bug 594605 has been marked as a duplicate of this bug. ***
From bug #594605 comment #0 > Seems to be possible to capture the Isochronous Timer Register using the > RAW1394_IOC_GET_CYCLE_TIMER ioctl.
I added clock code in git. Needs someone to review it.
(In reply to comment #14) > I added clock code in git. Needs someone to review it. I don't know much about how clocks work but your get_internal_time always returns 40*some_time_representation. Wouldn't it be better to override get_resolution instead of always multiplying with 40?
The current clock is wrong and a faster than what it should be (http://www.dennedy.org/libraw1394/API-raw1394-read-cycle-timer.html). I proposed a fix here:https://bugzilla.gnome.org/show_bug.cgi?id=593910. The seconds counter and the cycles counter must be treated as separate counter. Each cycle is 125us and the cycle counter has 13 bits: 2^13 * 125us != 1 second Thus the overflow of the cycle counter is not a second. The good approach is to read the seconds from the seconds counter and than sum the microseconds from the cycle counter
Is this still relevant? A clock has been added as far as I can tell, and been fixed (bug #593910) but another bug claims it continues to be broken (bug #615461). Either way, it seems like this can be closed as OBSOLETE. Please re-open if I've overlooked something.