Media Plugin System Project Notes

Changes to existing system

Client side code

• A large section of the client code that deals with moving bytes from memory into a texture managed by the client that OpenGL understands will have to be rewritten. There are several reasons for this - firstly, that code has grown "organically" and needs a significant clean-up. Secondly, the process by which dynamic textures are created and managed hasn't changed since QuickTime was added to the client 4 years ago. Lastly and most importantly, the programming paradigm changes completely with this new design from a synchronous model where you call functions to a message based model. When you send a message to a plugin, consider it as being shot into the dark. You may (or may not) get a response back at some future time. Whether a particular message will cause a response to be sent will be defined by the particular type of plugin.

• plugin will specify which transport controls should be used via a fragment of XML.

• The number and type of transport controls can vary over time and should support an enabled and disabled state.

• QUESTION: How will we do this? Built in set of icons that XML file references plus ability to specify your own or something more straightforward?

Existing media implementations

• New versions of the embedded Web browser (using LLMozLib) and movie support (QuickTime and GStreamer) will be written using the new API.

• Ideally, we will include at least one additional Linden Lab written plugin and one more 3rd party plugin.

• Some simple examples will be included in the API documentation.

Testing philosophy

• Lots of QA and user testing via a 'First Look' release and blog post encouraging users to test the more esoteric existing media set ups.

• Script to grab all media URIs from the grid, add them to a playlist that is used as input to a test harness that tries to open and render each one for a few seconds. Clearly this won't test the visuals but may find potential crashers. A lot of this exists already. It's takes a long time - several days to grab URIs and a day to run through them.

• We should think about unit tests for each media implementation. A script can run through the directory and load each one, initialize it and render a known media URL at a given "timecode". The output can be captured and written to a file. We can either visually examine the file or look for an all black frame (for example) and pass/fail automatically. Not perfect but it would catch big failures.