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

[Michael Niedermayer]

On Wed, Feb 15, 2017 at 05:47:32PM +0100, wm4 wrote:
> 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?

nothing in my mail was supposed to imply that its not a group who
"supports" the patchset or that it should be only on your shoulders


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

as i said elsewhere, i have things iam more obligated to like tickets
that regressed due to a commit of mine, i need to check trac to see
how many that are, i just found and fixed one yesterday.
I in fact only realized there were such tickets when i looked at
trac to check how many regressions we have and checked a random subset
to see what commits caused these regressions.

I also have 2 outreachy students i have to help. I agreed to mentor
them. And even a bunch of mails from people who might pay me for a
random bit of FFmpeg work here or there if i would find the time.
Doing a deep analysis on every issue i spot is beyond my available time.


> 
> 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.)

I try to test all patches, iam not singling out merges at all.
For some patches its hard to identify issues though, for example
a patch intending to change the output from mov/mp4, finding which
changed output is intended and which not is harder than if no change is
intended.
Also the average commit here causes far fewer issues than cherry picking
complex patches from libav. Especially ones that were skipped
previously


[...]
> > 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

I want what is best for FFmpeg, i do not know what is best.

What i know is regressions are bad and thats why i put some effort in
finding them. No question that annoys people whom this causes extra
work.


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

yes, i try to test as many patches as i can, merges especially complex
ones seem to cause a lot more regressions which results possibly in
the impression that i single them out, i really dont

I also often skip reviewing patches when they dont built or dont pass
fate as it saves me much time.

Ill try to find more issues and not 1 per 24h for this patchset
it was more i think already
and was the result of me having the feeling the patchset wasnt ready
and once i found and reported an issue myself wanting to move on with
the long todo i have and work on the next task ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170215/610483ed/attachment.sig>