[MPlayer-dev-eng] mplayer libtremor patch

[Siarhei Siamashka]

On Saturday 12 August 2006 21:13, Diego Biurrun wrote:

> > > Tremor was added back when there was no Vorbis decoder in FFmpeg.  Now
> > > that there is one and it has become faster than Tremor in 99% of all
> > > cases there is good reason to remove it again.
> >
> > I would not call it a good reason. It only would make sense if Tremor was
> > broken with nobody available to fix it. But as long as it works fine on
> > ARM (and it does),
>
> The reason is called bloat.

OK, finally we are getting somewhere and at last you used this argument.
Tremor is reasonably small, removing it requires some work (done by you, so I
don't care much) and introduces risk of new bugs. Also you can't verify that
new external Tremor works on ARM, so it requires someone to do this and fix
if needed, and that is a bit annoying.

Also I'm not very enthusiastic about modular systems. It the real world
monolithic solutions are sometimes better and easier to maintain. Some
examples are Linux kernel vs. Hurd. When you split a system into modules, it
becomes somewhat harder to install, track dependencies and ensure that all
modules work properly together.

Removing internal Tremor can make life somewhat harder for already a limited
number of ARM users, but see the end of my post for more details and some
suggestions.

> > I don't see any reasons for you to spend your time and do some work
> > with the only goal to remove internal Tremor. Do you have nothing else
> > to do?
>
> This is an insult.

Not really, was a question (also English is not my native language and I'm
sorry if it sounded like insult). The situation is quite curious and I'm just
intrigued to know your reasons. Right now my impression is that you want to 
do this Tremor removal just because it is fun. And I don't mind it, almost
all open source development is done because people like it and it is a way of
showing their creativity.

> > > I know you care about ARM and Tremor.  A good way to show your
> > > appreciation would be to help fix external Tremor support.
> >
> > Not really. I do care about ARM, but don't particularly care about
> > vorbis, it is not so widely used after all. And I don't have much free
> > time available for open source development and there are things that have
> > higher priority for me (when speaking about MPlayer, these are optimized
> > scaling and color conversion for ARM).
>
> You flame, but you are not willing to contribute.  Somehow I'm not
> surprised...

I don't mind contributing, I'm just too lazy to do stupid work that could be
easily avoided, maybe I'm getting old. Also proposing me to work on
supporting external Tremor without proving your point was not a very good
idea, you generally can't expect someone to do the work he does not believe
in, it is just contrary to the spirit of free software development. And I
don't know your skills, you don't know mine, it is better to avoid making fast
conclusions.

As I already told you in one of the previous posts, you are the bosses here so
do as you wish. It just seemed to me that you are going to make a mistake and
thought that it is better to warn you about this. I'm sorry again for any
possible misunderstanding.


Now on a more constructive side. This is related to ARM support in MPlayer.
The biggest problem seems to be not techical, MPlayer works fine and fast
enough on ARM. It is documentation and default configuration. People trying
just standard ./configure + make building sequence get unusable binary that 
is extremely slow. Surely if they take some time to investigate the problem,
everything can be compiled properly but most give up too early thinking that
it may be impossible or too hard to get watchable playback on their device
using MPlayer. Also somewhat misleading is the fact that it is libmp3 decoder
that is so slow. Intuitively video decoding seems to be more resource
consuming task and people may dig into the wrong direction when 
investigating the problem. When searching mailing lists I have seen a few
people encountering this problem, I almost got into this trap too:
http://www.internettablettalk.com/forums/showthread.php?t=2405

That's why I feel somewhat sorry about possible internal Tremor removal, it
was just a good way to verify that MPlayer actually works fine on ARM.

And now a suggestion. What about showing a warning message in libmp3
initialization code when run on ARM? Something like 'Warning: you are using
libmp3 decoder on ARM cpu, if you experience poor performance and don't
have hardware floating point support, consider using -ac mad instead' .
That should explicitly guide users into the right direction, more people will
be able to successfully compile and run MPlayer and you may get more
contributors willing to work on better ARM support.

Even better would be runtime CPU capabilities detection for ARM (presence of
hardware floating point support, edsp instructions set support, etc.), but
unfortunately I did not find some ready code that does it yet. And if I try
writing this code myself, I can test it only on ARM926EJS cpu that Nokia 770
is using, so I can't be sure if it works right everywhere.