[FFmpeg-devel] [PATCH v2 0/8] Merge lazy filter initialization in ffmpeg CLI
michael at niedermayer.cc
Wed Feb 15 18:17:03 EET 2017
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> ...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 ...
who will fix the regressions ?
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.
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.
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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel