bugGnash - The GNU Flash player - Bugs: bug #45722, Gnash emitted loud screech after...

 
 

bug #45722: Gnash emitted loud screech after playing PCM audio object

Submitter:  Nutchanon Wetchasit <nachanon>
Submitted:  Sat 08 Aug 2015 04:10:32 PM UTC
   
 
Category:  sound Severity:  3 - Normal
Release:  master Status:  Ready For Test
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 26 Sep 2015 08:30:18 AM UTC, comment #34: 

I get now that what exactly the "_real fun_" means when Gnash's `./configure`
script tried to convince me to install Csound.

        WARNING: You need to have csound installed
                 to have real fun.
                 Install it from http://www.csounds.com/
                 or .deb users: apt-get install csound
                 or .rpm users: yum install csound


But, seriously, the configure script should be more clear on what Csound have
to do with Gnash's build, e.g. for generating sound-related test cases.
(Patch included; see patch #8753)

Nutchanon Wetchasit <nachanon>
Wed 23 Sep 2015 01:56:09 PM UTC, comment #33: 

If you look under testsuite/sound there's a "brokenchord.wav" file which although distributed can be generated by having "csound" installed (see Makefile for the rule).

It'd be interesting to see if we can get csound to output all the type of sounds we need for testing.

Sandro Santilli <strk>
Group Member
Wed 23 Sep 2015 01:49:42 PM UTC, comment #32: 

All pending patches have been pushed, back to automated testing.

Sandro Santilli <strk>
Group Member
Sun 20 Sep 2015 07:12:18 AM UTC, comment #31: 

Patches included for FFmpeg 8-bit PCM wailing and and crashing case:
see patch #8747.

After applied patch 1-5, all test files provided so far in this bug entry
seems to play properly with `gnash --media=ffmpeg`. They were tested
with `gnash --media=gst` too; no problem found.

I also done few tests for side effect of the fix on other codecs,
and found none so far. (But the test is performed on only one version of libAV,
and covered only few variety of codec parameters)

Gnash: 0.8.11dev (patched against git 516a6ca 15-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Sat 19 Sep 2015 03:58:48 PM UTC, comment #30: 

The attached `pcmplay-11k.zip` contains more resampler test files, including
sounds and build scripts, using 11025 Hz sample rate, in all combination
of `UNCOMPRESSED`/`RAW` (little-endian) format, 16-bit/8-bit depth,
mono and stereo.


(file #34927)

Nutchanon Wetchasit <nachanon>
Sat 19 Sep 2015 03:55:29 PM UTC, comment #29: 

The attached `pcmplay-22k.zip` contains additional resampler test files,
sounds, and build scripts, using 22050 Hz sample rate, in all combination
of `UNCOMPRESSED`/`RAW` (little-endian) format, 16-bit/8-bit depth,
mono and stereo.

(file #34926)

Nutchanon Wetchasit <nachanon>
Fri 18 Sep 2015 05:50:27 AM UTC, comment #28: 

We're counting on you to provide a patch.
You did a wonderful work so far, and there seem to be a lot more to do. It would be a pity for all this work to be ruined in the future so I'd stress out again that sound decoding currently has zero automated tests. If you can provide that it will be extremely rewarding in the long run.

Sandro Santilli <strk>
Group Member
Fri 18 Sep 2015 05:19:29 AM UTC, comment #27: 

I've tested around Gnash's FFmpeg/libAV-based codec backend, and found problem on many levels:


These problems seems to be very closely related that all of them would have
to be fixed at the same instant to get the correct behavior.

Gnash: 0.8.11dev (git 516a6ca 15-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Thu 17 Sep 2015 02:26:20 PM UTC, comment #26: 

Note (for the record): embeded 8-bit PCM `UNCOMPRESSED` and `RAW` event sound
is encoded in an unsigned 8-bit PCM format.

If you run following commands with `pcmplay-8bit.swf` and `rawpcmplay-8bit.swf`
you will hear the correct siren sound:

swfmill swf2xml pcmplay-8bit.swf | sed -n 's/.*<data>\([^<]*\)<\/data>/\1/p' | base64 -d | aplay -t raw -f U8 -r 44100
swfmill swf2xml rawpcmplay-8bit.swf | sed -n 's/.*<data>\([^<]*\)<\/data>/\1/p' | base64 -d | aplay -t raw -f U8 -r 44100


But if you changed the `-f U8` part to `-f S8` (signed PCM), you'd hear a hoarse wailing instead.

Nutchanon Wetchasit <nachanon>
Mon 14 Sep 2015 11:35:51 AM UTC, comment #25: 

Please note that Gnash with FFmpeg/libAV backend is still not playing 8-bit PCM (and 8-bit raw PCM) properly.
(Submitted patches fixes only GStreamer backend)

These are summary of result on current Gnash playing test files:

  • FFmpeg/libAV backend:
    • `pcmplay.swf`: played OK
    • `pcmplay-stereo.swf`: played OK
    • `pcmplay-8bit.swf: played with weird wail followed
    • `pcmplay-stereo-8bit.swf`: aborted, or crashed
    • `rawpcmplayle.swf`: played OK
    • `rawpcmplayle-stereo.swf`: played OK
    • `rawpcmplay-8bit.swf`: played with weird wail followed
    • `rawpcmplay-stereo-8bit.swf`: aborted, or crashed
  • GStreamer backend:
    • `pcmplay.swf`: played OK
    • `pcmplay-stereo.swf`: played OK
    • `pcmplay-8bit.swf: played OK
    • `pcmplay-stereo-8bit.swf`: played OK
    • `rawpcmplayle.swf`: played OK
    • `rawpcmplayle-stereo.swf`: played OK
    • `rawpcmplay-8bit.swf`: played OK
    • `rawpcmplay-stereo-8bit.swf`: played OK


For GDB backtraces on FFmpeg 8-bit stereo (uncompressed PCM) case, see the
previously attached `pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`.

I think that crashes/aborts on uncompressed 8-bit stereo sound and
raw 8-bit stereo sound are the same, as they were handled by the same decoder (AV_CODEC_ID_PCM_S8).

For the FFmpeg wailing (8-bit mono, both uncompressed and raw), I'm not sure of the cause.
(The audio dump from uncompressed PCM case is in `pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`)

Gnash: 0.8.11dev (git e4c2ac8 14-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Mon 14 Sep 2015 08:44:22 AM UTC, comment #24: 

Patches pushed as commits 76b8fa551a4c4849c72318e6fb7bcafb070485db and c16e78cd22f2fb2c656c378399aba0d3956e5254

Any idea on how decoding sound could be automatically tested ?

Sandro Santilli <strk>
Group Member
Mon 14 Sep 2015 07:52:36 AM UTC, comment #23: 

Patch included for raw 8-bit stereo GStreamer case: patch #8738 comment 2.

After applied patch 1-2 from patch #8738, Gnash (using `--media=gst`) seems
to play both `pcmplay-stereo-8bit.swf` and `rawpcmplay-stereo-8bit.swf` properly.

FFmpeg/libAV cases on 8-bit uncompressed PCM and raw PCM (both mono wailing
and stereo crashing), are remaining to be fixed.

Gnash: 0.8.11dev (patched against git f5016cc 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Mon 14 Sep 2015 07:37:10 AM UTC, comment #22: 

The attached file (`rawpcmplay.zip`) contain test SWF files for raw PCM
event sound in combination of both bit depth 16-bit (little endian) and 8-bit,
both 1 and 2 channels, together with source sound, code, and build scripts.

Testing current Gnash git using `rawpcmplay-8bit.swf` and `rawpcmplay-stereo-8bit.swf`
on both media handler backend yields result similar to `pcmplay-8bit.swf` and `pcmplay-stereo-8bit.swf`:

  • FFmpeg/libAV backend:
    • `rawpcmplay-8bit.swf`: played with weird wail followed
    • `rawpcmplay-stereo-8bit.swf`: aborted, or crashed
  • GStreamer backend:
    • `rawpcmplay-8bit.swf: played OK
    • `rawpcmplay-stereo-8bit.swf`: played with gibberish followed, or crashed


On the other hand, raw little-endian 16-bit PCM (both mono and stereo)
seems to play properly on both FFmpeg and Gstreamer media handler.

Gnash: 0.8.11dev (git f5016cc 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34872)

Nutchanon Wetchasit <nachanon>
Sun 13 Sep 2015 01:48:30 PM UTC, comment #21: 

Patch included for 8-bit stereo GStreamer case: see patch #8738.

After applied this patch, Gnash (using `--media=gst`) played
`pcmplay-stereo-8bit.swf` properly.

FFmpeg/libAV cases (both 8-bit mono wailing and 8-bit stereo crashing),
and 8-bit `RAW` PCM codec are remaining to be investigated.

Gnash: 0.8.11dev (patched against git f5016cc 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Sun 13 Sep 2015 01:45:23 PM UTC, comment #20: 

The "`libmedia/AudioDecoderSimple.cpp` line 393" phrase in previous post
was misquoted, sorry. The correct line number should be 404:
http://git.savannah.gnu.org/cgit/gnash.git/tree/libmedia/AudioDecoderSimple.cpp?id=f5016cc9399c9ffd3c5d32c67bb28fac285559c6#n404

Mistake aside, the issue (and fix) might similarly apply to 8-bit `RAW` codec too.
But I will try to create test files for confirming it first.

Nutchanon Wetchasit <nachanon>
Sun 13 Sep 2015 01:17:45 PM UTC, comment #19: 

I have observed around `AudioDecoderSimple` for bits relating to GStreamer
`pcmplay-stereo-8bit.swf` case, which have normal sound at first, then
followed by either gibberish or crash. Excerpt from diagnostic output:

DEBUG: AudioDecoderSimple: initialized flash codec 3 (Uncompressed)
DEBUG:   decoding 65536 bytes (offset 0, remaining 88200, total 88200)
DEBUG:   decoded to 262144 bytes, used 65536 bytes from source
DEBUG:   decoding 22664 bytes (offset 65536, remaining 22664, total 88200)
DEBUG:   decoded to 90656 bytes, used 22664 bytes from source


An anomaly could be seen in the first "decoded..." line: diagnostic code
reported that 65536 bytes audio get expanded to 262144 bytes, which was
four times of original.

In this case, 2 byte/frame simply got converted to 4 byte/frame should expand
only for two times, not four times.

This could be traced to `libmedia/AudioDecoderSimple.cpp` line 393
The code errneously set output size to four times of input size if the sound
is stereo, even when itself is responsible only for 8-bit to 16-bit conversion,
which always multiplies two. (Note: stereo expansion, when applicable,
is done in later stage and will re-adjust the buffer size again automatically)

When this happens, after outputting the normal sound, SDL output stage tries
to read beyond the audio buffer (due to erroneous buffer size),
leading to gibberish output (or crash).

Gnash: 0.8.11dev (git f5016cc 9-Sep-2015 with `show-sound-decoding-diagnostic.patch`)
SDL: libsdl1.2debian 1.2.15-5 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Sat 12 Sep 2015 05:12:20 PM UTC, comment #18: 

These are summary of result on current Gnash playing test files:

  • FFmpeg/libAV backend:
    • `pcmplay.swf`: played OK
    • `pcmplay-stereo.swf`: played OK
    • `pcmplay-8bit.swf: played with weird wail followed
    • `pcmplay-stereo-8bit.swf`: aborted, or crashed
  • GStreamer backend:
    • `pcmplay.swf`: played OK
    • `pcmplay-stereo.swf`: played OK
    • `pcmplay-8bit.swf: played OK
    • `pcmplay-stereo-8bit.swf`: played with gibberish followed, or crashed


For audio dumps from 8-bit PCM tests (including log message, and GDB backtrace
when Gnash aborted or crashed), see the previously attached `pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`.

Gnash: 0.8.11dev (git 775c5fe 9-Sep-2015 with `show-sound-decoding-diagnostic.patch`)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Thu 10 Sep 2015 03:45:40 AM UTC, comment #17: 

There is an interesting problem on Gnash's 8-bit PCM support.
See the attached `pcmplay-8bit.zip` for test files (mono and stereo).

Note: This issue predates the introduction of workaround patch (b7dbb23).
From my tests and observation, the patch didn't change Gnash's behavior
on these 8-bit PCM cases in significant way.

After applied the diagnostic patch (`show-sound-decoding-diagnostic.patch`),
I have tested current Gnash with both FFmpeg and GStreamer backend on both
`pcmplay-8bit.swf` and `pcmplay-stereo-8bit.swf`. Result logs
(verbosity 2 + action error log), audio dumps, and GDB backtraces
(when applicable) from each cases are attached as
`pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`.

Note #1: in `pcmplay-stereo-8bit.swf` case, backtrace and audio dumps are
captured multiple times per media handler. These documents each different style
that Gnash crashed or abort()'d on playing the test file.

Note #2: audio dump from testing `pcmplay-stereo-8bit.swf` on Gnash with
GStreamer backend is fixed using AVconv.

Gnash: 0.8.11dev (patched against git 775c5fe 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34845)

Nutchanon Wetchasit <nachanon>
Wed 09 Sep 2015 02:55:50 PM UTC, comment #16: 

workaround patch committed. It also made sense to size the chunk as documented by the comment above (2^16) rather than one byte less...

Sandro Santilli <strk>
Group Member
Wed 09 Sep 2015 01:51:53 PM UTC, comment #15: 

Workaround included: patch #8736

This patch (hack) does not address the issue itself, but rather
works around it by always requesting the decoder to read in block size
that is a multiple of PCM frame size (both mono and stereo).

Which this patch, Gnash (both FFmpeg and GStreamer backend) seems to play
both `pcmplay.swf` and `pcmplay-stereo.swf` properly.

Underlying issue of frame boundary rounding (or why the decoder didn't
keep the remainder bytes for the next decoding round) should be fixed
in the each respective backend (both GStreamer and FFmpeg).

This patch should not affect other codec if their decoder do not have
framing problem similar to ones described in comment 12.


Gnash: 0.8.11dev (patched against git c969f9d 8-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Wed 09 Sep 2015 09:25:24 AM UTC, comment #14: 

Regarding "PCM decoder" mentioned in comment 12:


Gnash: 0.8.11dev (git ba8ab1d 07-Sep-2015)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Tue 08 Sep 2015 10:47:51 AM UTC, comment #13: 

Is the PCM decoder a Gnash class or is it internal to gst/ffmpeg ?

Sandro Santilli <strk>
Group Member
Tue 08 Sep 2015 10:38:24 AM UTC, comment #12: 

From result in previous posts, it seems that both Gnash's media codec
handler backend (FFmpeg and GStreamer-based) have a problem on incremental
decoding of uncompressed PCM audio. The issue is caused by either:

  • PCM decoder does not consume source data in a block size that is rounded to frame boundary. Or...
  • PCM decoder does not keep the remainder byte(s) for decoding in the next go.

 
This issue surfaced when the decoder is requested to read in a block that is
not a multiple of frame size, resulting in misalignment, thus nasty screech
are being decoded instead of desired sound in the second decoder call
(and so on).

Fixing the second issue (by keeping the remainder bytes in the decoder for use
in the next try) would make the incremental decoding works even when
the requested chunk size is as small as 1 byte.

Nutchanon Wetchasit <nachanon>
Tue 08 Sep 2015 10:07:09 AM UTC, comment #11: 

Note: assertion check mentioned in previous post is located here (original markup was messed up a bit):
http://git.savannah.gnu.org/cgit/gnash.git/tree/libsound/EmbedSoundInst.cpp?id=ba8ab1d9757bef44ab9be979072337a9e0fe463e#n118

Nutchanon Wetchasit <nachanon>
Tue 08 Sep 2015 09:59:00 AM UTC, comment #10: 

For stereo cases (`pcmplay-stereo.swf`):

The problem is similar to normal ones: decoder, both FFmpeg and GStreamer,
seemed to consume 65535 bytes which is not rounded to frame boundary.

Symptiom difference (FFmpeg V.S. GStreamer) is that GStreamer one seems to be
more straightforward; as the audio [fits Gnash's internal sample format],
it was passed verbatim without consideration of frame size,
and tripped assertion error.

Side note: I'm not sure if the assertion check [`assert(!(decodedDataSize%2))`
is correct, since Gnash's internal sample format seems to use 4 bytes/frame
not 2 bytes/frame.


For the double screeching (FFmpeg), I figured it was due to size of the audio,
the misalignment started earlier, and covered the area where original
siren sound changes frequency, thus the screech changed into second pattern.

With second chunk ended before the end of sound, third `.decode()` call
resulted in a second misalignment; making the frame partially aligned again
(sample is aligned but flipped channel), this makes the final bits of
siren sounds apparently normal again.

Playing `pcmplay-lr.swf` (from the attached `pcmplay-lr.zip`) under Gnash
using FFmpeg backend will show the symptom of flipped channel
after the second screech.

(file #34835)

Nutchanon Wetchasit <nachanon>
Tue 08 Sep 2015 09:49:56 AM UTC, comment #9: 

From the attached `pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip`.

This is an exerpt from output on playing `pcmplay.swf` using FFmpeg backend:

DEBUG: AudioDecoderFfmpeg: initialized FFmpeg codec 65536 (pcm_s16le) for flash codec 3 (Uncompressed)
DEBUG:   decoding 65535 bytes (offset 0, remaining 88200, total 88200)
DEBUG:   decoded to 131028 bytes, used 65535 bytes from source
DEBUG:   decoding 22665 bytes (offset 65535, remaining 22665, total 88200)
DEBUG:   decoded to 45328 bytes, used 22665 bytes from source


(The second set of `decoding ... decoded ...` output is emitted the same time
as screech sound)

From `used 65535 bytes from source` part, it shown that the underlying decoder
consumed audio data in a block that's not aligned to frame boundary.
(PCM 16-bit Mono has frame size of 2 bytes) This has potential of messing up
the subsequent read; which is evident as the second `.decode()` call was
occured at the same moment that screech is audible.

This is an exerpt from output on playing `pcmplay.swf` using GStreamer backend:

DEBUG: AudioDecoderSimple: initialized flash codec 3 (Uncompressed)
DEBUG:   decoding 65535 bytes (offset 0, remaining 88200, total 88200)
DEBUG:   decoded to 131068 bytes, used 65535 bytes from source
DEBUG:   decoding 22665 bytes (offset 65535, remaining 22665, total 88200)
DEBUG:   decoded to 45328 bytes, used 22665 bytes from source


(The second set of `decoding ... decoded ...` output is emitted the same time
as screech sound)

Problem is the same as FFmpeg (`used 65535 bytes from source`), only
difference are decoded sizes of data; GStreamer backend seems to be
more accurate on this; there is 65534 bytes worth of complete frames
on first read, which output data is correctly shown as 131068 bytes.

Note (for the record): As far as I know, Gnash's sound decoding process always
convert sample format to PCM 44100 Hz 16-bit stereo (4-byte/frame).

Nutchanon Wetchasit <nachanon>
Mon 07 Sep 2015 07:37:14 PM UTC, comment #8: 

bug #25456 was reported as being a regression, btw

Sandro Santilli <strk>
Group Member
Mon 07 Sep 2015 12:22:32 PM UTC, comment #7: 

I have made a dummy patch for showing some diagnostic information on
`AudioDecoder.decode()`, see the attached `show-sound-decoding-diagnostic.patch`.

After applied the patch, I have tested Gnash with both FFmpeg and GStreamer
backend on both `pcmplay.swf` and `pcmplay-stereo.swf`. Result logs
(verbosity 2 + action error log) and audio dumps (if applicable) from
each cases are attached as `pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip`.

Note: audio dump from `gnash --audio-dump` might not be read properly in
some sound editor/player. This issue was reported separately as bug #45887.

(Audio dumps attached above are already fixed using AVconv,
so they could be opened directly in an editor like Audacity)

Gnash: 0.8.11dev (git dc51f53 28-Aug-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34825)

Nutchanon Wetchasit <nachanon>
Fri 04 Sep 2015 08:24:04 AM UTC, comment #6: 

I've re-tested the regression on a new system where modern FFmpeg/libAV is available.

I think it's important to note that Gnash's FFmpeg and GStreamer backend
are both affected by this issue, and traced back to the same commit.
Though the symptom of pcmplay-stereo case is a bit different between FFmpeg
and GStreamer (double screech V.S. assertion failure).

These are summary of result on Gnash playing two attached test files:

  • Pre-regression commit (77966b2), FFmpeg/libAV backend:
    • pcmplay.swf: played OK
    • pcmplay-stereo.swf: played OK
  • Pre-regression commit (77966b2), GStreamer backend:
    • pcmplay.swf: played OK
    • pcmplay-stereo.swf: played OK
  • Regression commit (7a53cb3), FFmpeg/libAV backend:
    • pcmplay.swf: played with screech
    • pcmplay-stereo.swf: played with double screech
  • Regression commit (7a53cb3), GStreamer backend:
    • pcmplay.swf: played with screech
    • pcmplay-stereo.swf: assertion failed


Screech sounds are apprently the same as ones in each corresponding videos attached earlier
(`pcmplay_gnash0.8.11dev-6b269f9.ogv` for FFmpeg-mono and GStreamer-mono,
`pcmplay-stereo_gnash0.8.11dev-f341372.ffmpeg.ogv` for FFmpeg-stereo)

Assertion failure message in GStreamer-stereo case is still the same as comment 1
(GDB backtrace using f341372 is also available inside the `pcmplay-stereo.zip` attached earlier)

Gnash: 0.8.11dev (git 77966b2), 0.8.11dev (git 7a53cb3)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>
Thu 03 Sep 2015 09:51:40 PM UTC, comment #5: 

It sounds like AudioDecoderGst is not allowed to do incremental decoding ? I've to admit I mostly focused on FFMPEG media handler as GST was left behind. Maybe Bastiaan can shed a light on the matter.

Sandro Santilli <strk>
Group Member
Wed 02 Sep 2015 08:43:53 AM UTC, comment #4: 

I the previous post I said "pcmsound.swf" and "pcmsound-stereo.swf",
I actually meant to say "pcmplay.swf" and "pcmplay-stereo.swf".
They were mistyped, sorry.

Nutchanon Wetchasit <nachanon>
Wed 02 Sep 2015 08:39:50 AM UTC, comment #3: 

Git bisect test (dc51f53 bad, 0.8.10 good) using `pcmsound.swf` and `pcmsound-stereo.swf` revealed that:

7a53cb38d4b3f8a8f6160a40e2912133663c1ab3 is the first bad commit
commit 7a53cb38d4b3f8a8f6160a40e2912133663c1ab3
Author: Sandro Santilli <strk@keybit.net>
Date:   Sun Nov 3 19:49:28 2013 +0100

        Decode embedded sound in chunks of 65535 bytes

        Fixes latency in lessig-freeculture.swf:
        https://savannah.gnu.org/bugs/?25456

        Confirms AudioDecoder is already allowed to do incremental decoding:
        https://savannah.gnu.org/bugs/index.php?24638

:040000 040000 b4f35f74ac4a1974de3dd731ba1dbb3d3a540552 22c9c9db76729b744a13b6ccf85265b226380894 M        libsound


In this commit, using `gnash --media=gst pcmsound.swf` resulted in screech
after siren sound. With `gnash --media=gst pcmsound-stereo.swf`, it ended
with an assertion error just like in comment 1:

92 SECURITY: Checking security of URL 'file:///home/window/Desktop/pcmplay/pcmplay-stereo.swf'
92 SECURITY: Load of file /home/window/Desktop/pcmplay/pcmplay-stereo.swf granted (under local sandbox /home/window/Desktop/pcmplay/)
106 SECURITY: Extensions disabled
108 ACTIONSCRIPT ERROR: reference to non-existent variable 'PCMPlayStereo'
gtk-gnash: EmbedSoundInst.cpp:118: virtual void gnash::sound::EmbedSoundInst::decodeNextBlock(): Assertion `!(decodedDataSize%2)' failed.
Aborted


In a commit before the regression (77966b2), both `pcmsound.swf` and
`pcmsound-stereo.swf` played correctly.

Note: `--media=ffmpeg` was not tested due to version requirement.

SDL: libsdl1.2debian 1.2.14-6.1 (debian)
GStreamer: libgstreamer0.10-0 0.10.30-1 (debian)
CSound: libcsound64-5.2 1:5.12.1~dfsg-5 (debian)
System: Debian GNU/Linux 6.0 Squeeze i386

Nutchanon Wetchasit <nachanon>
Wed 02 Sep 2015 08:36:08 AM UTC, comment #2: 

I tested on an older system and found that Gnash 0.8.10 played both
`pcmplay.swf` and `pcmplay-stereo.swf` smoothly, without any screech.

Gnash: 0.8.10 (source)
SDL: libsdl1.2debian 1.2.14-6.1 (debian)
FFmpeg: libavcodec52 4:0.5.10-1 (debian), libavformat52 4:0.5.10-1 (debian), libavutil49 4:0.5.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.30-1 (debian)
System: Debian GNU/Linux 6.0 Squeeze i386

Nutchanon Wetchasit <nachanon>
Thu 27 Aug 2015 07:59:33 AM UTC, comment #1: 

I have tested more by using the same sound but in stereo instead of mono,
the symptom got interesting.

The attached `pcmplay-stereo_fp11.2.202.491.ogv` is a video result from Adobe Flash:
You'll see that siren sound played and stopped normally.

The attached `pcmplay-stereo_gnash0.8.11dev-f341372.ffmpeg.ogv` is a video
result from Gnash using FFmpeg/libAV media handler:
You'd see that there're now two screech, emitted in the middle
of siren sound instead of at the end.

On the other hand, with Gnash using GStreamer media handler,
Gnash window was shown in a blink before it terminated with an assertion error
(no sound was audible).

3623:1] 354 ACTIONSCRIPT ERROR: reference to non-existent variable 'PCMPlayStereo'
3623:1] 355 DEBUG: Loading native class Sound
3623:1] 355 DEBUG: Sound.start: secOff:0 loops:0
3623:1] 371 DEBUG: AudioDecoderSimple: initialized flash codec 3 (Uncompressed)
gtk-gnash: EmbedSoundInst.cpp:118: virtual void gnash::sound::EmbedSoundInst::decodeNextBlock(): Assertion `!(decodedDataSize%2)' failed.


Full Gnash logs of both case (verbosity=2 + action error log), full GDB
backtrace output of GStreamer case, test source code, sound, and build script
are attached (pcmplay-stereo.zip).

Gnash: 0.8.11dev (git f341372 25-Aug-2015)
Adobe Flash Player: 11.2 r202 (11.2.202.491) standalone
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34753)

Nutchanon Wetchasit <nachanon>
Sat 08 Aug 2015 04:10:32 PM UTC, original submission:  

I have created a simple flash file from SWFMill/MTASC (Flash 8) which have
a single PCM sound in the library, and use `Sound.start()` in ActionScript
to play it.

When running the file on Gnash, its sound seems to play smoothly at first.
But as soon as the sound ended, Gnash emitted a short loud screech.

The attached `pcmplay_fp11.2.202.491.ogv` is a video result from Adobe Flash:
You'll see that siren sound played and stopped normally.

The attached `pcmplay_gnash0.8.11dev-6b269f9.ogv` is a video result from Gnash:
You'll see that as soon as siren sound ended, loud screech followed.

This symptom occurs with both FFmpeg and GStreamer media handler.
Screech is also captured when `--audio-dump` is used.
Also, this issue didn't apply to MP3-compressed sound object.

Test flash file, sound, source code and build script are attached as `pcmplay.zip`.
Siren sound embeded is PCM 44100Hz 16-bit Mono, with the length of 1.0 sec
(44100 samples total).

Gnash: 0.8.11dev (git 6b269f9 24-May-2015)
Adobe Flash Player: 11.2 r202 (11.2.202.491) standalone
System: Debian GNU/Linux 7.0 Wheezy i386

Nutchanon Wetchasit <nachanon>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #34927:  pcmplay-11k.zip added by nachanon (75KiB - application/x-zip - Test Flash files (11025 Hz PCM uncompressed/raw little-endian 16-bit/8-bit mono/stereo cases), sound, and source code)
file #34926:  pcmplay-22k.zip added by nachanon (80KiB - application/x-zip - Test Flash files (22050 Hz PCM uncompressed/raw little-endian 16-bit/8-bit mono/stereo cases), sound, and source code)
file #34872:  rawpcmplay.zip added by nachanon (633KiB - application/x-zip - Test Flash files (raw little-endian PCM 16-bit/8-bit mono/stereo cases), sound, and source code)
file #34846:  pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip added by nachanon (163KiB - application/zip - Audio dumps, log outputs, and backtraces from Gnash running `pcmplay-8bit.swf` and `pcmplay-stereo-8bit.swf`)
file #34845:  pcmplay-8bit.zip added by nachanon (9KiB - application/zip - Test Flash files (8-bit mono/stereo case), sound, and source code)
file #34835:  pcmplay-lr.zip added by nachanon (290KiB - application/zip - Test flash file (stereo with L-R difference), sound, and source code)
file #34826:  pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip added by nachanon (119KiB - application/zip - Audio dumps and log outputs from Gnash running `pcmplay.swf` and `pcmplay-stereo.swf`)
file #34825:  show-sound-decoding-diagnostic.patch added by nachanon (1KiB - text/x-patch - Patch to show diagnostic information on sound decoding)
file #34754:  pcmplay-stereo_fp11.2.202.491.ogv added by nachanon (65KiB - video/ogg - Screencasts from the stereo test file)
file #34755:  pcmplay-stereo_gnash0.8.11dev-f341372.ffmpeg.ogv added by nachanon (76KiB - video/ogg - Screencasts from the stereo test file)
file #34753:  pcmplay-stereo.zip added by nachanon (298KiB - application/zip - Test flash file (stereo), sound, source code, and logs)
file #34600:  pcmplay_fp11.2.202.491.ogv added by nachanon (38KiB - video/ogg - Test Flash file, sound, source code, and screencasts)
file #34601:  pcmplay_gnash0.8.11dev-6b269f9.ogv added by nachanon (83KiB - video/ogg - Test Flash file, sound, source code, and screencasts)
file #34599:  pcmplay.zip added by nachanon (11KiB - application/x-zip - Test Flash file, sound, source code, and screencasts)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by strk
  • -email is unavailable- added by nachanon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-19 nachanon Attached File- Added pcmplay-11k.zip, #34927
    2015-09-19 nachanon Attached File- Added pcmplay-22k.zip, #34926
    2015-09-14 strk StatusNone Ready For Test
    2015-09-14 nachanon Attached File- Added rawpcmplay.zip, #34872
    2015-09-10 nachanon Attached File- Added pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip, #34846
    2015-09-10 nachanon Attached File- Added pcmplay-8bit.zip, #34845
    2015-09-08 nachanon Attached File- Added pcmplay-lr.zip, #34835
    2015-09-07 strk Dependencies- bugs #25456 is dependent
    2015-09-07 nachanon Attached File- Added pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip, #34826
    2015-09-07 nachanon Attached File- Added show-sound-decoding-diagnostic.patch, #34825
    2015-09-03 strk Carbon-Copy- Added bjacques
    2015-08-27 nachanon Attached File- Added pcmplay-stereo_fp11.2.202.491.ogv, #34754
        Attached File- Added pcmplay-stereo_gnash0.8.11dev-f341372.ffmpeg.ogv, #34755
    2015-08-27 nachanon Attached File- Added pcmplay-stereo.zip, #34753
    2015-08-08 nachanon Attached File- Added pcmplay.zip, #34599
        Attached File- Added pcmplay_fp11.2.202.491.ogv, #34600
        Attached File- Added pcmplay_gnash0.8.11dev-6b269f9.ogv, #34601

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code