Sandro, would it be possible that the patch would be released with next 0.8.11 version?

Many thanks for your help.

Sandro,

the patch you posted in bug #25456 seems to work fine. Could it be applied to master?

the testcase (http://archive.org/download/Lessig-Free_Culture/lessig-freeculture.swf) has ActionScript code allowing sound start/stop and going to next/previous slide that doesn’t work.

Which is the best way to report this?

Many thanks for your help,


Pablo

Bug #25456 seems fixed to me.
This ticket isn't really a bug (there's no testcase proving anything is wrong) but more of a task.

+1 to go with the push/pop model.
Sounds the cleanest.

Eventually, we'll also want a method to check
if any input data didn't result in a set of samples
(for error logging and the like).
So the caller, to follow the current design, would
push blocks, pop as many resulting samples buffers
(tipically one for each decoded frame)
and then check if any partial buffer remained unbuffered.

I'd return sampls by auto pointers to SimpleBuffer from pop().

FYI: the AudioDecoder interface already allows a form of progressive decoding in the second ::decode interface (the one
NOT taking EncodedAudioFrame).

Only, state keeping is not done internally but left to caller.

See:
http://www.gnashdev.org/doc/apidoc/classgnash_1_1media_1_1AudioDecoder.html#e29075a2a2ca9a6ef7a266c545559b24

The decodedData output parameter expresses how much of the data
was used, then it's up to caller to keep the rest for next
call. This is how sound_handler_SDL uses that interface currently,
for embedded sounds.

Presumably, but it won't help in fixing this bug.

Currently, AudioDecoder requires implementation of at least one decode() method. The decode() method requires that the decoder decode the encoded data passed and return all decoded information.

However, this is not how most decoding libraries operate. In practice, libraries expect to receive an unspecified amount of data, which will be split into frames and returned on a frame-by-frame basis. It is then up to the AudioDecoder to reallocate a buffer large enough to contain all the decoded frames so as to comply with the AudioDecoder::decode() requirements. It is important to realize that a SWF or FLV frame does not necessarily correspond to a single frame of decoded audio. Indeed, a SWF Or FLV frame might contain less than a single frame of encoded audio data.

This is a huge overhead in unnecessary reallocation and CPU time. Instead, AudioDecoder should specify a push/pop/pull interface similar to VideoDecoder, so that decoders can return decoded data frame by frame.