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

wm4 nfxjfg at googlemail.com
Fri Mar 3 10:53:17 EET 2017


On Thu, 2 Mar 2017 20:31:53 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Mar 02, 2017 at 06:27:29PM +0100, wm4 wrote:
> > On Thu, 2 Mar 2017 17:12:04 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > 
> > > 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
> > 
> > OK, I missed that part. Sorry. I guess I overlooked it when I tried to
> > collect all the new test cases and tried to find the required samples
> > (for which you only provided a path on your local disk, and I had to
> > look them up from the ticker number in that path). So I apologize, but
> > I'm still grumpy.
> > 
> > Anyway, _please_ don't report bugs to me in the future without providing
> > a direct sample link (sure, you can do it privately if necessary).
> > 
> 
> > In the mean time, I somehow expected you'd provide me a sample for the
> > case above (in private), since you know that I obviously want and don't
> > have it, but you didn't yet. Why make me ask.
> 
> because i have no permission to share the file unless its neccessary.

Well, you either report it and share the sample, or you don't report
it. Sometimes it's possible to guess the bug from a backtrace, but
usually it's not enough. Maybe some consideration?

> 
> > 
> > Btw., I've tested every single case you pointed out and which I could
> > test.
> 
> you missed one case it seems
> ./ffmpeg -skip_frame nokey -ss 20  -i ~/tickets/2024/dvbsubtest.ts -qscale 2  -scodec dvbsub -t 6   -an file.ts
> 
> displays fewer subtitles than before the patchset, i did report this
> case previously

No, your original complaint about this was fixed. After it was fixed,
another issue appeared, but I first decided to ignore it because it
happened only with -skip_frame (i.e. obscure close to nonsensical
corner case).

I've looked at it again anyway this morning. It was caused by a DVB sub
special case in ffmpeg.c that hardcoded the target container's timebase
to 1/90000 (originally added by Fabrice Bellard over a decade ago).
This was overlooked by the original Libav patch author. It works now.

> 
> > 
> > > 
> > > >   
> > > > > 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 is not the first time you're implying that your time is somehow
> > more valuable than mine.
> 
> iam not implying that.
> what iam implying is that if a person or group wants something its
> theirs to do the work. Thats especially true in FLOSS
> you seem to expect me to also want to work on the same things you
> want to work on.

Again, merges are a group effort, and by their nature they're different
from normal contributions. When you did the merges, "whatever" was fine
to get it done too.

You seem to do everything to slow them down. Or that's what it looked
like to me.

Anyway, I've pushed the patches now, with some local modifications.
I've had this sitting on my mind for 3 weeks or so, and now someone
wants to get my push rights revoked, so I'll leave it to others to fix
the final regressions. Sorry to sound like a dick again, but I'm done
here.


More information about the ffmpeg-devel mailing list