[FFmpeg-cvslog] random thoughts about refactoring

[Michael Niedermayer]

On Sun, Jan 10, 2010 at 07:14:27PM +0100, Diego Biurrun wrote:
> On Sun, Jan 10, 2010 at 05:42:24PM +0100, Michael Niedermayer wrote:
[...]
> > > > > > > There are people here who know H.264 well enough to lend
> > > > > > > a helping hand in theory, but in practice the implementation in lavc is
> > > > > > > just too impenetrable.  h264.c is around 10.000 lines if you count svq3.c
> > > > > > > which it directly includes!
> > > > > > 
> > > > > > > 
> > > > > > > Also, our H.264 decoder is not a speed demon.
> > > > > > 
> > > > > > That seems to depend on CPU and situation, gcc making poor inlining choices
> > > > > > and overflowing the available caches is not exactly the codes fault ...
> > > > > 
> > > > > Carl Eugen was the first person I have ever heard claim that our
> > > > > H.264 decoder was faster than anything, ever...
> > > > 
> > > > Ive never tried CoreAVC, but i can assure you the reference implementation
> > > > is much much slower
> > > 
> > > You are referring to the H.264 reference implementation?
> > > 
> > > Jason mentioned two new H.264 decoders on IRC that are even faster than
> > > CoreAVC...
> > 
> > Why is this information not posted on the mailing list ?
> 
> I don't see much gain from this.  What is the news factor?  More H.264
> decoders that whip FFmpeg's ass?  Our decoder is slow, everybody knows
> this already...

I repeat to the 3rd time that i cannot work on everything and that this
information would help me and possibly reduce the amount of work it is to
improve h264.c.

Explaining why every individual detail (that you prefer me not to even know
about) is usefull to me costs time, my time, time i could spend on improving
h264.c

For this here i can explain it, for others i cannot because i am not even aware
what is said on irc about h264.c.
If someone knows that decoder X is faster than Y then he tested them on some
CPU and some file. Knowing the details of this especially if there are multiple
files tested allows one to judge which parts of our decoder are by how much
slower. That is its a hint toward what can be done better.
Also what was posted here namely a claim of our architecture being bad but
then not telling what is bad on it when i ask is extreemly hostile to ffmpeg
development.
like your doctor telling you "we have found a treatable illness that when not
treated will kill you but we wont tell you anything further"

If suggestions for improvements are submitted to our bug tracker or posted to
our mailinglist or collected at some other public place these are usefull
todo items people can work on when they have time. Just pointing out that there
is a problem but not further specifying it is useless. It can neither be
confirmed if its true at all nor can it be fixed.


> 
> > > > Also our mpeg1/2 decoder could be improved by mere throwing all non mpeg1/2
> > > > code out. i dont remember how much faster that made it but it was significant
> > > 
> > > This would likely be worthwhile.
> > > 
> > > How about making 2010 the year of performance improvements?
> > 
> > Prerequesite to that would be keeping h264 discussions where the only person
> > who works on our decoder (yeah thats me) sees them
> > 
> > Its really sad, how often do i have to repeat that i cannot do all the work
> > alone. Now if people refuse to send cleanly split patches, could they at least
> > _please_ keep their h264 discussions on ffmpeg-dev!
> 
> People just talk about whatever tickles their fancy on IRC.  

> You cannot
> make them stop.

Iam not sure what this is trying to reply to. I never asked anyone to stop
with anything they say.


>  Some people are mailing list types, others prefer IRC.
> It's just the way it is.

Thats fine, but ffmpeg development happens on the ffmpeg-dev mailing list
primarely. Discussions away from this prevent participation of a large number
of developers and harms ffmpeg. So please if a discussion happens that is
related to h264, it would be nice if this would be posted to our mailing list
or if there are privacy concerns (yeah IRC is so great secure private channel)
then post the irc log at least to the maintainer about whos code it is

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20100110/e7273eab/attachment.pgp>