* 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.
* We don't aim to replicate this functionality. I don't
think this will be useful at all in future iterations.
Originally I planned to rewrite it on top of the new
BMediaFormat, but now I am of the hopinion this is
greatly unneeded.
* 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.
* 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.
