On Mon, 1 May 2017 15:29:22 -0300 James Almer <jamr...@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 <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 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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
