[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Libmedia Redesign

From: Benjamin Wolsey
Subject: Re: [Gnash-dev] Libmedia Redesign
Date: Tue, 23 Nov 2010 09:40:17 +0100

Am Montag, den 22.11.2010, 12:13 -0700 schrieb Patrick Mitchell:
> Hey everybody, 
> I'm new to the project, working with 3 other University of Colorado
> students as something-like interns; I'm trying to fix up the
> webcam/microphone input functionality, but I'm not sure where to
> start; I also know that some of you want the libmedia libraries
> redesigned, so I'd like to hear any input you have for how to change
> that section around. I'm still pretty thoroughly a noob, so I
> apologize in advance for all the mistakes I'm going to make.

I want the AudioInputGst and VideoInputGst classes redesigned, but this
is also a prerequisite for them working. The base input classes need
extending and adapting, but no major redesign. At at the time of the
last attempted design I made various suggestions on this list, which may
possibly contain useful information. You can search the gnash-dev
archive online to find the mails.

I looked at the current code again recently and found that a) it leaks
memory pretty much continuously, b) it duplicates code like crazy, and
c) it crashes under certain circumstances. You will find some useful
things there (for instance how to access devices), but you'll save a lot
of time by starting from scratch and just using bits of the code for

I'd advise you to start by doing what Sandro suggested and plan how the
data will get from the input devices to the core, but also to look at
the requirements of ActionScript: how should AudioInputs relate to
actual input devices? where should they be stored? how should
ActionScript objects correspond to particular AudioInputs? where should
those ActionScript objects be stored? When should they be created? What
happens when a camera or microphone is removed from the system? Or

You can share your plans on a wiki page or in a mail to this list.

For general coding karma:

1. Avoid all use of g_printf, *especially* g_strdup and friends, gchar*,
and any other g* functions or types, because they aren't typesafe or
exception safe, and the current code omits to free most of the objects
it creates in any case.
2. Read the coding style guidelines on the Gnash wiki.
3. Become familiar with boost.

And finally: make sure the entire testsuite builds and completes before
changing anything, because causing failures in the testsuite is worse
than not writing any code at all.


Use Gnash, the GNU Flash Player!

Benjamin Wolsey, Software Developer -
C++ and Open-Source Flash blog -


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]