Closed
Bug 1130611
Opened 10 years ago
Closed 10 years ago
gstreamer audio decoders produce AudioBuffer longer than original file
Categories
(Core :: Web Audio, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: aykevanlaethem, Unassigned)
Details
Attachments
(1 file)
7.94 KB,
audio/mp4
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 Iceweasel/37.0a2
Build ID: 20150201004024
Steps to reproduce:
1. Load the page http://jsfiddle.net/nqg226wf/ (a test page I put together).
2. Select the audio file attached to this bug report.
The .m4a file was converted from a .wav file using neroAacEnc.
The .wav file was created using Audacity (Generate > Tone with default settings apart from the length which is 44101 samples).
Actual results:
The shown audio file has 46080 audio samples.
An MP3 of the same original WAV file encoded using LAME produces an AudioBuffer with 47232 samples.
Expected results:
It should have a length of 44101 audio samples.
As all other codecs work correctly (apart from the Opus codec - bug #1129355) I suspect the problem lies somewhere in gstreamer.
I have not tested Windows or OS X.
Reporter | ||
Comment 1•10 years ago
|
||
Forgot to mention: I tested this on Iceweasel from Debian (the aurora version of Debian testing, which is 37.0a2). This build uses gstreamer 1.0.
Reporter | ||
Comment 2•10 years ago
|
||
See http://mozilla.debian.net/.
I used that build as I couldn't manage to build Firefox with gstreamer support (I added the build flag and it failed to build until I installed the required -dev packages, but still the build didn't decode MP3 or AAC).
Comment 3•10 years ago
|
||
Can you test to decode your file using gstreamer directly, and check the number of frames? It might just be gstreamer acting up, in which case we can't do much.
Flags: needinfo?(aykevanlaethem)
Reporter | ||
Comment 4•10 years ago
|
||
With a command like:
$ gst-launch-1.0 filesrc location=sounds/test/sine.m4a ! decodebin ! audioconvert ! 'audio/x-raw,format=S16LE' ! wavenc ! filesink location=extracted.wav
I get the same number of frames as Firefox reports, so it's a GStreamer issue, but...
http://sourceforge.net/p/gstreamer/mailman/message/26763211/
It appears like it may be possible to implement it, but googling around a bit it looks like GStreamer (still?) has many bugs in it's gapless playback implementation.
Flags: needinfo?(aykevanlaethem)
Comment 5•10 years ago
|
||
I'll close as invalid, then, thanks for putting the extra work and verify it's not Firefox's fault, much appreciated !
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•