[Ffmpeg-devel-irc] ffmpeg-devel.log.20191117
burek
burek at teamnet.rs
Mon Nov 18 03:05:03 EET 2019
[00:23:26 CET] <cone-769> ffmpeg 03Paul B Mahol 07master:9db24ee26ded: avfilter/vf_framepack: switch to activate
[00:23:27 CET] <cone-769> ffmpeg 03Paul B Mahol 07master:9498ce0c23b1: avfilter/vf_framepack: really fix ef466a8b29f8
[00:33:45 CET] <BtbN> What is this "has to be ref counted" stuff, why was it added, and why does ff_alloc_packet2 not do it then?
[00:35:19 CET] <BtbN> There is only very few encoders which actually use the new API, and all except one of them use ff_alloc_packet2.
[00:36:21 CET] <cone-769> ffmpeg 03Carl Eugen Hoyos 07master:eeab18329f03: lavc/libopencore-amr: Silence a warning about an unused function.
[00:53:22 CET] <BtbN> I don't understand why this even happens. ff_alloc_packet2, in libavcodec/encode.c, looks like it always returns a ref-counted packet?
[00:54:33 CET] <BtbN> It does call av_new_packet() on it, if !pkt->data
[00:54:57 CET] <BtbN> so does that mean, the packet nvenc is getting has data != NULL, but buf == NULL?
[00:55:16 CET] <BtbN> Where does it come from? receive_packet should be guaranteed to not get that.
[00:57:00 CET] <BtbN> I don't think I can just drop the encode2 callback from nvenc, which would allow me to just unconditionally call av_packet_new
[00:57:27 CET] <BtbN> Since avcodec_encode_video2 still bails out if that's the case
[01:12:54 CET] <BtbN> jamrial, regarding http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=73ee53f317418a5719f6169e6171b40f90d18321 where does the encode2 API check that?
[01:13:11 CET] <BtbN> All I can see is it checking if the user provided a packet, and if it's big enough, it copies data into it
[01:13:31 CET] <jamrial> in do_encode(), line 383
[01:13:51 CET] <BtbN> How am I supposed to correctly handle this in nvenc, which supports both APIs?
[01:14:00 CET] <jamrial> it's with avcodec_receive_packet() only, when it needs to use encode2
[01:14:19 CET] <BtbN> Since I need to be prepared for a user-provided, non-ref-counted, packet to be given to me in nvenc
[01:14:45 CET] <BtbN> Or does the logic in avcodec_encode_video2, which I don't fully understand, allow me to just always call av_net_packet?
[01:15:05 CET] <BtbN> *new
[01:16:06 CET] <BtbN> My immediate idea was to just drop encode2 support from nvenc, and call it a day. But I'm sure there will be API users being upset about that.
[01:16:25 CET] <jamrial> with avcodec_encode_video2() you need to take a potential user packet into account, so i don't think av_new_packet() can be used
[01:16:44 CET] <BtbN> nvenc.c has a shim encode2, which just calls the receive_packet function
[01:16:49 CET] <BtbN> not doing that would be... annoying
[01:17:32 CET] <BtbN> or even close to impossible without major rewriting at this point
[01:17:34 CET] <jamrial> you could check in the receive_packet function if it's being feed an user packet or not
[01:17:40 CET] <BtbN> How?
[01:18:55 CET] <BtbN> Currently it's calling ff_alloc_packet2 to alloc the packet. Which already calls av_new_packet() if pkt->data is NULL. So apparently it must be getting fed a packet where data is set, but buf is not.
[01:18:56 CET] <jamrial> check for pkt->data and/or pkt->size. avcodec_receive_packet() calling it will always be with a fresh unreffed packet, but avcodec_encode_video2() may call it with an user packet
[01:19:30 CET] <jamrial> if pkt->data is true, then use ff_alloc_packet2(), otherwise use av_new_packet()
[01:19:36 CET] <BtbN> Which is what's confusing me. Where is that input packet coming from, that does not trigger ff_alloc_packet2 to call av_new_packet?
[01:19:52 CET] <BtbN> jamrial, that's exactly what the logic _in_ ff_alloc_packet2 already does.
[01:20:38 CET] <BtbN> And it runs into that new assertion when encoding with ffmpeg.c
[01:20:42 CET] <BtbN> Which is using the new API
[01:21:04 CET] <jamrial> no, it's probably using avctx->internal->byte_buffer instead of calling av_new_packet()
[01:21:21 CET] <mkver> Maybe this packet comes from av_fast_padded_malloc in ff_alloc_packet2, lines 47-49.
[01:21:37 CET] <jamrial> try calling ff_alloc_packet2() with minsize == size
[01:22:11 CET] <jamrial> so it skips that internal buffer altogether
[01:22:37 CET] <BtbN> hm, why is that even 0. The packet is for sure not gonna be shrunk.
[01:22:40 CET] <jamrial> it should use av_new_packet() in that case
[01:24:21 CET] <BtbN> Doing that check myself actually feels cleaner, than relying on internal magic of that function.
[01:25:02 CET] <jamrial> i think i nuked all this logic in my encode api port. i don't recall if you tested it or not when i pasted a link to the repo here some months ago
[01:29:51 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/5d33a4d33034a890e907fcdb9bc93a04a8a10e0f this should fix it
[01:31:37 CET] <jamrial> yeah, that looks good
[01:32:13 CET] <BtbN> Avoid any future problems if the logic in ff_alloc_packet2 changes or something.
[01:38:00 CET] <cone-769> ffmpeg 03Timo Rothenpieler 07master:4fb6ce27f088: avcodec/nvenc: make sure newly allocated packets are refcounted
[01:38:31 CET] <BtbN> Would it make sense to backport this to at least 4.2?
[01:39:42 CET] <jamrial> if you want to
[01:39:44 CET] <jamrial> but the assert isn't there
[01:39:53 CET] <BtbN> Yes, but the assert probably was added for a reason
[01:40:04 CET] <jamrial> right :p
[01:40:23 CET] <jamrial> yeah, the encoder is returning non ref counted packets otherwise
[01:42:27 CET] <BtbN> Makes me wonder if it wouldn't make sense to just nuke that weird special case out of ff_alloc_packet2
[01:42:36 CET] <BtbN> that must make a lot of encoders return non-refcounted packetsd
[01:42:38 CET] <BtbN> -d
[01:46:30 CET] <cone-769> ffmpeg 03Timo Rothenpieler 07release/4.2:44fe41a1cae9: avcodec/nvenc: make sure newly allocated packets are refcounted
[01:54:06 CET] <cone-769> ffmpeg 03Timo Rothenpieler 07release/4.1:4df5dfabcc1c: avcodec/nvenc: make sure newly allocated packets are refcounted
[02:11:21 CET] <cone-769> ffmpeg 03Jun Zhao 07master:487e7e967003: lavf/rtmpproto: fix the playpath truncation if the len > 512
[06:37:55 CET] <cone-714> ffmpeg 03Gyan Doshi 07master:1c23abc88fef: avutil/eval: add function to track variable use
[06:39:41 CET] <cone-714> ffmpeg 03Gyan Doshi 07master:b741a84a15ae: doc/APIchanges: update for av_expr_count_vars
[12:12:45 CET] <cone-437> ffmpeg 03Paul B Mahol 07master:90622f9e8faf: avfilter/af_aecho: switch to activate
[12:39:47 CET] <cone-437> ffmpeg 03Paul B Mahol 07master:7db61bf0e3b7: avfilter/af_adeclick: fix pts handling when timebase and 1/samplerate differ
[12:39:48 CET] <cone-437> ffmpeg 03Paul B Mahol 07master:c588a0f5281f: avfilter/af_afftfilt: fix pts handling when timebase and 1/samplerate differ
[12:39:49 CET] <cone-437> ffmpeg 03Paul B Mahol 07master:115537f48759: avfilter/af_afftdn: fix pts handling when timebase and 1/samplerate differ
[12:39:50 CET] <cone-437> ffmpeg 03Paul B Mahol 07master:0a17a3015056: avfilter/af_agate: fix pts handling when timebase and 1/samplerate differ
[12:39:51 CET] <cone-437> ffmpeg 03Paul B Mahol 07master:b66acf4a3403: avfilter/af_anlmdn: fix pts handling when timebase and 1/samplerate differ
[12:49:34 CET] <durandal_1707> nice, cone-437 started to not show all commits
[14:19:00 CET] <jamrial> jkqxz: ping
[16:28:31 CET] <cone-039> ffmpeg 03Paul B Mahol 07master:2e7ccd493aec: avfilter/f_loop: fix pts handling when timebase and 1/samplerate differ
[16:28:31 CET] <cone-039> ffmpeg 03Paul B Mahol 07master:315a4496ea16: avfilter/f_loop: switch aloop to activate
[17:27:22 CET] <ubitux> it looks like ffmpeg-cvslog is has a very high spam score
[17:27:50 CET] <ubitux> http://b.pkh.me/p/2019-11-17-172743-Uuvo1bah
[17:28:01 CET] <ubitux> all the mail end up in my spam folder
[17:28:13 CET] <ubitux> it's probably not a regression (it's just that i setup a spam filter recently)
[17:28:27 CET] <ubitux> ffmpeg-devel and friends are not affected by this
[17:30:35 CET] <ubitux> i suppose this is due to videolan sending the mail instead if ffmpeg.org so the mail can't be dkim signed
[22:32:10 CET] <cone-620> ffmpeg 03Nomis101 07master:5e0a3278bb73: avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
[23:25:31 CET] <cone-620> ffmpeg 03Carl Eugen Hoyos 07master:8038a87d4956: configure: Add fft dependency for headphone filter.
[23:30:20 CET] <cone-620> ffmpeg 03Carl Eugen Hoyos 07master:ce8faea9fddb: configure: Add fft dependency for showspatial filter.
[23:44:28 CET] <cone-620> ffmpeg 03Carl Eugen Hoyos 07master:56f25c11a9e8: lavf/Makefile: Specify sln demuxer requirements.
[23:46:06 CET] <cone-620> ffmpeg 03Andreas Rheinhardt 07master:5d8d9e032caf: avformat/flacdec: Remove useless packet
[00:00:00 CET] --- Mon Nov 18 2019
More information about the Ffmpeg-devel-irc
mailing list