[haiku-commits] Re: Aw: Re: haiku: hrev47086 - in src: kits/media servers/media
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 02 Apr 2014 17:59:53 +0200
Am 02/04/2014 16:57, schrieb Stephan Aßmus:
Bad applications can hardly be an argument for bad OS level services.
This isn't about bad application design: there is no way to get a
notification when a plugin is added or removed. So,the application
would have to poll the Media Kit and query the list repeatedly to see
if there is a change. On the application side this can be done at
strategic points (like, when the codec list menu or window opens), but
BMediaFormat also does this and, at each call to one of its methods,
sends a message to the media_server, and waits for a reply, to get the
updated list of codecs.
Exactly.
While not being able to get notifications can certainly be improved,
scanning the codecs should be fast enough to do it on the fly, at least
if it operates on cached data (which again rules out my previous
solution, damnit :-)).
I was going towards implementing this, but I think it is a bit
pointless. The media_server would notify all applications that there
is an update to the codecs, and all applications would instanciate the
new codec to see what changed.
No, that's not how I laid it out at all. There would be no notification,
only the cache is invalidated. Only if an application actively asks for
the codec list, the cache will be updated.
Sure, this could happen at the same time in different applications, but
that's not really an issue.
But anyway, Stippi's suggested solution is indeed the best way to
implement that.
Additionally to these problems, it doesn't actually implement the
caching the way it should be done. The caching serves two purposes:
1) To the cache list of codecs.
2) To get a specific codec for a given format without knowing the list
of codecs. This one is also interesting, since it triggers each time a
file is opened.
Why wouldn't it address that? Where have I written that it would not
address that?
Just caching the names would be completely superfluous. That's actually
a pretty fast operation. Loading the add-on, and executing it is what's
expensive, and should be avoided as long as possible in the client.
If done on the media server side, then it also reduces application
startup time and also the first opening of a media file, which should be
the whole point, IMHO.
Sure, that makes sense.
If this form of caching is desired, then the media server should simply
have one add-on scanning sub-service per architecture. And it should
forward the requests it receives from clients to the one matching the
client architecture. I did suggest this in IRC yesterday.
That sounds indeed like the best solution so far.
But one problem with this whole discussions is that the list of add-ons
is reduced to one, the ffmpeg addon. The performance concerns are rather
pointless, given that all that will most likely ever happen from here on
is the ffmpeg plugin getting fixes and supporting more and more formats.
Why would there ever be additional codec plugins anymore?
640kb will be enough for anybody. Fact is, you don't know the future.
Besides that, we already had a good, scalable, caching implementation.
Replacing that with an inferior mechanism in order to add a feature
makes me shudder.
Even that one add-on could make a difference in application
responsiveness, anyway.
Bye,
Axel.
Other related posts:
