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 ? 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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
