GNOME Bugzilla – Bug 652765
Audio distortion / glitch / popping when using audioconvert
Last modified: 2015-02-12 15:06:30 UTC
Distortions seem to be introduced for some inputs when using the audioconvert element. Example file to reproduce: http://jadn.com/p.flv Example command to hear distortion (it's quite clear between 3-4 seconds): $ gst-launch-0.10 uridecodebin uri="file:///home/dan/Videos/p.flv" name=dmux qtmux name=mux ! queue ! filesink name=sink location="/home/dan/Videos/p1.m4v" dmux. ! queue ! audioconvert ! audiorate ! audioresample ! faac bitrate=128000 profile=LC ! mux.audio_%d Removing 'audioconvert' from the above command stops the distortion from happening. Various audioconvert options don't seem to make a difference. Reporting this upstream from an issue originally reported here: https://github.com/danielgtaylor/arista/issues/24 The Arista iPad preset produces the equivalent gst-launch command, which was used to construct the simplified example above: $ gst-launch-0.10 uridecodebin uri="file:///home/dan/Videos/p.flv" name=dmux qtmux name=mux ! queue ! filesink name=sink location="/home/dan/Videos/p1.m4v" dmux. ! queue ! ffmpegcolorspace ! videorate ! videoscale ! video/x-raw-yuv, width=\(int\)480, height=\(int\)360, framerate=\(fraction\)25/1, pixel-aspect-ratio=\(fraction\)1/1\; video/x-raw-rgb, width=\(int\)480, height=\(int\)360, framerate=\(fraction\)25/1, pixel-aspect-ratio=\(fraction\)1/1 ! x264enc pass=qual quantizer=21 me=umh subme=6 ref=3 cabac=0 threads=0 ! tee name=videotee ! queue ! mux.video_%d dmux. ! queue ! audioconvert ! audiorate ! audioresample ! audio/x-raw-int, width=\(int\)[ 8, 24 ], depth=\(int\)[ 8, 24 ], rate=\(int\)[ 8000, 96000 ], channels=\(int\)[ 1, 2 ]\; audio/x-raw-float, width=\(int\)[ 8, 24 ], depth=\(int\)[ 8, 24 ], rate=\(int\)[ 8000, 96000 ], channels=\(int\)[ 1, 2 ] ! faac bitrate=128000 profile=LC ! mux.audio_%d The actual encoder element is irrelevant in this case, as the same thing happens when using e.g. vorbisenc instead of faac. Same with the muxer, as webmmux, qtmux, mp4mux, etc all display the same issue. Any potential workarounds as well as an upstream fix would be greatly appreciated. Thanks!
Here is another file the exhibits the same exact issue: http://www.dwad.net/episodes/178%20Might%20of%20the%20Starry%20Sea%2005.wmv This file was reported to Arista here: https://github.com/danielgtaylor/arista/issues/12 Both are confirmed in the latest Ubuntu 11.04, haven't tested anywhere else or with GStreamer Dev PPA.
WMV/WMA files are known to often have a lot of jitter. Have you tried setting the "tolerance" property on the audiorate element to a non-0 value? (e.g. to 100000000 or so)
Setting audiorate tolerance=100000000 does fix the WMV. Is this value safe to always set for all conversions or would it ever cause negative effects for other files? Setting the tolerance for the FLV above does not fix the issue. The audioconvert element seems to be adding distortion there, not audiorate.
For the WMV jitter issue see bug #549940 and bug #640859. If you do the following, do you still have distortions when playing back the created file (test.wav)? $ gst-launch-0.10 uridecodebin uri="file:///home/dan/Videos/p.flv" name=dmux ! queue ! audioconvert ! audioresample ! wavenc ! filesink location=test.wav
danielgtaylor, can you please provide requested information as per comment#4 ?
The command in comment#4 does not produce audio glitches. This does: $ gst-launch-0.10 uridecodebin uri="file:///home/dan/Videos/p.flv" name=dmux ! queue ! audioconvert ! audiorate ! audioresample ! wavenc ! filesink location=test.wav
This is still an issue with gstreamer-0.10.36. Several graphical audio converters that are based on gstreamer, such as gnac oder soundconverter, produce a file with crackling audio regardless of the target format or compression. Comment #4 produces no crackling, adding the 'audiorate' option to the gst-launch command does however.
Yes, you need to use audiorate tolerance=XYZ