[haiku-development] Re: Media plugin support - to message or not to message
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Jul 2014 14:20:16 +0200
On Tue, Jul 22, 2014 at 01:51:39PM +0200, Axel Dörfler wrote:
> > On July 21, 2014 at 5:46 PM pulkomandy <pulkomandy@xxxxxxxxxxxxx> wrote:
> > [...] This can be considered a regression, but we already discussed
> > this before I made the change and there were two reasons to go with it
> > anyway:
>
> Since you repeat these same non-sense arguments again, I take the liberty to
> repeat why they are non-sense in the first place, maybe you forgot, or were
> not
> listening (just to show you how annoying that is).
>
> > - Installing and uninstalling media plugins happens very rarely, and
> > having to restart apps when doing so is only a minor annoyance,
>
> We go to great lengths everywhere to make it possible to avoid such
> annoyances.
> Why on earth are we doing that if the lazy way is so much simpler? These are
> actually the details where Haiku can shine because of its comprehensive
> approach.
>
> > - Most applications (MediaConvert, for example) got the list of available
> > plugins and formats once on startup, and never refreshed it, so the
> > scanning of the plugins had no benefits at all. I don't remember if we
> > could find an application that allowed installing plugins and using
> > them straight away without needing a restart.
>
> Again, broken applications are not an excuse for a broken API.
>
> The actual argument behind that, as Stippi explained, is that there is
> currently
> no way to listen for changes in the list in order to refresh UI elements. Of
> course, an application could always just build it in the moment the user
> clicks
> the button, but a notification would still be a nice approach. Of course, that
> could simply be implemented, too.
I'm only explaining what changed from the previous imperfect
implementation to the current, also imperfect one.
Previous implementation (with plugins probed completely server side):
* No support for hybrid plugins
* Apps can use new plugins as they are installed, but have no
notification when this happens. As a result, no apps use the feature.
* The media server uses one node monitor slot, initial scan of plugins
is done at boot time
Current implementation (plugins scanned by each app when it starts):
* Supports hybrid plugins
* Plugins are scanned at application start only, so the application
needs to be restarted when a new plugin is installed (again, something
that happens very rarely)
* No node monitoring involved.
The perfect solution would handle hybrid plugins and notify apps when a
new plugin is available so they can refresh their format lists. Now,
this is a new feature, which is very nice to have, but is out of R1
scope. That being said, it is possible to implement it in either cases:
* Going back to the server-side scanning with a hybrid server doing
just the plugin probing. I don't like this solution much because of the
extra server that seems rather useless.
* Reintroduce node monitoring (only, not probing) of plugins on the
media server side. The media server would then let the media kit code on
application side that a new plugin is available (or that a plugin was
removed), the client-side code can then probe the plugin and add the
managed formats to the list of available formats.
Both of these solutions work, but without a way to notify the
application code of the availability (or even worse, the removal) of a
plugin, they are not really useful. Doing the probing client-side means
all apps get to do the probing, whereas in the case of server-side
probing, that is done only once. However, there are ways around that,
for example the first app to probe the plugin can send the results (the
list of supported formats) back to the media server, which can then
forward it to other apps.
So yes, all of this can be implemented, and we already discussed the
possible solutions. I was just pointing out that the implementation
change didn't bring any significative regressions when compared to the
previous implementation, and that it still works better than in BeOS,
where you have to restart the whole media server when installing new
media formats.
>
> > Media plugins always were instanciated on the application side. This is
> > what I think you are complaining against, but it is unfortunately quite
> > difficult to do things otherwise if we want to keep our "realtime media
> > performance" label, and the BeOS ABI compatibility. A new API could be
> > designed to have media decoding happen on media server side (or in some
> > other server), but this is definitely out of Haiku R1 scope.
>
> The ABI does not state where the media is decoded. It's just an implementation
> detail.
That's why I said it is difficult, not impossible. Moving the whole
media encoding/decoding server-side, and having the server built with
gcc4, would allow for a single set of decoder plug-ins, and let us get
away from the very old ffmpeg we are currently using, possibly solving a
lot of the problems. However, I'm not sure this can be done while
keeping the current API and with acceptable performance.
--
Adrien.
Other related posts:
