[Gnash-dev] Sortie's weekly GSoC activity log

[Jonas 'Sortie' Termansen]

Hi, I'm Jonas 'Sortie' Termansen, and I'm the Google Summer of Code 
student working on Gnash's media playback.

I decided to post weekly logs of my activities here on the mailing list, 
so you fine folks can see what I am doing and comment if you have 
anything to say.

This is just a bullet-point list of my activities, my thoughts, and 
considerations.

* Decided to make testcases for libmedia's various handlers, codecs and 
considered various methods of doing so.
* Studied a bit how digital sound works and wrote a small program 
'mksound' that generates wav/raw PCM files with a specific tone. 
<http://www.maxsi.org/software/mksound/>
* Investigated whether any existing testcases could be easily adapted. 
Doesn't look like it.
* Submitted bug <https://savannah.gnu.org/bugs/index.php?33764>
* Studying in what manner FFmpeg and gst post-processes its output and 
how it would affect any testcases.
* Decided to test performance as well when writing libmedia testcases.
* Read a lot of documentation on how libmedia integrates with the main 
player.
* Wondered whether it is possible/useful to compile both GST and FFmpeg 
into gnash, and then search for a decoder in both backends.
* That would make it easier for make check to check all possible backends.
* Figuring out how GnashFactory works.
* Fixed bug where gnash/base-attempter.sh wasn't in EXTRA_DIST. (commit 
3bf4171)
* Learned what libtool is, what it is good for, and how it actually works.
* Began writing the libmedia.all/test_decoding.cpp testcase for audio 
decoding.
* Made makeFileChannel also accept a filepath string and not just a C 
FILE* stream. <https://savannah.gnu.org/patch/index.php?7582>
* Created a mini media player for libmedia.all/test_decoding.cpp.
* My testcase only tests sound files at this point. Video testing will 
be added soon.
* Had some nasty MediaParser race conditions when implementing the 
testcase that made it difficult to see when MediaParser::getAudioInfo() 
is available, and how should the code wait for the next frame?
* It could possibly be beneficial for AudioDecoder to contain a string 
about which codec it is using, making it easier to print debug output in 
my testcase. It could also be added to AudioInfo.
* FFmpeg fails to decode .wav, .ogg, .mkv, .webm, .flac sound files 
(could not initialize parser for ffmpeg codec).
* The parameter 'parse' in "boost::uint8_t* AudioDecoder::decode(const 
boost::uint8_t* input, boost::uint32_t inputSize, boost::uint32_t& 
outputSize, boost::uint32_t& decodedData, bool parse);" seems to be 
redundant as it always is true, except in very rare cases (decoding RAW 
sound), but then the audiodecoder is able to figure it out anyways.
* The FFmpeg parse system is causing trouble when decoding many of my 
non-flv testfiles. I'll have to refactor it. Getting rid of the needless 
'parse' parameter would simplify matters.
* Investigating whether (and how) the parse parameter can be safely 
removed when dealing with other backends (gst, haiku, simple, speex).
* AudioDecoder{Simple,Speex,Gst,Haiku} doesn't use the 'parse' parameter 
at all.
* Haiku media backend is a stub. No need to worry much about it.
* Removed the 'parse' param from all backends.
* Changed parsing logic in AudioDecoderFfmpeg such that the presence of 
a parser for a given format is detected automatically.
* The above change now fixes vorbis/.ogg and .wav playback in my 
testcase for FFmpeg.
* The .webm, .mkv, and .flac containers are still broken for FFmpeg, 
they get a premature EOF and halt.
* Does Gnash have a built-in way to scan a directory for files? I'll 
just write a quick-and-dirty method myself that is portable (tested with 
Wine).
* My testcase now automatically scans a sample directory for files to test.
* I wrote a script using mksound(see above), ffmpeg(1), and lame(1) to 
generate test files for my test case.
* Gstreamer appears to have some EOF halting trouble on .mp4 and .ogg 
files during my testcase (.flv files works just fine).
* A similar bug was described on the IRC; it is probably the same bug. 
I'll investigate.
* Gstreamer appears to output a kilobytes more data than FFmpeg.
* Gstreamer appears to freeze on my test .wav file (created by mksound) 
(probably a bug in my code).
* AudioDecoder::decode() allocates 4096 bytes on every call that is soon 
freed. While malloc shouldn't take long to handle that, it would 
probably be better to switch to memory-pooled buffers. (Oh hey, wasn't 
that officially my GSoC project?)

Alright, thanks. That was this week's achievements. I'll be back next week.

Jonas