bomi is not a front end

Many people have asked me to integrate bomi into system-provided libmpv package. Some people even blame me for not doing it mentioning other mpv front end. These questions and requests are reasonable because it appears possible. However, one significant differece from other front ends exists in bomi. Literally, bomi is not a front end.

Front end: separable layer

A key point in concept of front end and back end is separation of layer. Here's a simple description quoted from Wikipedia

In software engineering, the terms "front end" and "back end" are distinctions which refer to the separation of concerns between a presentation layer and a data access layer respectively.

A front end can be separated from back end. This does not mean that a front end can work without back end. Instead, this means that a front end can work with any back end which provides same interface or protocol to interact with front ends, which is defined as a term 'compatiblity'. For instance, SMPlayer which is a famous and great front end of MPlayer also can work with mplayer2 because MPlayer and mplayer2 provides similar slave modes, that is, compatible interfaces. On the other hand, SMPlayer cannot work with mpv without additional compatible layer because mpv dropped and modified most parts of slave mode.

bomi is a fork

Then, what about bomi? Can bomi be separated from mpv? There are two things which makes it not separable.

First, bomi uses customized built-in mpv, literally. Some mpv's features cannot be used from bomi without customized parts. This restriction comes from the limited video output usage of bomi(See Video Output and OpenGL).

Second, bomi itself depends on mpv's internal APIs to implement its own video/audio filters. These have similar functionalities of mpv's vf/afs, but provide better integration with bomi. Because internal APIs are not exposured in libmpv, bomi cannot be compiled with libmpv only. Even if one compiles bomi successfully copying internal header files, it will be broken as soon as mpv changes internal structure.

Ergo, bomi is not separable from mpv, and obviously, bomi is not a front end. Since built-in mpv shares most of code from original one, I prefer the expression mpv-based player. However, if you want to define bomi, bomi is more like a fork rather than front end.

Different program

Although bomi is a fork of mpv, most parts of forked mpv are same as original one as I said. That's because I'm trying to include as much as changes into original mpv through pull request(PR)s. In fact, over than 99% of source code is same with original mpv and 1% is too specialized for certain case which is valid for bomi to make a PR for it.

Someone may think 'then make PRs more actively till bomi can integrate with original mpv'. It's possible to just give up all those uncompatible parts and make bomi compatible with original mpv. However, Supporting mpv compatibility brings lots of negative effects.

Suppose I wanted 'A' in mpv and I implmented it or requested it. 'A' may be a feature or a bug fix.

Even if the change for 'A' is merged soon, system libmpv still lacks 'A' because 'A' is only in git repository. There's a time span between releasing new versions. Moreover, larger gap exists in updating packages in distributions. If I decided to support system libmpv, I could use 'A' after several months later even though I had already implemented 'A' way before. Same logic is applied to a new feature or fix in mpv by themselves. mpv evolves rapidly and libmpv keeps expanding. I cannot adopt those new features or fixes till new version is released. Also, release schedule for bomi is determined by mpv release and distribution update. This is silly. I don't want to wait release my program for other program.

Also, there's a chance that 'A' won't be included in mpv. In that case, there's no option. I just have to give up 'A'. The only alternative is to ask users of bomi to make requests to mpv devs directly. If 'A' was a feature, it can be waited for. But if it was a bug, the sooner, the better. mpv depends on lots of external components, and some bugs are originated from such external libraries. In that case, the fundametal solution is to make a bug report to devs of those external libraries, but some bugs can be avoided by some kind of workarounds inside mpv. I can make my own fix if bomi uses forked mpv but it's not possible for system libmpv.

And don't forget I have to give up some features for the integration.

bomi is different from mpv. Even though they share same code, their policies are not same. If I agree with mpv's policy, there's no point to develop bomi. I would just use mpv. Forking mpv is the best option I found for bomi.