The list of Reader plugins will also not remain sorted,
the same mechanism needs to be applied as for Decoders,
so that user add-ons are always found before system
add-ons.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38360 a95241bf-73f2-0310-859d-f6bbb57e9c96

* When unregistering plugins, decoders specifically,
we need to remove its globally registered formats
from the FormatManager.
* When searching decoders for a given format, we need
to search by add-on directory, since the decoder
list will not stay sorted once some have been removed
or added after the initial add-on scan.

These fixes make it finally possible to rebuild media
plugins and have the media_server pick up the changes
without needing a restart.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38338 a95241bf-73f2-0310-859d-f6bbb57e9c96

* It's easier if we deal with just entry_refs instead of converting
to BEntry and back to entry_ref. This ommits a check to
BEntry::InitCheck(), but AddOnMonitor should pass us only valid
entry_refs.
* Removed no longer valid TODO.

TODO: There is still some problem with reloading add-ons, once they have
been reloaded, they fail to instantiate properly, as if the entry_ref
is pointing to the wrong node.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38328 a95241bf-73f2-0310-859d-f6bbb57e9c96

The media_server supports updates to add-ons now.
It unloads any media_format mappings when an add-on
becomes unavailable, and consequently reloads the
supported formats and similar when the same add-on
becomes available again. Previously it would only
load previously unkown add-ons by node-monitor
events (unkown name). What also works is that user
add-ons shadow/hide system add-ons when installed,
and the system add-on will become effective immediately
when removing the user add-on again. One thing to
note is that certain IDs will not stay consistent.
I am not aware of an application for which it could
be a problem, most should rememeber codecs by name.
In any case, I only tested add-on events a lot, and
not so much the effects of unstable media_file_format
IDs, so it's possible there are regressions, though
only when installing new versions of add-ons, which
previously mostly required a media_server restart
anyway.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38282 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented support for get_next_encoder() variations from MediaFormats.h.
The AddOnManager in the media_server registers one encoder entry per
successful EncoderPlugin::RegisterNextEncoder(). This gives us a first idea
what media_format_family and input/output media_type is supported. The
mechanism may have to be extended, or the Encoder needs an API to specialize
a format further. In that case, the get_next_encoder() version that takes
optional _acceptedInput/OutputFormat needs to instantiate the plugin and
needs to ask the Encoder. But AFAIK, no app uses it like that anyway.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32005 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the way Encoders are published by EncoderPlugins. Encoder retrieval
in PluginManager is reenabled. We use the media_codec_info.id to reference
a specific plugin, while the sub_id will be used to reference individual
Encoders that the plugin supports. No idea if that's how it was intented, but
some comments hint in this direction. I failed to mention this before, but
comments are of course very welcome on any of these commits, as always.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31993 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement the backend of get_next_file_format(). The AddOnManager maintains
a list for known media_file_formats. The internal IDs map to plugins.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31950 a95241bf-73f2-0310-859d-f6bbb57e9c96

In theory, I added management of WriterPlugins and EncoderPlugins. When looking
at media_file_format.id, I wonder if this could work without having to get an
entry_ref from the server for a WriterPlugin, added TODOs to this effect.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31936 a95241bf-73f2-0310-859d-f6bbb57e9c96

Header indentation updated, changed "* " style.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31930 a95241bf-73f2-0310-859d-f6bbb57e9c96

new MediaFormats. node monitoring codec plugin loading. codec mods to support new codec api to retrieve supported formats.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6465 a95241bf-73f2-0310-859d-f6bbb57e9c96

Almost rewritten the AddOnManager. It now works together with the new
media decoder detection code and the FormatManager.
It now stores all registered formats from a decoder, and uses this
information to implement GetDecoderForFormat().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6245 a95241bf-73f2-0310-859d-f6bbb57e9c96

update to the codec api, docoder assignment is now handled in the server
multiple reader add-ons are probed to recognize a media file
FormatManager does the translation from media_format to media_description


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5667 a95241bf-73f2-0310-859d-f6bbb57e9c96

