On 5/1/2017 3:13 PM, Marton Balint wrote: > > On Mon, 24 Apr 2017, wm4 wrote: > >> On Mon, 24 Apr 2017 21:14:15 +0200 (CEST) >> Marton Balint <c...@passwd.hu> wrote: >> >>> On Mon, 24 Apr 2017, Michael Niedermayer wrote: >>> > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote: >>> >> We have recently been able to go through six hundred or so commits >>> in a >>> >> month or two this way after being stuck for the longest time by a >>> few of >>> >> those big API changes. If we start requiring every commit to go >>> through >>> >> a review process on the ML then we will never catch up with the >>> backlog. >>> >> In short, things as they are right now are smooth. Changing it >>> will only >>> >> make this slower. > >>> > Maybe, but is merging more faster also better for FFmpeg ? >>> > I did not analyze the bugs on our bug tracker but subjectivly the >>> > number of regressions seems much larger than a year or 2 ago. >>> > and i just yesterday found 2 issues in a merge (which you fixed) >>> > >>> Yeah, I also have two I recently came across, both caused by the >>> delayed filter initialization patch: >>> >>> https://trac.ffmpeg.org/ticket/6323 >>> https://trac.ffmpeg.org/ticket/6318 >>> >>> Maybe someone more familiar with ffmpeg.c code can take a look? >> >> Currently I'm overworked, I can take a look later if you remind me. > > This is a friendly reminder :) > > Thanks, > Marton
Similarly, ticket 6227 describes a big regression introduced by this commit that i'm surprised is not reflected by any FATE test seeing that a simple "ffmpeg -i INPUT -c:v copy -c:a ENCODER OUTPUT", a very common use case, is enough to reproduce it. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel