On Sun, Jul 10, 2016 at 01:39:01PM -0300, James Almer wrote: > On 7/10/2016 8:36 AM, Michael Niedermayer wrote: > > On Sun, Jul 10, 2016 at 07:08:19AM -0400, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Thu, Jul 7, 2016 at 8:51 AM, Ronald S. Bultje <rsbul...@gmail.com> > >> wrote: > >> > >>> Hi, > >>> > >>> On Thu, Jul 7, 2016 at 7:38 AM, Michael Niedermayer < > >>> mich...@niedermayer.cc> wrote: > >>> > >>>> On Thu, Jul 07, 2016 at 07:14:43AM -0400, Ronald S. Bultje wrote: > >>>>> Hi, > >>>>> > >>>>> On Thu, Jul 7, 2016 at 7:07 AM, Michael Niedermayer > >>>> <mich...@niedermayer.cc> > >>>>> wrote: > >>>>> > >>>>>> On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: > >>>>>>> On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: > >>>>>> [...] > >>>>>> > >>>>>>> > >>>>>>> One other thing: why didn't this come up when the earlier patch was > >>>>>>> submitted and applied? > >>>>>> > >>>>>> community patch review is not a reproduceable process, depending on > >>>>>> who has time and does the review, different things can be found and > >>>>>> pointed out, and people have also different oppinions. > >>>>>> Real consistency can possibly only be achived by having an active > >>>>>> maintainer that does all review ... > >>>>>> > >>>>>> To be more precisse the other patch was applied due to this comment > >>>>>> IIRC: > >>>>>> "If this patch works (FATE passes on ppc64) and is faster than > >>>>>> the plain c functions then it can be committed as is" > >>>>> > >>>>> > >>>>> How much faster was it? > >>>> > >>>> There where several benchmarks posted, one is here: > >>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/196022.html > >>>> it also contains some arguments why the speedup is less than on x86 > >>> > >>> > >>> I don't think these numbers are very convincing... > >>> > >>> The arguments, on the other hand, are not facts, they are hunches, so they > >>> are essentially meaningless. > >>> > >>> I would suggest to revert the patch > >>> > >> [..] > >> > >> So, this hasn't been reverted yet, is there any particular reason why it > >> hasn't? > >> > >> Again, the speedup is practically meaningless, the code unreviewed, and it > >> will have to be rewritten by whoever finishes #5570. Can we please agree > >> reverting is the best option - and then revert? > > > > i think if you want to "mentor" this you should just do what you need > > to do to mentor this ... > > Ronald is asking for people's opinion, since reverting it without > consulting others first (especially the committer) is not nice.
as iam the commiter, if it wasnt clear already, i really have no oppinion, at least not in the form of taking any offense from any action. If anything then complete non-action in leaving this unresolved would feel offending. The part where i do have an oppinon, is incremental development, i do like incremental development, optimizing code in steps or implementing codecs stepwise in the main repository with feedback from users and collaboration of other developers. Thats how a lot of code in FFmpeg was developed. And I tend to enjoy it more to work on something in smaller steps than to sit on a growing patchset which noone really uses=tests. But thats not what we have here. The code here seems to be abadoned and there remain unawnsered questions ... It could be reverted, it could be left for the next developer to use as starting point, i have no oppinion on this. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