The list of Reader plugins will also not remain sorted,
the same mechanism needs to be applied as for Decoders,
so that user add-ons are always found before system
add-ons.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38360 a95241bf-73f2-0310-859d-f6bbb57e9c96

* When unregistering plugins, decoders specifically,
we need to remove its globally registered formats
from the FormatManager.
* When searching decoders for a given format, we need
to search by add-on directory, since the decoder
list will not stay sorted once some have been removed
or added after the initial add-on scan.

These fixes make it finally possible to rebuild media
plugins and have the media_server pick up the changes
without needing a restart.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38338 a95241bf-73f2-0310-859d-f6bbb57e9c96

* It's easier if we deal with just entry_refs instead of converting
to BEntry and back to entry_ref. This ommits a check to
BEntry::InitCheck(), but AddOnMonitor should pass us only valid
entry_refs.
* Removed no longer valid TODO.

TODO: There is still some problem with reloading add-ons, once they have
been reloaded, they fail to instantiate properly, as if the entry_ref
is pointing to the wrong node.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38328 a95241bf-73f2-0310-859d-f6bbb57e9c96

The media_server supports updates to add-ons now.
It unloads any media_format mappings when an add-on
becomes unavailable, and consequently reloads the
supported formats and similar when the same add-on
becomes available again. Previously it would only
load previously unkown add-ons by node-monitor
events (unkown name). What also works is that user
add-ons shadow/hide system add-ons when installed,
and the system add-on will become effective immediately
when removing the user add-on again. One thing to
note is that certain IDs will not stay consistent.
I am not aware of an application for which it could
be a problem, most should rememeber codecs by name.
In any case, I only tested add-on events a lot, and
not so much the effects of unstable media_file_format
IDs, so it's possible there are regressions, though
only when installing new versions of add-ons, which
previously mostly required a media_server restart
anyway.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38282 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented support for get_next_encoder() variations from MediaFormats.h.
The AddOnManager in the media_server registers one encoder entry per
successful EncoderPlugin::RegisterNextEncoder(). This gives us a first idea
what media_format_family and input/output media_type is supported. The
mechanism may have to be extended, or the Encoder needs an API to specialize
a format further. In that case, the get_next_encoder() version that takes
optional _acceptedInput/OutputFormat needs to instantiate the plugin and
needs to ask the Encoder. But AFAIK, no app uses it like that anyway.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32005 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the way Encoders are published by EncoderPlugins. Encoder retrieval
in PluginManager is reenabled. We use the media_codec_info.id to reference
a specific plugin, while the sub_id will be used to reference individual
Encoders that the plugin supports. No idea if that's how it was intented, but
some comments hint in this direction. I failed to mention this before, but
comments are of course very welcome on any of these commits, as always.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31993 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement the backend of get_next_file_format(). The AddOnManager maintains
a list for known media_file_formats. The internal IDs map to plugins.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31950 a95241bf-73f2-0310-859d-f6bbb57e9c96

In theory, I added management of WriterPlugins and EncoderPlugins. When looking
at media_file_format.id, I wonder if this could work without having to get an
entry_ref from the server for a WriterPlugin, added TODOs to this effect.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31936 a95241bf-73f2-0310-859d-f6bbb57e9c96

Header indentation updated, changed "* " style.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31930 a95241bf-73f2-0310-859d-f6bbb57e9c96

new MediaFormats. node monitoring codec plugin loading. codec mods to support new codec api to retrieve supported formats.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6465 a95241bf-73f2-0310-859d-f6bbb57e9c96

Almost rewritten the AddOnManager. It now works together with the new
media decoder detection code and the FormatManager.
It now stores all registered formats from a decoder, and uses this
information to implement GetDecoderForFormat().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6245 a95241bf-73f2-0310-859d-f6bbb57e9c96

update to the codec api, docoder assignment is now handled in the server
multiple reader add-ons are probed to recognize a media file
FormatManager does the translation from media_format to media_description


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5667 a95241bf-73f2-0310-859d-f6bbb57e9c96