[MPlayer-dev-eng] mplayer libtremor patch

[Diego Biurrun]

On Sun, Aug 13, 2006 at 03:09:44PM +0300, Siarhei Siamashka wrote:
> 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.

Tremor is not that small:

-rw-rw-r-- 1 diego diego 127378 2006-08-08 11:49 tremor/libvorbisidec.a
-rw-rw-r-- 1 diego diego 64280  2006-08-08 11:48 libavcodec/vorbis.o

And most importantly it's duplicate.  We already have a (better) Vorbis
decoder in FFmpeg.  Supporting external Tremor for testing and ARM users
is fine, but included in the main package it's just bloat.

Removing code does not introduce the risk for new bugs.  The FFmpeg
Vorbis decoder might get more widespread testing and bugs in it might
get uncovered, but this is a welcome sideeffect, not a drawback.

> 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.

That's the way the game is played.  I cannot test on ARM, yes.  If
somebody cares about ARM I expect them to help me by doing the work I
cannot do.

> > > 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.

OK, if English is not your native language I'll try to give you the
benefit of the doubt.  It sounded very much as if you were telling me
what to do with my time.  This is what I felt was insulting.

> > > > 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.

The master plan around here is that FFmpeg should be the be-all and
end-all of codec libraries.  We wish for FFmpeg to someday make all of
the others obsolete.

Supporting external Tremor is good in and of itself for several reasons:

- It would allow testing and using more current versions of Tremor.
  Hey, they may be faster and better, possibly even on ARM.
- It would allow updating our internal Tremor copy, should we decide to
  do that.
- It would allow removing internal Tremor should we wish to do so,
  reducing code and binary size, which makes maintenance easier.

> 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.

OK, it seems it was not your intention, but you made it sound as if you
were telling us what to do.

> 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.

Yes, defaults could be better for such platforms.  This is something
that can be done from the config file, though.  Have you tried removing
mp3lib from the list of audio codecs to use, like so:

  mplayer -ac -mp3, foo.mp3

Have you tried ffmp3?  The MP3 decoder in FFmpeg is integer-only.  I'd
be interested to know how it performs compared to libmad.  

Now that you mention it, libmad is a good example for external libraries
that work well.  We support it externally and you seem to have had no
problems addding it to your build...

> 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.

Sounds wonderful.  How about you implement this?

Diego