On Thu, 9 Feb 2017 14:01:59 -0500 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> Hi, > > On Wed, Feb 8, 2017 at 8:21 PM, Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > On Thu, Feb 09, 2017 at 01:03:06AM +0100, Michael Niedermayer wrote: > > > On Wed, Feb 08, 2017 at 09:07:09PM -0200, Pedro Arthur wrote: > > > > 2017-01-27 1:01 GMT-02:00 Michael Niedermayer <michae...@gmx.at>: > > > > > > > > > we need more (backup) mentors, so yes, i think its needed > > > > > > > > > > also if you want to be mentor for a swscale related project i would > > > > > support that idea > > > > > > > > > > > > Hi, sorry for the late reply. > > > > I think implementing a cascade-less swscale could be a good project. > > > > If you think it is doable for a GSOC project, I'm fine with it. > > > > > > It depends on the student, it doesnt sound too complex but students > > > abilities varies alot and its quite possible there will be noone > > > interrested in any specific project > > > > > > > > > > I just doesn't know a good qualification task. > > > > > > Something which shows that the student can work with the swscale > > > codebase, not something that is just copy and paste work > > > > > > Either way, this can be added later > > > > also in absence of any other ideas, YCoCg support may be a > > qualification task. Maybe not the best choice but certainly usefull > > on its own > > > Before we get into adding new things to swscale: I will veto anything that > doesn't use the provided API in libavutil. So no new SWS_CS_*. > > And yes I'm serious about this. That should be self-evident and not an issue. Did anyone argue for it? (Also wondering if I should revive my ancient libswscale + AVFrame patch.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel