GNOME Bugzilla – Bug 601293
[patch] Fix dvdemux timestamping issue
Last modified: 2011-01-26 10:44:43 UTC
Created attachment 147301 [details] Log before applying the patch dvdemux does not timestamp properly outgoing buffers because the last_stop value is not calculated in the proper way. Therefore, the buffers' duration value is not set properly, which produces with the vorbis encoder a file which sound is cracking/wobbling. I attach the log with some additional debugging info to illustrate the problem, before and after the patch using the following pipeline: export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-0.10/ && export GST_DEBUG=*dvdemux*:5 && gst-launch-0.10 dv1394src ! dvdemux name=mux .audio ! identity ! audioconvert ! vorbisenc ! oggmux ! filesink location=vorbis.ogg It's the first time I hack on dvdemux so certainly there is a much better solution, but I hope that will point you to the right direction.
Created attachment 147303 [details] Log after applying the patch
Created attachment 147306 [details] [review] Fix buffer timestamping
Created attachment 147307 [details] Log after applying the patch
Created attachment 147308 [details] Log before applying the patch
Created attachment 147311 [details] Log after applying the patch
I wouldn't say the problem is in dvdemux. It is doing what's expected (that is take the incoming timestamp and forwarding it on the downstream buffer). This is a more generic problem regarding jitter in audio streams (try transcoding an asf audio file to vorbis and you'll most likely encounter the same issue). A more 'proper' fix, would be to correct that jitter. That is to see if the incoming timestamp is within a certain 'diff' of the expected next_ts, and if so adjust to use next_ts instead of the incoming timestamp. fwiw, next_ts should also be current_ts + 1/fps (and not the current code). (/me mumbles at dvdemux code needing some loving in general)
Have you tried to play the audio file using the current HEAD and the patched one? The first one is totally corrupted while the second one plays smoothly. The time stamping issue also affects video buffers. The 'duration' variable, which is calculated in gst_dvdemux_demux_frame() is also passed to gst_dvdemux_demux_video() with the wrong value. With ffdemux_dv that problem doesn't show up. To illustrate it better you should try with these pipelines: gst-launch-0.10 -v dv1394src ! dvdemux name=mux .audio ! identity ! audioconvert ! vorbisenc ! oggmux ! filesink location=vorbis.ogg gst-launch-0.10 -v dv1394src ! ffdemux_dv name=mux .audio_00 ! identity ! audioconvert ! vorbisenc ! oggmux ! filesink location=vorbis.ogg dvdemux is not doing what's expected because it's calculating the duration in a wrong way. It should be timestamping buffers at a correct framerate, which is not the case. If the next_ts is calculated using dvdemux->frame_offset+1, the last_ts or current_ts (dvdemux->time_segment.last_stop) should be calculated with dvdemux->frame_offset.
You were totally right, the bug is indeed in dv1394src. I think these two bugs are related: https://bugzilla.gnome.org/show_bug.cgi?id=593910 I have proposed a patch in the other bug is more complete
*** This bug has been marked as a duplicate of bug 593910 ***
Created attachment 155242 [details] [review] 0001-gstdvdemux-Correct-timestamp-jitter-of-incoming-buff.patch I reopen the bug since the demuxer should be able to correct the jitter of incoming buffers. Attached patch
Created attachment 155294 [details] [review] 0001-gstdvdemux-Correct-timestamp-jitter-of-incoming-buff.patch Correct the jitter if jitter<latency/2 (previous was jitter<latency)
Combining dv1394src ! dvdemux ! dvdec ! vorvbisenc produces streams with cracking audio. This issue has been reported by many users in flumotion and can be confirmed by zaheer. The timestamps of buffers from the dv source are not perfectly aligned and they should (unless there is a frame drop) because framerate is a constant in this format. The timestamps follows the following rule (without considering lost frames: ts = n_frame * 1/25 + jitter This jitter in the timestamps should be corrected by the demuxer. Could you guys review the patch or suggest a better approach?
Use audiorate with a specified tolerance (10 or 20ms should do) before the audio encoder. The issues isn't specific to dvdemux: * Audio sinks will automatically adjust for such jitter (drift-tolerance with a default of 40ms), which is why you don't hear it when playing that pipeline back with a audiosink. * Most audio encoders expect perfect audio streams. You'll have the same problem if you were to replace that live DV pipeline with a non-live ASF pipeline (the granularity of packets in an asf file is much lower than that of raw audio) or if you were to encode a RTP stream.