Allow registration of custom codecs in MimeTypes class

[robin2046]

When I am trying to adding new codec, I have to copy all the source code of mp4/ts extractor just to modify a bit of it.
And what is more, since I cannot modify MimeTypes class, I have to fork ExoPlayer instead of just have a simple dependency on it as a library.

So, is it possible to have extension hooks in extractors and functions like MimeTypes.getMediaMimeType() to ease this pain in future?

[andrewlewis]

Is this for a standard/widely used format, or is it for a custom codec? If it's the former, we can probably just add support, or feel free to send a PR and we'll take a look. If it's the latter, this seems like a very specialized use case and I'm not sure we can justify the work and extra complexity to make every extractor extensible for this.

Could you elaborate on what customizations you needed to make in MimeTypes? Is it related to handling of codecs strings?

[robin2046]

Thanks for your reply. I can copy and modify the mp4/ts extractor to add my extension. It is acceptable since I am adding unofficial modification to those famous containers.

However, methods like getMediaMimeType() and getAudioMediaMimeType() is widely used in other modules like HLS/SS/DASH, which I don't want to copy and modify them just for adding a new MIME type string.

My intention is just to support some new codec, which is not published yet. The container is still mp4/ts and can be streamed by HLS/SS/DASH. In order to easily keep the track of exoplayer updates, I want to just use it as a library instead of fork my own branch.

Thanks again for the comment.

[ojw28]

We could probably look at adding some static methods to MimeTypes to allow injection of custom codec information?