After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773861 - wavparse: element error is posted at EOS even though WAV file is OK
wavparse: element error is posted at EOS even though WAV file is OK
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 1.10.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 775025 775382 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-11-02 20:07 UTC by Carlos Rafael Giani
Modified: 2016-11-30 08:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wavparse: Don't set caps to NULL after setting them on the srcpad (944 bytes, patch)
2016-11-03 10:35 UTC, Sebastian Dröge (slomo)
committed Details | Review
test case for wavparse (9.09 KB, patch)
2016-11-03 13:35 UTC, Tim-Philipp Müller
committed Details | Review

Description Carlos Rafael Giani 2016-11-02 20:07:48 UTC
In 0.10.0, once a WAV file reaches EOS, this error is posted:

    /GstPipeline:pipeline0/GstWavParse:wavparse0: The stream is of a different type than handled by this element.

this has been happening to me with every WAV file I tried. A test WAV file that reproduces the problem can in fact be generated with gst-launch:

    gst-launch-1.0 audiotestsrc num-buffers=10 ! "audio/x-raw, rate=44100, format=S16LE, channels=2" ! wavenc ! filesink location=test.wav

when I then play it like this, the error is posted:

    gst-launch-1.0 filesrc location=test.wav ! wavparse ! fakesink

It also happens if I use the latest git master.
Comment 1 Carlos Rafael Giani 2016-11-02 20:08:12 UTC
Err, typo - I meant 1.10.0, not 0.10.0 :)
Comment 2 Carlos Rafael Giani 2016-11-02 20:17:04 UTC
It seems that the fix from https://bugzilla.gnome.org/show_bug.cgi?id=773643 causes this problem, since the error message comes from gstwavparse.c line 2220.
Comment 3 Sebastian Dröge (slomo) 2016-11-02 21:48:18 UTC
The problem is that on EOS we check for no caps and do an error then... but when settings caps we replace them with NULL again. So it will always cause an error it seems. How could we have missed that?
Comment 4 Sebastian Dröge (slomo) 2016-11-03 10:35:39 UTC
Created attachment 339015 [details] [review]
wavparse: Don't set caps to NULL after setting them on the srcpad

We would like to check later on EOS if we found a known stream type or
not, to possibly post an error message.
Comment 5 Tim-Philipp Müller 2016-11-03 13:35:17 UTC
Created attachment 339024 [details] [review]
test case for wavparse
Comment 6 Sebastian Dröge (slomo) 2016-11-03 13:43:06 UTC
commit 752dd15c54238c389f676105867ff7815d623ced
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Thu Nov 3 13:27:51 2016 +0000

    tests: wavparse: add test for processing an actual .wav file
    
    https://bugzilla.gnome.org/show_bug.cgi?id=773861

commit aecc31ab7b4e5a7f5d0b8889c6815644c6b5598a
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Thu Nov 3 12:34:51 2016 +0200

    wavparse: Don't set caps to NULL after setting them on the srcpad
    
    We would like to check later on EOS if we found a known stream type or
    not, to possibly post an error message.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=773861
Comment 7 Sebastian Dröge (slomo) 2016-11-24 16:14:40 UTC
*** Bug 775025 has been marked as a duplicate of this bug. ***
Comment 8 Sebastian Dröge (slomo) 2016-11-30 08:52:38 UTC
*** Bug 775382 has been marked as a duplicate of this bug. ***