[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

Rather tricky to fix, so I didn't. The problem is that the filter graph
remains unconfigured, so it can't know about unconnected outputs. It
remains unconfigured because the first input file is connected to two
filters (one trivial that keeps shuffling input to the output file, and
one connected to the unconfigured graph). To get the graph configured,
the second input file would have to decode 1 frame - this doesn't
happen because there's nothing in ffmpeg.c scheduling that would make
the second input file produce output.

The scheduling should be fixed. In theory it would be best to move the
input "duplication" (single input to several filter inputs) into
libavfilter, and make libavfilter do proper data flow that blocks
instead of queuing up frames until OOM.

but I'm not sure how to do that, so I posted a hacky fix for it that
checks for unconnected outputs on start, instead of in the old place.

> >>> https://trac.ffmpeg.org/ticket/6318

Works here, I suspect it was the same as one of the other issues that
was fixed recently.

> >>>
> >>> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel