GNOME Bugzilla – Bug 481354
[wavparse] does not play 700Hz GSM 6.10 wav file
Last modified: 2008-03-31 16:25:22 UTC
This file, which is described as GSM 6.10 wav format, does not play in GStreamer. http://totem.menneske.dk/batch_totem/OUTPUT/Trunkeret_&_Ikonisk/10~_%a4%20A%20MINOR%20PRISM%20GLOW%20NUMBER%20.wav gst-launch-0.10 -v playbin uri="file:///home/sa/Download/10.wav" Setting pipeline to PAUSED ... /playbin0/decodebin0/typefind.src: caps = audio/x-wav Pipeline is PREROLLING ... ERROR: from element /playbin0/decodebin0/wavparse0: Could not determine type of stream. Additional debug info: gstwavparse.c(1361): gst_wavparse_stream_headers (): /playbin0/decodebin0/wavparse0: No caps found for format 0x0, 0 channels, 0 Hz ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /playbin0/decodebin0/typefind.src: caps = NULL FREEING pipeline ...
This file has a samplerate of 700 and we don't allow rate lower than 1000 currently. I see no reason to set the lowest rate to 1.
Is the sample rate advertised even correct? I mean, it doesn't really sound particularly right in mplayer (or any other player that plays this, if they play it at all). WONTFIX seems ok to me, 700Hz is not really a useful sample rate, is it?
It's fine to have a samplerate that low apparently. I have it modified locally but it needs changing all over the map.
My reasoning is the following: - if there is no technical limit to the samplerate, just use 1 - INF. For GSM this is certainly true. For MP3, this is not true. - if the format has a prefered rate (like 8000 for GSM), put this as a first structure in the caps, in front of the 1 - INF caps. This should make sure that automatic negotiation prefers the 8000Hz when possible.
*** Bug 525321 has been marked as a duplicate of this bug. ***
If 1000-96000 hz samplerate is allowed then currently why does its not considered.
Created attachment 108339 [details] [review] samplerate 1000-96000 support added This patch makes the gsmdec decode the ms-gsm encoded wav files with samplerate from 1000-96000hz.
why lowest 1000? This will still make this bug fail because gsmdec will not accept a rate of 700. In Comment #4 I explained the desired behaviour: The caps should look like this: - fixed caps with 8000 Hz (to state the prefered format) - range 1 - INF (all other samplerates are also possible)
(In reply to comment #8) I didnt intended to fix this bug, but solve another problem of gsmdec . So I opened bug 525321 , but that was duplicated to this one. I used lowest 1000 since wavparse supports 1000-96000 Hz for audio/ms-gsm.
I created a dup of this bug because they both are about the insane ranges in gsmdec/enc. Your patch certainly makes it less insane but still puts quite arbitrary ranges for the supported samplerates (ones that makes this bug still fail). I will apply and improve when I have some time.
* gst-libs/gst/riff/riff-media.c: (gst_riff_create_audio_caps): ms-gsm can have arbitrarty sample rates. See #481354.
Patch by: kapil <kapil at fluendo dot com> * ext/gsm/gstgsmdec.c: (gst_gsmdec_sink_setcaps), (gst_gsmdec_chain): * ext/gsm/gstgsmdec.h: Increase the allowed samplerates for the ms-gsm format. Fixes #481354.