[haiku-development] RFC: Media plug-ins hybrid support

  • From: PulkoMandy <pulkomandy@xxxxxxxxx>
  • To: Haiku dev <haiku-development@xxxxxxxxxxxxx>
  • Date: Tue, 1 Apr 2014 15:04:24 +0200

Hello there,
During my work on adding HTML5 audio/video to WebKit, I hit an issue
with the design of the Media Kit and the way plugins are loaded.

I'm not talking about media add-ons, these live only in the
media_server and work fine. I'm talking about plugins, which are used
for decoding and encoding audio and video files. We currently have a
single one that uses ffmpeg to decode all formats we support.

Unlike add-ons, the medi plugins are loaded in the application memory
space. The current design is as follows:

* The media_server monitors the plugins directories. When a file is
added, it instanciates the plugin in order to identify wether it is a
decoder, encoder, reader or writer. 4 lists for these 4 kind of
plugins are managed by the media_server.
* When an application wants to decode or encode a file, it gives the
media_server a format information, and the media_server identifies and
returns the matching plug-in, in the form of an entry_ref.
* The application loads the plugin, instanciates it, and uses it for
decoding (this is wrapped in Media Kit classes, BMediaFile and
BMediaTrack).
This is where things break for hybrid apps: the plugin returned is
always for the primary architecture, and doesn't work on the secondary
one.

This design is similar to the way BeOS worked. The idea is that the
media_server can cache the mapping of media formats to matching
plugins, and thus find the right plugin without having to scan the
disk, instanciate each of them, and ask it if the requested format is
supported.

There are several ways to change this, but I'm not sure which is best,
so I'd like more opinions.

1) Move everything application side.
Besides the monitoring and caching, media_server never uses the
plug-ins. So this could be moved to the application side (in the Media
Kit). Each app could do the caching of format>plugin, possibly with a
lazy initialization as formats are requested.

There could be a problem with all apps monitoring the plugins
directories, but I'm not sure that's needed. It was important in the
media_server to allow adding new formats without restarting the
server, but restarting an app to get a new format (something that
doesn't happen very often) sounds reasonable. Alternatively, the
add-ons on disk could be re-scanned each time a request to find a
plugin is made.

I'll add that the current media_server code re-scans the plugin
directories each time a request is made, to make sure that plugins
stored in user directories are tried first, and system ones second.
This doesn't seem to have an unacceptable performance impact.
Ultimately the plug-in still has to be read from disk and instanciated
in each application, so the cost of browsing the disk to locate it is
not so high.

2) Keep things in the media server
To keep the monitoring and caching shared between apps, we would have
to keep things on app_server side. While monitoring the plugins for
the secondary architecture is easily possible, there is no way to
instanciate the add-ons to detect which kind they are
(reader/decoder/writer/encoder).

One way to achieve this would be to have an hybrid-compiled part of
the server running just for this purpose (as a separate team). The
server would delegate all requests comming from hybrid apps to that.


What would you suggest?
-- 
Adrien
http://pulkomandy.tk

Other related posts: