[Ffmpeg-devel-irc] ffmpeg-devel.log.20170420

[burek]

[00:49:28 CEST] <philipl> wm4: I can look this weekend but hopefully BtbN can look at cuvid first.
[00:51:04 CEST] <philipl> crystalhd will fail with any emulation code, I'm sure. I need to add some blocking code.
[02:50:17 CEST] <cone-122> ffmpeg 03Michael Niedermayer 07master:88612f8db3b8: avfilter/af_compand: Check av_strtok() for failure
[04:45:28 CEST] <cone-122> ffmpeg 03James Almer 07master:0f05f2c7e679: avcodec/aac_adtstoasc: fix ASC passthrough on small frames
[10:28:22 CEST] <BtbN> philipl, hm? What's broken?
[10:59:52 CEST] <wm4> BtbN: we're merging a Libav commit that changes the internal API for the new decode API
[11:00:38 CEST] <wm4> and it affects cuvid
[11:00:50 CEST] <wm4> https://github.com/jamrial/FFmpeg/tree/mergework
[11:10:45 CEST] <nevcairiel> i cant say i'm a fan of that change
[11:10:59 CEST] <wm4> how come
[11:11:08 CEST] <wm4> I welcome the decoding bsf stuff
[11:12:25 CEST] <nevcairiel> the bsf seems unrelated to the api change
[11:15:10 CEST] <wm4> well elenril claimed that it made things easier on both sides
[16:43:48 CEST] <BtbN> wm4, is there any doc on what exactly changed?
[16:45:44 CEST] <wm4> BtbN: lol no
[16:45:52 CEST] <BtbN> great
[16:46:02 CEST] <wm4> basically the send_packet callback was removed
[16:46:17 CEST] <wm4> and instead you call a ff_get_packet (or something like this) function in receive_frame
[16:46:32 CEST] <BtbN> That's weird
[16:46:38 CEST] <BtbN> and not a trivial change
[16:48:06 CEST] <wm4> not too trivial, but still simple
[16:48:15 CEST] <wm4> jamrial's branch should include a fix for cuvid
[16:48:33 CEST] <BtbN> Yeah, but that fix looks like it gets one input packet per output frame
[16:48:38 CEST] <BtbN> which makes cuvid go horribly slow
[16:49:10 CEST] <wm4> does it?
[16:58:29 CEST] <nevcairiel> you can call it as often as you want, and generate output as often as you need
[18:10:54 CEST] <Mista_D> Is that supoposed to take longer: "-ss $t -i $file" VS. "-ss $t -f concat -i $file.concat" ? Wondering why is seeking much slower with concat
[18:12:53 CEST] <RiCON> maybe concat uses the slower seek as in "-i $file -ss $t"
[18:16:58 CEST] <cone-797> ffmpeg 03Derek Buitenhuis 07master:cbd3a68f3e1c: avformat/webmdashenc: Require the 'adaptation_sets' option to be set
[18:16:58 CEST] <cone-797> ffmpeg 03Derek Buitenhuis 07master:ec07efa70012: avformat/webmdashenc: Validate the 'streams' adaptation sets parameter
[18:28:39 CEST] <alevinsn> Not sure if anyone is here, but I was getting tired of debugging optimized builds, so I took the _dce.c files that Matt Oliver submitted recently to the ml
[18:29:05 CEST] <alevinsn> Enabled a new config option, opt_disabled, which is only enabled if --disable-optimizations is turned on
[18:29:33 CEST] <alevinsn> and adjusted the Makefiles to add OBJS-{CONFIG_OPTS_DISABLED} appropriately
[18:29:38 CEST] <alevinsn> and I've gotten that to build
[18:29:42 CEST] <nevcairiel> Just add a pragma to the file you are working on, much less effort then keeping some hacky patch alive forever
[18:30:01 CEST] <alevinsn> you don't always know what files you want
[18:30:08 CEST] <alevinsn> if I'm using the libraries
[18:30:18 CEST] <alevinsn> I like to be able to step through the code of av_ functions I call
[18:30:46 CEST] <nevcairiel> I know, but I have also worked with the code for years
[18:30:47 CEST] <alevinsn> so, adding pragmas isn't really practical in that case
[18:31:07 CEST] <alevinsn> if it is only used in the case that --disable-optimizations is enabled, what is the harm?
[18:32:34 CEST] <nevcairiel> You are free to use anything locally, but upstream such ugly hacks are even unlikelier to get in then removing the DCE reliance
[18:36:11 CEST] <alevinsn> separate question:  in ffmpeg.c, it appears to handle video and audio output processing from the same thread
[18:36:18 CEST] <alevinsn> this appears to be done in reap_filters()
[18:36:35 CEST] <alevinsn> where it calls do_audio_out() and do_video_out() from the same function
[18:36:57 CEST] <alevinsn> is the reason why this is done because, among other things, that aspect of ffmpeg isn't thread-safe?
[18:37:33 CEST] <alevinsn> for example, it seems like it might not be safe to call av_interleaved_write_frame() from separate threads at the same time
[18:37:44 CEST] <alevinsn> maybe--I'm not certain of this
[18:38:50 CEST] <nevcairiel> Muxing is not thread safe, however a mutex around that would potentially solve that
[18:40:03 CEST] <nevcairiel> But there would also be quite some complexity involved to sync everything up properly so noone might have dared
[18:47:38 CEST] <alevinsn> ok, that makes sense.  I'm probably butchering this, but from looking at reap_filters()
[18:48:02 CEST] <alevinsn> I would guess that new encoded frames are delivered to the filters/buffer sinks
[18:48:09 CEST] <alevinsn> potentially by multiple threads
[18:48:23 CEST] <alevinsn> and then muxing happens on a single thread
[18:48:47 CEST] <alevinsn> is that a reasonably correct statement?
[18:49:06 CEST] <alevinsn> not necessarily encoded
[18:49:14 CEST] <alevinsn> but input frames
[20:24:06 CEST] <alevinsn> nevcairiel:  still there by chance?
[20:24:10 CEST] <alevinsn> still here I mean
[22:56:23 CEST] <cone-202> ffmpeg 03Paul B Mahol 07master:74acc1eec582: avfilter: add deflicker filter
[23:31:30 CEST] <llogan> durandal_1707: mind if i add that the size option in deflicker is in frames? i wanted to mention it yesterday before you pushed but forgot to do so.
[23:32:23 CEST] <durandal_1707> llogan: no , go ahead
[23:51:43 CEST] <jamrial> wm4, ubitux: fixed the bug i mentioned about this badly cut mpegts video and pushed a new version to my repo. should be a matter of getting crystalhd working now
[23:54:48 CEST] <cone-202> ffmpeg 03Lou Logan 07master:0b8c159a9391: doc/filters: deflicker size option value is in frames
[00:00:00 CEST] --- Fri Apr 21 2017