GNOME Bugzilla – Bug 593910
[dv1394src] live streaming / clock issues
Last modified: 2010-03-18 21:41:09 UTC
I used gstreamer to streaming live video and audio stream from dv-camcorder to icecast streaming server. When I updated to latest gstremaer version (0.1.24) and gst-plugins-good (0.10.16) I get problem with audio channel. Also oggz-validate say that: testi.ogg: Error: 00:00:01.558: serialno 0181621575: Packet out of order (previous 00:00:01.567) 00:00:01.558: serialno 0181621575: Granulepos decreasing within track 00:01:18.285: serialno 0181621575: Packet out of order (previous 00:01:18.294) 00:01:18.285: serialno 0181621575: Granulepos decreasing within track 00:01:18.848: serialno 0181621575: Packet out of order (previous 00:01:18.857) 00:01:18.848: serialno 0181621575: Granulepos decreasing within track 00:01:39.694: serialno 0181621575: Packet out of order (previous 00:01:39.703) 00:01:39.694: serialno 0181621575: Granulepos decreasing within track 00:01:52.695: serialno 0181621575: Packet out of order (previous 00:01:52.704) 00:01:52.695: serialno 0181621575: Granulepos decreasing within track 00:02:05.697: serialno 0181621575: Packet out of order (previous 00:02:05.705) 00:02:05.697: serialno 0181621575: Granulepos decreasing within track oggz-validate: maximum error count reached, bailing out ... pipeline what I used: dv1394src use-avc=true ! queue leaky=1 ! \ dvdemux name=dv \ { dv.audio ! queue ! \ audioresample ! audio/x-raw-int,rate=32000 ! \ audioconvert ! audio/x-raw-float,channels=1 ! \ vorbisenc quality=0.3 ! queue ! mux. } \ { dv.video ! queue ! \ dvdec name=dvideo quality=5 ! \ ffmpegcolorspace ! "video/x-raw-yuv",format=\(fourcc\)I420 ! \ videocrop right=36 left=36 top=0 bottom=0 ! \ queue ! videoscale method=2 ! "video/x-raw-yuv",width=576,height=360,pixel-aspect-ratio=1/1 ! \ queue ! \ videorate ! "video/x-raw-yuv",framerate=25/1 ! \ theoraenc bitrate=720 keyframe_force=75 sharpness=2 keyframe_freq=50 quick=true ! \ queue ! mux. \ { oggmux name=mux ! \ queue ! shout2send..... I tested also stream from .dv-file (using filesrc) using same pipeline, and all works fine! I noticed that some changed has been maked for latest relases. Can anybody help?
As a workaround, use dv1394src do-timestamp=false.
This could also be fixed by the following commit. Can you check if it works with that commit? commit 3dc2c2472c0b70a05b09c2248e9c332fdb08b98d Author: David Schleef <ds@schleef.org> Date: Wed Sep 9 17:51:19 2009 -0700 dv1394src: Add a clock based on isochronous cycle counter Partial fix for #169383.
Created attachment 148112 [details] [review] Proposed patch I also run into the same error but your commit does not work for me. There is an issue with time stamping: dv1394src should be time stamping buffers at 'frame_offset * 1/framerate' This is the timestamping with current HEAD: gstdvdemux.c:1264:gst_dvdemux_demux_audio: pushing audio 0:00:00.174849320 gstdvdemux.c:1354:gst_dvdemux_demux_video: pushing video 0:00:00.174849320 gstdvdemux.c:1264:gst_dvdemux_demux_audio: pushing audio 0:00:00.220122320 gstdvdemux.c:1354:gst_dvdemux_demux_video: pushing video 0:00:00.220122320 gstdvdemux.c:1264:gst_dvdemux_demux_audio: pushing audio 0:00:00.261218120 gstdvdemux.c:1354:gst_dvdemux_demux_video: pushing video 0:00:00.261218120 And this is the timestamping after applying the patch: gstdvdemux.c:1264:gst_dvdemux_demux_audio: pushing audio 0:00:00.040000000 gstdvdemux.c:1354:gst_dvdemux_demux_video: pushing video 0:00:00.040000000 gstdvdemux.c:1264:gst_dvdemux_demux_audio: pushing audio 0:00:00.080000000 gstdvdemux.c:1354:gst_dvdemux_demux_video: pushing video 0:00:00.080000000 gstdvdemux.c:1264:gst_dvdemux_demux_audio: pushing audio 0:00:00.120000000 gstdvdemux.c:1354:gst_dvdemux_demux_video: pushing video 0:00:00.120000000
You can also look at https://bugzilla.gnome.org/show_bug.cgi?id=601293 for more info, which I opened thinking the error was in dvdemux.
Comment on attachment 148112 [details] [review] Proposed patch looks good, will apply after freeze
*** Bug 601293 has been marked as a duplicate of this bug. ***
No, this patch is wrong. It ignores dropped frames or stream corruption.
You are right David. Is this the normal behaviour? Is it possible to get the BaseSink writing perfect timestamps or should this be rather fixed in dvdemux as suggested by Edward?(https://bugzilla.gnome.org/show_bug.cgi?id=601293#c6)
What clock is getting used? In a live stream, it should be dv1394clock. I'm seeing timestamps here that have the wrong interval, which needs to be fixed.
It's using the GstDV1394Clock clock. As you can see in the description of #601293, ffdemux_dv doesn't seems to care about this small diff in the timestamping and will output frames timestamped with a separation of 40ms for PAL@25fps using the same source So my question is: Should I try to correct his jitter in the source or in the demuxer? Thanks
After some more tests I have more questions :) Using the following pipeline 'gst-launch -v dv1394src ! fakesink' I get: timestamp: 0:00:00.097398880, offset: 1, timestamp: 0:00:00.138369400, offset: 2, timestamp: 0:00:00.220215160, offset: 3, timestamp: 0:00:00.261179040, offset: 4, timestamp: 0:00:00.302219600, offset: 5, timestamp: 0:00:00.384036320, offset: 6, timestamp: 0:00:00.425097440, offset: 7, timestamp: 0:00:00.466067720, offset: 8, timestamp: 0:00:00.506912160, offset: 9, timestamp: 0:00:00.588985560, offset: 10, timestamp: 0:00:00.629886520, offset: 11, timestamp: 0:00:00.670746000, offset: 12, timestamp: 0:00:00.711674080, offset: 13, timestamp: 0:00:00.793784520, offset: 14, timestamp: 0:00:00.834561280, offset: 15, timestamp: 0:00:00.875678200, offset: 16, timestamp: 0:00:00.957566560, offset: 17, timestamp: 0:00:00.998437160, offset: 18, timestamp: 0:00:01.039347320, offset: 19, timestamp: 0:00:01.080274040, offset: 20, timestamp: 0:00:01.162292240, offset: 21, timestamp: 0:00:01.203333920, offset: 22, timestamp: 0:00:01.275629640, offset: 23, timestamp: 0:00:01.357669680, offset: 24, timestamp: 0:00:01.398504360, offset: 25, Why does the time diff between frame 1 and 25 is 1,32 seconds when it should be 1 second? The average diff between frames is 40ms, but in some cases it's 80ms, does that means a frame has been dropped? If this is the case with the frame offset is not increased? You also commented that my patch was not valid because it was using the frame offset to write the timestamp but I see the dvdemuxer using the same approach to calculate the timestamp of the next frame (http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/dv/gstdvdemux.c#n1434). What would be the right thing to do? Thanks, Andoni
Created attachment 155247 [details] dv1394src source log I attach a new log to illustrate more the issue. The problem seems to be in the new GstDV1394Clock. From frame 1 to 25 the GStreamer clock increase 1 second while the Gstdv1394Clock increase 1.20 seconds. I hope that helps :)
What it's supposed to be doing is using the GstDV1394Clock, and then outputting timestamps based on the stream timestamp information coming back from the driver. The clock timestamps are based on the stream timestamps, so one should theoretically get a constant rate.
I found a bug in the clock, I'll post the patch in few minutes :)
Created attachment 155291 [details] [review] 0001-dv1394src-Fix-internal-clock.patch The current clock joins cycleSeconds and cycleCounter to compute the current time, but these counters must be treated separately, the first one to get the seconds and the second one to retrieve the current cycle , where each cycle is 125 microseconds (http://www.dennedy.org/libraw1394/API-raw1394-read-cycle-timer.html). The current time is the sum of each counter.
Good catch. I wonder wtf I was thinking.
It took a while to figure out was going on :) I hope the patch is goog enough to be applied upstream. Cheers
Tested, this patch fixes a bug in my application (that uses dv139src and dvdemux).
commit 63624f966e4f24145bc6c1b1e6a441c119eb6976 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Thu Mar 4 22:12:35 2010 +0100 dv1394src: Fix internal clock Fixes #593910.