[FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 1 May 2017 15:29:22 -0300
James Almer <jamrial at gmail.com> wrote:

> 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 <cus at 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.

Seems like Muhammad Faiz has a patch for this.

Will try to look at the other 2 issues tonight, if they're not the same
as 6227.