GNOME Bugzilla – Bug 731169
wavparse: Puts codec_data on raw audio caps
Last modified: 2014-06-05 09:42:58 UTC
Created attachment 277818 [details] [review] adder: do not reject caps which differ only by codec_data This lets a pipeline such as [1] work. gst-launch-1.0 filesrc location=/home/v/Samples/8.wav ! wavparse ! audioconvert ! audioresample ! 'audio/x-raw,format=S32LE,rate=48000,channels=2' ! queue name=q48 ! adder name=mix ! queue ! audioconvert ! alsasink filesrc location=/home/v/Samples/6.wav ! wavparse ! audioconvert ! audioresample ! 'audio/x-raw,format=S32LE,rate=48000,channels=2' ! queue name=q44 ! mix.
Comment on attachment 277818 [details] [review] adder: do not reject caps which differ only by codec_data I don't think this makes sense. There should be no codec_data field on raw audio caps.
Aaah, I was surprised to see those here. If it really is unexpected, I'll go look at what is setting them.
This is the contents of the "strf" chunk in a wav file. This is from the riff code in -base/gst-libs and seems quite deliberate. wavparse calls this via gst_riff_parse_strf_auds.
It shouldn't really do that :)
It's been there since 2007 at least though. Removing it might break something that expects it...
Created attachment 277863 [details] [review] do not include codec data on raw audio caps Reading the riff lib code, we want to keep this field sometimes as we can get non-raw data. So the best seems to be to remove the field after parsing if we get raw data.
Comment on attachment 277863 [details] [review] do not include codec data on raw audio caps Looks fine, minor nit: >+ /* If we got raw audio from upstream, we remove the codec_data field, >+ which may have been added if the wav header included an extended >+ chunk. We want to keep it for non raw audio. */ Note how our code usually uses a '*' at the beginning of each comment line for multi-line comments: > /* do more sanity checks of header fields > * (these can be sanitized by gst_riff_create_audio_caps() > */
Created attachment 277939 [details] [review] do not include codec data on raw etc type type type again Done. I put the */ on a new line, I see both this and end of lines styles, but the closest multiline comment is new line, so it won.
commit 40ae581ef297839f38dd747444d5e6aa31dea29e Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed Jun 4 11:34:27 2014 +0100 wavparse: do not include codec_data on raw audio caps If the wav header contains an extended chunk, we want to keep the codec_data field, but not for raw audio. This fixes some elements (such as adder) from failing to intersect raw audio caps which would otherwise be intersectable.