[haiku-development] Re: RFC: Media plug-ins hybrid support
- From: Jessica Hamilton <jessica.l.hamilton@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 2 Apr 2014 08:33:41 +1300
On 2 April 2014 02:04, PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> 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.
>
To me, this sounds like the most straight-forward approach. It also seems a
bit redundant having to load a plugin into the media_server's address space
temporarily only to then have the application do it itself.
I also support removing the node monitoring if this approach is taken.
Other related posts:
