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 506557 - Convertion from wma to ogg introduce hatches in the sound
Convertion from wma to ogg introduce hatches in the sound
Status: RESOLVED DUPLICATE of bug 549940
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.15
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-31 10:59 UTC by Id2ndR
Modified: 2011-05-19 06:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Description Id2ndR 2007-12-31 10:59:15 UTC 
Please describe the problem:
Direct convertion from wma to ogg introduce hatches in the sound. Pipelines used are bellow.

Steps to reproduce:
1. Chose a wma file
2. $ gst-launch-0.10 filesrc location=<file.wma> ! decodebin ! audioconvert ! vorbisenc ! oggmux ! decodebin ! audioconvert ! alsasink

Actual results:
Sound is hatch

Expected results:
Sound should not be hatch

Does this happen every time?
yes

Other information:
$ gst-launch-0.10 filesrc location=<file.wma> ! decodebin ! audioconvert ! wavenc ! decodebin ! audioconvert ! vorbisenc ! oggmux ! decodebin ! audioconvert ! alsasink
=> With one stage of decoding/encoding (in wav), there is not trouble.
Comment 1 Tim-Philipp Müller 2007-12-31 18:56:26 UTC 
 - does it work fine if you use  alsasink device=front   instead?

 - does it work fine if you use  audioconvert ! audiorate ! vorbisenc ?
Comment 2 Id2ndR 2008-01-01 14:06:21 UTC 
alsasink device=front
=> No, it doesn't work. Error is :
gstalsasink.c(622): gst_alsasink_open (): /pipeline0/alsasink0:
Device 'front' is busy

audioconvert ! audiorate ! vorbisenc
=> The sound is largely better with audiorate, but it still contain hatch which aren't present using wavenc
Comment 3 René Stadler 2008-01-17 13:36:54 UTC 
I can reproduce this (with pitfdll being the decoder).  The timestamps are messed up, vorbisenc reacts by dropping buffers.
Comment 4 Sebastian Dröge (slomo) 2011-05-19 06:14:51 UTC 
That would be either a corrupted file then or bug #549940. I'll close this as a duplicate of bug #549940.

*** This bug has been marked as a duplicate of bug 549940 ***