[FFmpeg-devel] [PATCH] move h264 loopfilter strength code to yasm

[Michael Niedermayer]

On Thu, Sep 23, 2010 at 09:41:51PM -0700, Jason Garrett-Glaser wrote:
> On Thu, Sep 23, 2010 at 9:21 PM, Jason Garrett-Glaser
> <darkshikari at gmail.com> wrote:
> > On Thu, Sep 23, 2010 at 8:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> On Thu, Sep 23, 2010 at 06:13:30PM -0400, Ronald S. Bultje wrote:
> >>> Hi,
> >>>
> >>> $subj. This could likely be done in inline asm as well but I still
> >>> can't write that.
> >>
> >> can i help you to learn it?
> >>
> >>
> >>> The advantage of the approach to write it fully in
> >>> asm is to get rid of gcc doing a pretty bad job at optimizing, e.g.
> >>
> >> thats great and i dont mind
> >>
> >> the problem here is that inline ->yasm and further optimizations
> >> should be seperate patches and you yourself submitted a patch that repeats
> >> this rule, its already in the policy that patches shoudl be cleanly split.
> >> and we all know a dozen reasons why that is so.
> >
> > yasm and inline asm are different languages. ?Asking someone to port
> > code from one to the other while keeping it exactly identical is
> > stupid; it adds an enormous amount of overhead to the process. ?In
> > reality, it isn't really porting; it's rewriting, with some
> > inspiration gained from the original code.
> >
> >> So what should i do?
> >> mans, dark shikari, you and everyone else on irc do a witchhunt against
> >> inline asm
> >
> > No, we're submitting patches that improve performance and
> > compatibility. ?It just happens that these move inline asm to yasm.
> >
> > YOU ARE NOT MAINTAINING ANY OF THIS CODE. ?Therefore, you have no
> > right whatsoever to reject any of these patches.
> 
> Let me elaborate on this in a more detailed fashion.
> 
> "Maintain" is an action, not a state of being.  That is, being a
> "maintainer" means one of two things:
> 
> a) You are actively fixing and improving code.
> b) You are not working on code because there aren't any known bugs
> with it, but you're on call to work on it if issues arise.

b applies to the asm and me. i dont care about win64 and i dont think
its the job of a maintainer to change his code to work on platforms
he does not even own so cannot test.
in the past it was left to "who has that platform and cares can do the
porting within what the maintainer feels acceptable"
we arent supporting VC for that reason
if you want me to work on win64 i first would need to have a win64
system, but then its silly ronald is doing this work and iam already too
busy.
I have maintained the asm since longer than you are on any open source project
claiming i dont maintain it because i dont actively make it work on win64
feels just very hostile and ill wager a bet ronald and you wont maintain
the code for half the time i did and still do.


> 
> There are multiple known bugs in the h264 decoder, such as the fact
> that decoding is broken with threads+slices, and the fact that error
> concealment is hilariously broken with missing frames.  Personally, I
> hold myself to a very high standard regarding bugs (I try to fix them
> within hours of the report).  But even if I'm much more lenient here,
> you're hardly a maintainer: the first bug I reported a month ago,
> easily, and still haven't gotten any update beyond the original "I'm
> too busy".  The second bug I emailed the mailing list about yesterday
> and didn't even get a response.
> 
> It's fine if you don't have time to do these things.  You have a huge
> amount of work to do.  You've saddled yourself with far more than you
> have time for.  But if you don't have time to maintain H.264, don't
> try to jump into every bikeshed discussion as if you were somehow a
> maintainer.

ive spend much time with vacations in the summer holidays, and theres
a second issue that likely unconciously has caused me to ignore bugs more
than i should have. thats because a large company (NDA so i cant say who or
well i could as ive not signed it yet but iam trying to be nice)
has offered to pay me to fix issues but the paperwork is draging itself out
since about a year now. so i dont know if maybe i did ignore bugs more than
i should have due to thinking it would be wiser to fix what they need first
and get payed for it then fix what they dont care about.
but if that is so its unconscious ive not consciously ignored bugs except due
to total lack of time or lack of ability to force myself to sit and concentrate
on working on an issue

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100924/d8c4d6f2/attachment.pgp>