GNOME Bugzilla – Bug 615466
[hdv1394src] mpegts clock starting at large nonzero offset
Last modified: 2010-10-04 18:44:48 UTC
As of head, the hdv input using the hdv1394src, mpegtsdemux and mpeg2dec works, though the clock as reported is starting from some large offset (the absolute clock in the mpegts stream?) It appears to be reporting from the time when the firewire link started, not when the script started, and this offset means it can't work with any other source as the other sources are starting from zero and the pipeline timings can't reconcile. This means, eg, we can't use an HDV cam with an ALSA audio input. fishcore:~/icecast> ./gst-icecast Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: MpegTSClock progressreport0 (00:00:05): 219 seconds progressreport0 (00:00:10): 224 seconds progressreport0 (00:00:15): 229 seconds progressreport0 (00:00:20): 234 seconds script producing this: gst-launch \ hdv1394src \ ! mpegtsdemux \ ! mpeg2dec \ ! progressreport \ ! filesink location=/dev/null
Could you attach a gzipped GST_DEBUG=*:5 log of the first few seconds?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Re-opening and adding Edward since he's got gear to debug/reproduce this.
There is going to be one fundamental problem you can't circumvent though.... which is the internal latency added by the camera for the mpeg2 encoding process. I still haven't found a way to query it via avc1394 instructions, and I'm not sure it can even be done. I'll try to figure out if we can't reduce the other timing/latency to a minimal though.
The stream time seems correct nowadays. Closing bug :)