GNOME Bugzilla – Bug 637812
vorbisenc: choppy sound due to input timestamp jitter
Last modified: 2012-02-18 20:09:01 UTC
After encoding or recoding some sources i get choppy sound if i use vorbisenc, if i use flacenc i get warnings about wrong timestamps and suggestion to use audiorate. If i do not use audiorate with flaenc i get good sound. If i use audiorate with flacenc i get same kind of choppy sound like with vorbisenc. I assume vorbisenc has some kind of build in timestampcorrection/audiorate. Here is the pipeline i use to recode: gst-launch -e oggmux name=mux ! filesink location=tmp.ogg filesrc location=1888-de_1.10-wilhelm_und_die_welt.asf ! asfdemux name=demux demux.audio_00 ! ffdec_wmav2 ! audioconvert ! audiorate ! vorbisenc ! mux. in other hand ffdec_wmav2 may produce wrong timestamps. The video to reproduce you can find here: http://wstreaming.zdf.de/zdf/veryhigh/101104_karl1_lioudfa_did.asx i use mplayer to dump this stream: mplayer -dumpstream -playlist http://wstreaming.zdf.de/zdf/veryhigh/101104_karl1_lioudfa_did.asx
Most likely due to the timestamp jitter due to the asf container. Try the following: * put audiorate just after the decoder * set the audiorate tolerance property to a non-zero value (20ms normally clear out the issues for me, but more might be needed). The property is in nanoseconds, so 20 ms would be 20 000 000
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!
Sorry... audiorate with 30ms do the job. With flacenc i do not need audiorate.
Please try to the latest -good git, where a draconian discontinuity detection was recently relaxed. Nowhere like 30ms though, but the full 30ms might not be needed.
Alexey, can you please try with latest GStreamer as mentioned in comment#4 and respond back ?
Hi, i tested current -good git (from 2011.11.02) and i still can reproduce it.
Do any one working on this bug? Or is it just: "test latest version, may be wonder happens"-bug? If yes, i can invest some tom to investigate this issue. The only problem will be, who will push the patch? There is lots of patches i provided, and still not in git. Why should i add one more patch to the this list?
vorbisenc is in -base, so not clear what was tested with latest -good git. In any case, latest vorbisenc is based on audioencoder (as is flacenc iirc), with comes with a tolerance property, pretty much acting as an internal audiorate and specifically meant to do away with this possible mess of draconian discontuinity (so if audiorate did the job as reported before, so should that). Will see about having a look at this later on (if so still needed and provided example link still available).
(In reply to comment #8) > vorbisenc is in -base, so not clear what was tested with latest -good git. I updated all needed parts, include gstreame, gst-plugins-* and gst-ffmpeg. > In any case, latest vorbisenc is based on audioencoder (as is flacenc iirc), > with comes with a tolerance property, pretty much acting as an internal > audiorate and specifically meant to do away with this possible mess of > draconian discontuinity (so if audiorate did the job as reported before, so > should that). > > Will see about having a look at this later on (if so still needed and provided > example link still available). Thank you for your work. After some digging in code, i see that asfdemux provide wrong timestamps for audio. The block duration provided in file seem to be wrong too, the number looks more like garbage.
Downloaded (part of) this stream and used above pipeline to convert, but basically all works fine. More precisely, audioconvert ! vorbisenc has the (default) tolerance working just fine and it eats most jitter (except 1 instance) as they are below (default) 40ms. So does audioconvert ! audiorate tolerance=40000000 ! vorbisenc work fine (for same reason). However, audioconvert ! audiorate ! vorbisenc does exhibit some chop, but that is then to be expected since that operates with tolerance=0 which will have audiorate reacting a lot to the jitter (cf Comment #1). So, this seems pretty much NOTABUG or OBSOLETE (since vorbisenc based on audioencoder), unless some audio*:5 log can be provided for e.g. audioconvert ! vorbisenc combination showing the latter producing a great deal of discontinuity.
You right, i forgot to remove audiorate from pipeline. Without audiorate it produce clean output.