On Thu, 2 Mar 2017 14:03:18 +0100 Michael Niedermayer <mich...@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 > > ./ffmpeg -i ~/tickets/3015/test_video -filter:a apad -f flv -vcodec flv -ar > 22050 -shortest test.flv > > looses the audio stream This is because the test_video has an audio stream without any audio packets. The filter is never initialized, so apad can't do its work either. no audio is output, which in turn means that with the flv muxer no audio stream is created. To "fix" this you'd have to introduce a heuristic that determines that audio is starting too late, and then maybe come up with a fake format to initialize the filters anyway. This is out of scope of the merge, and it's not worth fixing anyway. > > 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. > 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. > > 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. I have to analyze this one (the only real/actionable issue in your whole post). > This one changes timebase > ./ffmpeg -i ~/fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec > mov_text -f mp4 -movflags frag_keyframe+empty_moov test.mp4 So what? If you had even bothered to read my patches, you would have noticed that some fate tests are adjusted accordingly too. The time_base gets more precise, which is not a bad thing. > Also some files still require max_muxing_queue_size to be manually set > to not fail > [libmp3lame @ 0x31dbea0] Queue input is backward in time > Too many packets buffered for output stream 0:1. > [libmp3lame @ 0x31dbea0] 5 frames left in the queue on closing > > This is worsened by the fact that the user has no hint towards this > option in the error messages > > [...] No context, can't do anything about it. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel