[FFmpeg-devel] [PATCH v2 0/8] Merge lazy filter initialization in ffmpeg CLI

[wm4]

On Wed, 15 Feb 2017 17:17:03 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Wed, Feb 15, 2017 at 03:22:33PM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 15, 2017 at 10:24:15AM +0100, wm4 wrote:  
> > > These patches merge the previously skipped Libav commits, which made
> > > avconv lazily initialize libavfilter graphs. This means the filters
> > > are initialized with the actual output format, instead of whatever
> > > libavformat reports.
> > > 
> > > It's a prerequisite to making hardware decoding support saner, as
> > > hardware decoders will output a different pixfmt than the software
> > > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > > half of the code is removed.
> > > 
> > > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > > changes were required.
> > > 
> > > I plan to push this tomorrow, except if critical errors are found.
> > > 
> > > Anton Khirnov (4):
> > >   ffmpeg: do packet ts rescaling in write_packet()
> > >   ffmpeg: init filtergraphs only after we have a frame on each input
> > >   ffmpeg: move flushing the queued frames to configure_filtergraph()
> > >   ffmpeg: restructure sending EOF to filters
> > > 
> > > Timo Rothenpieler (2):
> > >   ffmpeg_cuvid: adapt for recent filter graph initialization changes
> > >   avcodec/cuvid: update hw_frames_ctx reference after get_format call
> > > 
> > > wm4 (2):
> > >   ffmpeg: make sure packets put into the muxing FIFO are refcounted
> > >   ffmpeg: fix printing of filter input/output names  
> > 
> > breaks: (Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1824120 >= 70020)
> > 
> > ./ffmpeg -skip_frame nokey -ss 20  -i ~/tickets/2024/dvbsubtest.ts -qscale 2  -scodec dvbsub -t 6   -an file.ts
> >   
> 
> wm4 had a quite good comment, iam replying here as i belive its a
> important matter and shouldnt disappear in a IRC log
> 
> <wm4> I don't understand why we got to fix every< obscure
> <wm4> oops
> <wm4> ...every obscure regression, but something like mp4 edit lists makes it in just fine
> <wm4> michaelni: if you don't like the merges, do it yourself
> <wm4> I'm not going to delay this because you come up with a regression every other day
> <wm4> I'm only merging, not fixing every regression this will ever cause
> 
> I understand your point very well, ive done enough merges in the past ...
> but
> who will fix the regressions ?

You're welcome to. Some merges have been group efforts, why not this
one?

What I don't want is that you post a new failing case approximately
every 24 hours, with no end in sight, and with the implication that
it's supposed to be fixed before merge. At this rate it could take
weeks, with every day following the same pattern.

Maybe you could at least maybe analyze breakages yourself before
pointing them out. That would be helpful.

Besides even regular patches can have regressions. For example, with
the edit list patches, entire files didn't decode. (Now I don't want to
single out those patches specifically - they're simply in my recent
memory.)

> In projects based on fork & merge the people doing the merge would not
> fix regressions, the authors or person making a pull request would fix
> the regressions either before merge or after through a subsequent pull
> request or patch.

I have no idea what you're talking about.

This is not a typical merge. We're dependent on merging Libav from a
"non cooperating" foreign project. It wasn't my idea either. We're
behind by over 500 commits, and there are Libav features which people
need/want to have in FFmpeg.

> In projects based on send patch and apply, the authors or patch
> submitter fixes regressions and resubmit patches or submit new patches
> if an issue is found after push.

See above. If you want to stop merges, please say so. If not, you
should probably try not to prevent them. I'm not even saying you do,
but from my perspective the way and timing you point out the regressions
is a bit unhelpful. I've seen the same happening to others when they
merged Libav commits.

It's entirely possible that I interpret your behavior as hostile, even
though it isn't. Please correct me if I'm wrong.

> Please someone correct me if iam wrong but some of these patches
> dont have an author interrested in fixing issues in FFmpeg.
> I think for such changes whoever wants that code in has to
> accept the obligations the author normally has. This is my oppinion
> not an objection or demand.

Doesn't stop you from merging regular patches from contributors who run
away later (i.e. become unresponsive).