Fri 01 Nov 2013 09:34:35 AM UTC, comment #10:
No, this doesn’t seem to be a duplicate of #25456, which still needs to be fixed.
Pablo
|
Wed 30 Oct 2013 06:09:39 PM UTC, comment #9:
Sorry, but is bug 25456 a duplicate of this bug?
If it is, bug 25456 could be closed.
Many thanks for your help.
|
Tue 09 Jul 2013 09:22:07 PM UTC, comment #8:
Should be fixed with 9c9fde8.
|
Tue 09 Jul 2013 04:41:01 PM UTC, comment #7:
I committed an attempted fix in 953e044, and although it solves the problem of this bug, it does not quite do the right thing. Some testing with the pp shows that:
- onLoad should not be called until the whole sound is loaded (parsed).
- if the sound is a streaming sound it should start playing immediately (and consequently onLoad will be called some time after playback starts).
|
Sun 07 Jul 2013 01:16:32 PM UTC, comment #6:
I've added a test for this issue in 941633fd.
|
Sun 07 Jul 2013 10:01:20 AM UTC, comment #5:
I converted my testing mp3 back and forth to WAVE, removing any tags, and now the movie is just as silent with ffmpeg as it is with Gstreamer.
Thinking a little bit about the fix: if it is desirable that the whole sound is parsed, then of course the buffer length should be made infinite. Otherwise, we could use MediaParser::bufferFull() to tell us whether there is enough data to start playing, although that is an internal API at the moment.
|
Sun 07 Jul 2013 01:32:43 AM UTC, comment #4:
> Well, there is a bug in the ffmpeg MediaParser, that somehow detects a single video frame in the mp3
This might not be a bug exactly, because the mp3 with which I am testing happens to have a little JPEG data embedded, presumably in an ID3 tag, which ffmpeg is treating as video.
|
Sat 06 Jul 2013 11:20:25 PM UTC, comment #3:
MediaParser base class is in charge of obtaining new buffers from the derived Media Parser class, which I will call "DMP". MediaParser asks DMP to parse frames until a buffer (set to 1 minute) is full. Then it waits for Sound_as to consume the buffers and parsing continues. The trouble is that there is a chicken-and-egg situation between MediaParser and Sound_as:
Sound_as waits for parsing to be completed before it consumes audio and MediaParser is waiting for Sound_as to consume some data before it parses the rest of the file.
So, you ask, why does it work with Ffmpeg at all? Well, there is a bug in the ffmpeg MediaParser, that somehow detects a single video frame in the mp3, and the buffer length is calculated to be the minimum of either the audio or video time, and since the minimum video time will never reach the one minute barrier, Ffmpeg is permitted to parse the whole file; and then Sound_as can begin consuming.
|
Fri 15 Jul 2011 09:19:35 AM UTC, comment #2:
It was 6b478714a7264187cce8bd6d24c458ed94441843, the implementation of the onLoad callback. The problem isn't really the code that was added, but rather the fact that the gst decoder doesn't behave as expected.
It never sets decodingCompleted() to true, even though at some point it stops decoding and just sits there uselessly waiting for something to happen.
|
Wed 13 Jul 2011 04:07:56 PM UTC, comment #1:
0.8.9 appears to work, so this is a recent regression.
|
Wed 13 Jul 2011 07:39:55 AM UTC, original submission:
The following code should load and play some.mp3. It works as expected with ffmpeg, not with gstreamer.
s = new Sound();
s.loadSound("some.mp3", true);
It has been a bug for a while.
|