[FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

[Michael Niedermayer]

On Thu, Mar 02, 2017 at 02:37:09PM +0100, wm4 wrote:
> On Thu, 2 Mar 2017 14:03:18 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Thu, Mar 02, 2017 at 09:53:02AM +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 will push this tomorrow, except if critical failures are found.  
> > 
> > I think the patchset improved in terms of regressions but there are
> > still several
> > 
[...]
>
> > 
> > also this code crashes with some private files:
> > ==7506== Process terminating with default action of signal 11 (SIGSEGV)
> > ==7506==  Access not within mapped region at address 0x8
> > ==7506==    at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
> > ==7506==    by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> > ==7506==    by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> > ==7506==    by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> > ==7506==    by 0x43AA44: transcode_step (ffmpeg.c:4452)
> > ==7506==    by 0x43AB28: transcode (ffmpeg.c:4496)
> > ==7506==    by 0x43B2FD: main (ffmpeg.c:4701)
> 
> I don't know if you're shitting me on purpose. I can't fix what I can't
> reproduce, and you never gave me access to those files. Fix it yourself
> if you think it's important. Seriously, what is this.

I ofered access to this file to someone wanting to work on this
previously
"If this backtrace is not sufficient i can share the file privatly
 with someone who wants to work on fixing this"

Noone asked for the file, if you want to work on this and keep the file
private, i can share it with you.

Its not nice from you to ignore my ofer and then attack me pretending
there was no such offer


> 
> > This one produces a silent audio channel as previous patchsets did too
> > ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav
> 
> While libavformat signals a mono channel configuration, the decoder
> actually outputs stereo, with one channel muted. You can reproduce this
> with current master ffmpeg too by adding "-ac 2". If this is a bug,
> then it's merely an old bug that is made more obvious by this patch,
> rather than introducing it.
> 
> I don't know why you could not determine this yourself. It would have
> been easy to check.

Ive a huge amount of things to do, and analyzing differences is alot
of work, i stated that previously yet you keep attacking me, and i
tried to do some light analysis on some things to help a bit but could
not on all



> 
> > 
> > This one looses the first displayed subtitle (the green "help")
> > ./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' -qscale 2 -t 3 test.avi
> 
> The first time you mentioned this. Why didn't you do so a week ago?
> When I complained that you come up with a new case punctually at
> exactly the time when I want to merge the patches.

Well, either its new or i missed it previously.
you seem to assume i have a clean list of cases and withhold some,
thats not the case. There is no clean list to begin with and as you
asked me to spend time to investigate things a bit, i try to do so and
so i try to discard cases that appear to be duplicates
If iam wrong on one then theres a new case with the next patchset

Also id like to again ask for the attacks against me to stop.
I spend huge amounts of time in FFmpeg trying to
help but i get attacked on IRC and the ML. You realize that i just
reported some issues in a patchset ...
Its really strange, it feels like many people try really hard to push
me out of the project. And the really "hillarious" part is if i leave,
everyone of them will pretend its a surprise and they didnt see it
comming.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20170302/23803de5/attachment.sig>