GNOME Bugzilla – Bug 313266
[wavparse] will not play DTS stream in malformed WAV
Last modified: 2006-03-23 15:42:26 UTC
Please describe the problem: DTS streams encapsulated within WAV files are not played correctly (or at all). Steps to reproduce: 1. gst-launch-0.8 filesrc location=dts.wav ! dtsdec ! alsasink or 2. gst-launch-0.8 filesrc location=dts.wav ! wavparse ! dtsdec ! alsasink Actual results: 1. RUNNING pipeline ... ERROR: from element /pipeline0/alsasink0: Could not get/set settings from/on resource. ERROR: from element /pipeline0/dtsdec0: Internal GStreamer error: pad problem. File a bug. Additional debug info: gstpad.c(2562): gst_pad_set_explicit_caps: /pipeline0/dtsdec0: failed to negotiate (try_set_caps with "audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)2, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT >" returned REFUSED) Execution ended after 1 iterations (sum 10009000 ns, average 10009000 ns, min 10009000 ns, max 10009000 ns). (no sound output) 2. RUNNING pipeline ... Execution ended after 257 iterations (sum 6176000 ns, average 24031 ns, min 20000 ns, max 633000 ns). (no sound output) Expected results: Does this happen every time? Yes. Other information:
Created attachment 50593 [details] Sample DTS stream This is a sample of a DTS stream that will not play.
I can confirm that this doesn't work with 0.8.10 either. Note that when using decodebin a dtsdec element isn't added.
Updating to 0.9 and depending on Playback TRACKER (#138435).
This file is specified in the WAV header as raw (integer) PCM, not DTS. It'd be possible to sniff the actual PCM and decide that it looks like DTS, but that doesn't seem terribly worthwhile. Does anyone know of ANY software that can play this file?
Yes, mplayer (recent CVS version) plays it fine.
Created attachment 59993 [details] [review] possible fix Patch that delays pad creation until after we've had a chance to sniff the first few bytes of the data to determine whether it's dts-in-wav or not. If it is, patch amends caps to audio/x-dts before adding the pad. We need to delay pad creation for decodebin. Putting this into bugzilla only for now, as there has been disagreement whether we want to do things like this or not. Technically, it's a broken file. If it says it's PCM raw data and then it's not, that's just wrong and shouldn't have created like this in the first place. Unfortunately, there are quite a few files like this in the wild and mplayer, xine, and vlc all play them, only we don't. Me, I think we should strive to play those files, just like we work around broken tags or other things that aren't correct according to spec.
Sigh. Since these files are apparently 'common' (i.e. we've seen multiple reports of this problem), and the workaround seems to be present in a wide variety of existing players, I suppose you should go ahead and commit this. In the interests of actually playing existing files, I'll retract my objections.
Patch needs to be updated for wavparse changes.
Fixed: 2006-03-23 Tim-Philipp Müller <tim at centricular dot net> * gst/wavparse/gstwavparse.c: (gst_wavparse_perform_seek), (gst_wavparse_stream_headers), (gst_wavparse_add_src_pad), (gst_wavparse_stream_data), (gst_wavparse_loop): * gst/wavparse/gstwavparse.h: Delay source pad creation until we have the first chunk of media data, so the we can examine the data and adjust the caps accordingly if required. This makes playback of .wav files with DTS-declared-as-PCM content work (#313266).