GNOME Bugzilla – Bug 737735
wavenc writes broken file if caps are set
Last modified: 2014-10-14 07:44:19 UTC
Created attachment 287527 [details] Resulting output file gst-launch-1.0 --gst-debug-level=5 --gst-debug-no-color filesrc location=stereo.wav ! wavparse ! wavenc ! audio/x-wav ! filesink location=q.wav with an input file with 4370 Samples results in a file where soxi says that it has 536854528 samples, but in reality it is only a few bytes longer than the input file. The problem is reproducible with GStreamer Core Library version 1.2.4 and the lates git version. It works with 0.10.36.
Created attachment 287528 [details] The input file (generated by Audacity)
Created attachment 287529 [details] The log file
Each of these fixes it individually, but they're actually two separate bugs. commit 798cafa7fc2716478d4e3bbcdfd2c89340c7ecc5 Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Oct 2 10:13:28 2014 +0300 capsfilter: Push pending events before a buffer also if upstream never configured caps but we have srcpad caps already Otherwise we never send pending events downstream that arrive after we configured caps on the srcpad. https://bugzilla.gnome.org/show_bug.cgi?id=737735 commit 7729f4ce81580df72e03e509966651eebb092d81 Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Oct 2 10:10:11 2014 +0300 wavenc: Send CAPS event after the pad was activated Otherwise the CAPS event will be dropped and we never configure any caps at all, leading to weird behaviour in many situations. Especially header rewriting is not going to work if a capsfilter is after wavenc. https://bugzilla.gnome.org/show_bug.cgi?id=737735