On Fri, Mar 03, 2017 at 02:30:49PM +0100, wm4 wrote: > On Fri, 3 Mar 2017 14:21:37 +0100 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > On Fri, Mar 03, 2017 at 09:53:17AM +0100, wm4 wrote: > > > On Thu, 2 Mar 2017 20:31:53 +0100 > > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > [...] > > > > > > > > You seem to do everything to slow them down. Or that's what it looked > > > like to me. > > > > I just test the code and report bugs. > > > > also this is not new, i tested the code similarly when i did the merges > > long ago ... > > > > also theres something else i keep wondering about and thats > > for example in this case here many people wanted > > this patchset and it was a gigantic amount of work you did to get it > > working and i belive others also helped and its not completely finished > > yet, users will find bugs noone of us thoight of to test for. > > Isnt it easier considering we have so many developers interrested in > > this kind of refactoring that we do this ourselfs on ffmpeg > > at some point in the future ? > > People were just going to throw hacks on it (see how the qsv and cuvid > code turned out, or what people do to get a full-hwaccel pipeline going > with ffmpeg.c).
> Libav did the work, isn't it logical to take it? absolutely yes, if it is less work for us. my question really was IF it is actually less work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
