Thu 23 Oct 2008 11:48:00 AM UTC, comment #16:
Another option I just thought of: instead of using Gstreamer for audio resampling, we can use Util::convert_raw_data, if neither speexresample nor ffaudioresample are available. I suspect that code would be faster, although it admits it is "crude", so I don't expect very good quality.
|
Fri 10 Oct 2008 01:07:21 PM UTC, comment #15:
Another option here is to run missing-plugins for {speex,ffaudio}resample. But some distributions don't ship either, so we need the ability to give the user a "stop nagging me" option, or otherwise Gnash will (indirectly) pop up the codec dialogue which doesn't have a package for the requested plugin.
That said, this is fixed insofar as it can be fixed for the release.
|
Tue 07 Oct 2008 06:35:12 AM UTC, comment #14:
the libai-layer2-20-sound.swf is also much much better here.
|
Mon 06 Oct 2008 07:00:30 PM UTC, comment #13:
I've tested on this laptop (Mandriva 2008). It's much better than it was, but still has small gaps. It must be using the speex decoder, and hopefully ffmpegaudioresample is still quicker.
Perhaps a configure warning would be useful for gstreamer-ffmpeg, because audioresampler's speed is really not funny.
I see swfdec does the same, so there are no wizard answers from that direction either...
|
Mon 06 Oct 2008 05:58:39 PM UTC, comment #12:
The issue is not actually decoding; it's resampling. It's very slow (as you've seen). I've committed a partial fix which will try to use ffaudioresample, or speexresample, if either are available. If they're not an error message is printed.
I'm not sure if there's a better way to handle this situation.
|
Mon 06 Oct 2008 07:38:48 AM UTC, comment #11:
The same pseudo-hang happens with this:
libai-layer2-20-sound.swf
md5: c0f53d2a7412573c79f648ae00e4bf21
attached in a message on gnash-dev by Richard Tseng
on Sat, 3 May 2008 19:48:33
I took times. It takes 2 seconds with ffmpeg and 60 with gst,
the latter using 100% CPU during those 60 seconds. Tested by opening the right-click menu and massaging items...
I reported this in bug #23203, but seems more topic here
so I'll close the other.
|
Mon 06 Oct 2008 06:47:18 AM UTC, comment #10:
Yes, you're right, after about 3 minutes(!) it carries on. I guess it's the same for the other (weebls-stuff) SWF, only it has much more audio to decode and takes correspondingly longer.
|
Sun 05 Oct 2008 10:21:51 PM UTC, comment #9:
Nevermind that request. I managed to reproduce the stacktrace coming from sdl_audio_callback. Can you confirm that if you leave the "deadlocked" window playing four-second-fury sitting for a while (~30 seconds in my case), playback continues as normal?
It looks like gstreamer is simply taking a very long time to decode ~1MB of audio.
|
Sun 05 Oct 2008 09:55:51 PM UTC, comment #8:
Can you provide some backtraces from all threads when the deadlock has happened?
I've been playing with four-second-fury, and in some runs I see a ~30 second freeze from MediaParser::clearBuffers() / ADPCMDecoder::adpcm_expand(), actually pointing to a data race involving print output... But the stacktrace does not look very clean.
|
Sun 05 Oct 2008 09:00:48 PM UTC, comment #7:
I can reproduce this on a machine running Mandriva 2008.1 and one running 2009.0 rc2.
Having spent the evening watching locks in gdb, I can confirm that that the thread is locked in
SDL_sound_handler::sdl_audio_callback (void udata, Uint8 stream, int buffer_length_in)
and is still locked when play_sound() is called.
For confirmation, commenting out the lock in sdl_audio_callback prevents the hang (but obviously makes a mess of the sound...)
Ffmpeg has no problems with this, so I think it is a gst bug.
|
Sun 05 Oct 2008 12:37:50 PM UTC, comment #6:
Hang is still there on the weebls-stuff movie.
Four-second-fury seems to stutter less to begin with, but also hangs in sound_handler_sdl::load_sound() once you start playing. There are also occasional gaps in the audio with high CPU load (more locking probelms?). It's not a slow system.
|
Sun 05 Oct 2008 11:54:40 AM UTC, comment #5:
The stuttering issue should now be fixed in trunk. Could you try to see if the hang still occurs?
A weakness inherent to the current sound handler design is that decoding will happen on-the-fly, which is likely to cause small delays unless you have a fast system. That said, they should not be "show stoppers".
|
Wed 01 Oct 2008 07:43:01 AM UTC, comment #4:
The hang is waiting for the lock in sdl_sound_handler::play_sound()
|
Tue 30 Sep 2008 07:04:20 PM UTC, comment #3:
Ffmpeg works fine for me for both.
|
Tue 30 Sep 2008 06:47:36 PM UTC, comment #2:
Have you tried ffmpeg ? (four-second-fury isn't very clean for me with ffmpeg Lavc0d.51.11.0)
|
Tue 30 Sep 2008 05:57:55 PM UTC, comment #1:
They work with -r1.
|
Tue 30 Sep 2008 05:57:33 PM UTC, original submission:
These are all with embedded sound.
The SWF from bug #16980 stutters a lot and doesn't play properly
(http://www.koreus.com/media/four-second-fury.html)
The SWF http://www.weebls-stuff.com/flash/8594trev3.swf (bug #23916) (and all other weebls-stuff SWFs I've tried) plays no sound and hangs. Gnash won't exit either.
|