* I want to introduce a new way for plugins to
register for a format. Supporting the old FormatManager is
too painful at this point and not worth the effort.
* Adds some missing methods signatures.
* integer vs float framerate is a longstanging debate. In theory,
in digital a/v there should not be need for floating point framerates.
This is because unless the software is run on exoteric hardware, there
is not need for it. Unfortunately, some legacy from the past like the
29.7 hz debate (NTSC) still may need to work under floating point framerates.
Even if in pratice it'd be run at 30 hz anyway.
* In theory, to handle all those correctly we should use a rational framerate,
however most code should be rewritten to support that correctly, and
it'd add some excessive complexities.
* All integer types are reverted back to unsigned ones. There's really
no reason to use signed integers there, and more importantly the danger
for integer underflows and the attached security concerns is very big.
* We try to conform to what ffmpeg does, it is
unuseful to support metadata keys formats which
aren't really used anywhere.
* Add TODO with some infos for future improvements.
* Namespaces protect symbols, I didn't consider that when adding
the BCodecKit namespace, so, the AddOnManager complained that
instantiate_plugin() was missing. A macro is introduced that allow
plugins to specify it's className, version and name, this ease
the declaration of the plugin symbols, otherwise the function
should have been declared inside the BCodecKit namespace which
we would like to avoid.
* The code is also more future proof, since in future the AddOn manager
can begin to check for plugin versions.
* This should be probably uniformed with the future
media kit format defs. Not sure why those formats are
separated and used only by the codec kit. Eventually,
if needed can be changed to some name that differentiate
them better than media defs.
* Use string keys. I am still convinced we need BValue.
* Use boolean instead of status_t in return, this is
much more handy in pratical use given that there's no
really a status to check.
* Those classes are not ready for public consumption. Ideally,
I'd add a well designed BCodecRoster wrapping them. This is part
of the general cleanup I am doing to get the code in a good state
before going to finalize the design.
* I don't plan to reintroduce BMediaFile in the media2 API, and
I'd like to remove any (explicit) usage of entry_refs and things
like that.
* I plan to introduce BMetaData and BMediaFormat which is going
to be different than what we do now.
* We need to explicitly use the mime type when it's available and
it is another design consideration when CodecRoster will be introduced.
