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

[burek]

[01:33:00 CEST] <BtbN> Using video hwaccel with the latest AMD Windows driver is a Bluescreen Minefield, holy hell.
[01:34:50 CEST] <thardin> such is the penalty for using restricting software
[02:09:20 CEST] <juandl_> Is Nicolas George here?
[02:22:15 CEST] <jamrial> juandl_: no, he doesn't use irc
[02:25:55 CEST] <cone-290> ffmpeg 03Limin Wang 07master:eccb94c3babc: lavf/hlsenc: fix one warning: unused variable 'filename' [-Wunused-variable]
[02:59:26 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:f36925201c59: lavf/hlsenc: free the old_filname to avoid memory leak
[03:23:42 CEST] <juandl_> jamrial: ah, thanks anyway
[03:46:46 CEST] <cone-290> ffmpeg 03Steven Liu 07master:939c17fcb33f: avformat/hlsenc: remove unuse comment of the code
[03:58:23 CEST] <cone-290> ffmpeg 03Steven Liu 07master:3708a2a90991: avformat/hlsenc: reindent code
[04:10:55 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:df6876d69172: lavfi/af_adeclick: fix double free after ff_filter_frame fail
[04:10:56 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:f156f4ab2317: lavfi/avfiltergraph: add check before free the format
[04:10:57 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:1b0a8e48f1d7: lavfi/dnn/dnn_backend_native: fix memory leak in error path
[06:25:58 CEST] <durandal_1707> michaelni_: vp8 is broken, see above ticket
[07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:f115a2b7635d: lavc/qsvdec: add function ff_qsv_map_picstruct()
[07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:f3dfd34f27ae: lavc/qsv: make function qsv_map_fourcc() can be called externally
[07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:00d0a4aa9eda: lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()
[07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:0dfcfc5096d7: lavc/qsvdec: remove orignal parser code since not needed now
[07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:7555cfd29b71: lavc/qsvdec: Add mjpeg decoder support
[07:39:58 CEST] <cone-422> ffmpeg 03Zhong Li 07master:655ff4708bfe: lavc/qsvdec: Add VP9 decoder support
[07:39:58 CEST] <cone-422> ffmpeg 03Zhong Li 07master:d252d1c2e987: lavfi/scale_qsv: change alignment to be 16 bytes
[08:11:42 CEST] <cone-422> ffmpeg 03Zhong Li 07master:74e6800381a2: lavfi/qsvvpp: disable pass through mode if format changed
[10:25:21 CEST] <kierank> durandal_1707: do not question important fuzzing work
[10:28:24 CEST] <thardin> please report to nearest fuzzing reeducation facility
[10:28:46 CEST] <kierank> lol
[12:09:33 CEST] <durandal_1707> cehoyos: make sure g729b is not better name than acelp.kelvin
[12:10:18 CEST] <cehoyos> G.729b is a bad name for this codec imo, or do you see any indication that G.729b has a leading byte with additional information?
[12:10:35 CEST] <cehoyos> Afaict, G.729B allows network transmission to signal silent frames
[12:10:58 CEST] <durandal_1707> consult specifications
[12:11:10 CEST] <cehoyos> That's what I did but I may have missed something
[12:11:22 CEST] <durandal_1707> have link?
[12:18:57 CEST] <cehoyos> I read something when I looked into ticket 7604 but cannot find it atm
[12:21:52 CEST] <cehoyos> To say it differently: It seems more likely to me that 7604 (where the sample contains no frame that is longer than ten bytes) is G.729B than the sample from ticket 8081
[12:22:25 CEST] <JEEB> sounds like fun formats when they can't be proper discerned from each other :/
[12:22:28 CEST] <JEEB> *properly
[12:22:42 CEST] <cehoyos> The TwoCC does not claim G.729B, only the dll
[12:22:51 CEST] <cehoyos> The TwoCC entry does not claim G.729B, only the dll
[12:23:01 CEST] <cehoyos> Maybe the dll can do both..
[12:23:32 CEST] <cehoyos> And maybe the leading byte can also signal silence
[12:24:52 CEST] <cehoyos> https://tools.ietf.org/html/rfc3551#section-4.5.6 clearly speaks of "two octets" to signal silence
[12:32:40 CEST] <durandal_1707> wrong specs
[12:44:04 CEST] <durandal_1707> https://www.itu.int/rec/T-REC-G.729
[12:48:33 CEST] <cehoyos> Does it specify eleven-byte frames for G.729B?
[12:49:37 CEST] <durandal_1707> im on phone cant look
[14:16:11 CEST] <durandal_1707> cehoyos: name is ok
[14:16:22 CEST] <cehoyos> Thank you
[14:29:38 CEST] <durandal_1707> please, someone apply v360 set from me!
[15:19:03 CEST] <durandal_1707> cehoyos: how can it hurt FFmpeg?
[15:21:56 CEST] <durandal_1707> cuurently it never returns last frame
[15:22:08 CEST] <durandal_1707> for vfr
[15:22:27 CEST] <durandal_1707> eg case when last frames are same
[15:29:33 CEST] <Heisenberg> Hi ! I want to design a system in which a video is streamed under a given condition determined in a bsf filter, how could I drop packets (filtered as non relevant) and still be able to decode the non filtered packets at the receiver ? (H.264 videos and using the ffmpeg streaming feature)
[15:38:16 CEST] <J_Darnley> So you want to do 2 actions with incomping packets, right?
[15:38:38 CEST] <J_Darnley> Filter and retransmit?  And decode?
[15:40:20 CEST] <kierank> stream under a given condition
[15:40:23 CEST] <kierank> what does that mean
[15:41:00 CEST] <Heisenberg> The bsf  would only filter the relevant packets and I would stream or save to a file the outgoing stream. The issue is about "not dropping necessary infromations for decoding" so being able to play the video at the end.
[15:41:54 CEST] <Heisenberg> A condition that I would implement like "if motion" -> stream it otherwise -> save bandwidth
[15:43:59 CEST] <nevcairiel> with complex codecs like h264, its not necessarily that easy to just drop arbitrary packets just because nothing changes - unless you encode it in a particular (less efficient) way. On the other hand, if you encode it very efficient, then the  bandwidth during times of no motion would be extremely small anyway
[15:50:58 CEST] <Heisenberg> That is what I tried to do even if it is less efficient : defining a specific fps and gop so that I am sure to include the corresponding key frame when transmitting any predicted frame, so the packets would not really be drop arbitrary but "gop by gop"
[16:28:38 CEST] <J_Darnley> Am I going to have to install wine just to use HxD?
[16:28:50 CEST] <J_Darnley> Why isn't there a good hex editor on linux?
[16:29:22 CEST] <JEEB> bless is the one I utilized, but I didn't like it as much as HxD :<
[16:29:36 CEST] <JEEB> there's some payware one, but I've not tested it on lunix
[16:32:52 CEST] <J_Darnley> I've just tried ghex
[16:33:08 CEST] <J_Darnley> I made a selection to delete some bytes
[16:33:14 CEST] <J_Darnley> and it deleted 1
[16:33:19 CEST] <J_Darnley> 1!
[16:33:39 CEST] <J_Darnley> Not thw whole selection, the 1 byte I ended the selection at
[16:34:12 CEST] <durandal_1707> pay more
[16:34:23 CEST] <J_Darnley> Maybe I should
[16:34:38 CEST] <J_Darnley> Do you have a recommendation?
[16:38:40 CEST] <durandal_1707> my software i have yet to write :)
[16:38:56 CEST] <J_Darnley> :)
[16:39:37 CEST] <J_Darnley> I will add: no electron
[16:41:55 CEST] <BtbN> KDE has a nice Hex Editor iirc
[16:45:26 CEST] <kierank> J_Darnley: i used to use bless
[16:46:18 CEST] <durandal_1707> KDE ?
[16:46:55 CEST] <JEEB> khex was it?
[16:47:06 CEST] <durandal_1707> i think you could use radare2
[16:48:08 CEST] <kierank> durandal_1707: never managed to use that thing
[16:48:21 CEST] <J_Darnley> I tried it once too and was in way over my head.
[16:49:30 CEST] <durandal_1707> you just use visual modr
[16:49:39 CEST] <durandal_1707> *mode
[16:50:14 CEST] <durandal_1707> its little more complicated than vi/vim
[16:52:27 CEST] <durandal_1707> once you learn basics you starting to be excelent in it, not for simple minded people
[16:53:01 CEST] <kierank> too complex for J_Darnley, he is simple man :)
[16:53:18 CEST] <J_Darnley> Indeed.  Basic vim usage is my limit.
[16:53:19 CEST] <kierank> he likes beer and guns
[16:53:28 CEST] <J_Darnley> *cider and guns
[16:53:44 CEST] <durandal_1707> gums*
[17:45:25 CEST] <BtbN> https://www.reddit.com/r/Amd/comments/cqfdm8/psa_adrenaline_1981_has_bsod_for_many_5700xt_users/ hrm, "fun"
[18:49:09 CEST] <durandal_1707> kierank: please if you can apply my v360 set
[18:53:20 CEST] <kierank> Later yes
[18:55:36 CEST] <durandal_1707> is lego saturn finished?
[19:11:22 CEST] <durandal_1707> here is more music for your fuzz fest: https://m.soundcloud.com/fuzz-me/overgame
[19:17:59 CEST] <durandal_1707> https://www.usenix.org/conference/usenixsecurity19/presentation/jung
[19:18:19 CEST] <durandal_1707> here you can learn how to beat fuzzer
[19:38:37 CEST] <durandal_1707> michealni: you are a truly dictator, your way or no way at all
[19:53:04 CEST] <BradleyS> "please report to nearest fuzzing reeducation facility"
[19:53:10 CEST] Action: BradleyS gives thardin a cookie
[19:55:22 CEST] Action: durandal_1707 gives a fuzz
[20:42:53 CEST] <thardin> :]
[22:09:26 CEST] <durandal_1707> kierank: when to expect it?
[22:11:43 CEST] <kierank> Have to eat dinner
[22:11:48 CEST] <kierank> Was in pub
[22:13:49 CEST] <kierank> durandal_1707: seems Michaelni has sent me what he would call an "ad-hominem"
[22:15:00 CEST] <durandal_1707> that reply or private one?
[22:16:10 CEST] <kierank> public reply
[22:17:58 CEST] <durandal_1707> it happens to the best, even with good intentions
[22:18:17 CEST] <kierank> I replied
[22:18:37 CEST] <durandal_1707> never reply
[22:19:28 CEST] <kierank> yes I know, it's playing into michaelni_ game
[22:19:34 CEST] <kierank> where he argues you all the way so you give up
[22:19:37 CEST] <kierank> same with nicolas
[22:20:09 CEST] <kierank> but arguments for frame doubling are not comparable to dropping frames that fuzzed files decide not to decode
[22:24:08 CEST] <durandal_1707> it breaks final frame... amd appears to have more cases in codebase
[22:26:02 CEST] <durandal_1707> this is for timeout which was not even measured
[22:27:31 CEST] <durandal_1707> and still fuzzer should use reference counting, but im afraid that would kill most of highly valuable work over timeouts
[22:33:28 CEST] <kierank> Yes my concern is breaking other codecs, slippery slope
[22:40:48 CEST] <jamrial> i thought there was a patch to reintroduce the final frame dropped by accident?
[22:44:18 CEST] <jamrial> durandal_1707: re refcounting, avcodec_send_packet() ensures it's refcounted internally, before it gets to the decoder
[22:44:21 CEST] <jamrial> why would it matter what target_dec_fuzzer.c does?
[22:58:05 CEST] <kierank> durandal_1707: is urgent to push patch
[22:59:02 CEST] <durandal_1707> why?
[22:59:18 CEST] <kierank> i might sleep
[22:59:33 CEST] <durandal_1707> go play with lego? :)
[22:59:40 CEST] <thardin> maybe I've been foolish in planting the idea that one could do smart things when identical frames are output
[22:59:49 CEST] <thardin> instead of the stupid and simple thing
[23:00:47 CEST] <durandal_1707> kierank: fuzz is more urgent
[23:00:50 CEST] <kierank> durandal_1707: go watch japanese cartoons
[23:01:19 CEST] <durandal_1707> will i
[23:02:16 CEST] <thardin> ah right repeat_pict already exists
[23:04:13 CEST] <thardin> but only works if you know the picture repeats in advance
[23:04:49 CEST] <jamrial> so as kierank said, based on metadata coded into the bitstream
[23:05:33 CEST] <BtbN> Am I missing the issue at hand, or could a decoder keep a refernece to the buffer of the last frame it returned, and re-use it when it's a duplicate? That way it's still cfr, but avoid the memory allocation bomb.
[23:06:30 CEST] <thardin> that's what cinepak ends up doing at least
[23:07:09 CEST] <jamrial> and what ff_reget_buffer is for, afaik
[23:07:18 CEST] <thardin> turn on references, decoding speeds up ~1000x on fuzzed input
[23:07:53 CEST] <BtbN> Oh, so the issue is that the fuzzer does not use refcounting, and thus will get a copy made no matter what?
[23:08:01 CEST] <thardin> yes
[23:08:12 CEST] <thardin> and michael thinks this is an  issue for some reasoon
[23:08:15 CEST] <BtbN> That's pretty dumb
[23:08:25 CEST] <thardin> so every decoder then needs ugly checks to bail out early
[23:08:33 CEST] <BtbN> We should deprecate and discourage non-ref-counted frames more aggressively
[23:08:43 CEST] <thardin> but of course you can make files that avoid those checks and still decode to an identical frame
[23:09:40 CEST] <thardin> I think in theory at least it could be useful to signal that a frame didn't change. then users can turn cfr into vfr if they wish
[23:10:04 CEST] <BtbN> Can it even detect those cases?
[23:10:15 CEST] <thardin> I'd like to see someone actually wanting  that first, instead of coding  for theoretical use cases
[23:10:20 CEST] <thardin> BtbN: for meny codecs you can
[23:10:40 CEST] <thardin> fli, gif, cinepak at least. I think all the mpeg codecs have stuff for that too
[23:10:47 CEST] <BtbN> I mean, sure you can detect a clear duplicated frame. But if it's specifically crafted to not appear duplicated, but decode to the same data nevertheless?
[23:11:09 CEST] <thardin> yeah
[23:11:53 CEST] <thardin> I think we should have an actual use case, preferably some free software project. else it's probably a waste of effort
[23:21:45 CEST] <thardin> uhm this "sane number of channels" thing feels quite arbitrary
[23:23:08 CEST] <thardin> I've used .wav to store radio IQ data at a few MHz, and it could certainly be used to transport channelized data at similar rates
[23:23:28 CEST] <thardin> with many many channels
[23:31:37 CEST] <jamrial> durandal_1707, BtbN, thardin: so making target_dec_fuzzer.c refcount its packets before passing them to libavcodec in its loop would help with these timeouts
[23:32:15 CEST] <BtbN> non-refcounted frames are deprecated, right?
[23:32:34 CEST] <jamrial> yeah
[23:32:36 CEST] <BtbN> So fuzzing them seems like a waste of time. Not like there is nothing else to work on.
[23:33:11 CEST] <BtbN> Specially with how many things it reports, and what a mess it potentialy makes all over the whole codebase...
[23:33:17 CEST] <jamrial> ok, will try to implement that
[23:33:43 CEST] <jamrial> if it makes bogus timeout reports disappear and helps people calm down, i'm for it
[23:33:59 CEST] <BtbN> Why is it even NOT doing that? Just an oversight, or is it intentional?
[23:34:38 CEST] <thardin> michael wrote something about wanting to simulate what a user program would do
[23:34:47 CEST] <thardin> like that user programs will process the frames
[23:34:53 CEST] <jamrial> it's using the old decode api, which accepts non refcounted packets, despite being discouraged
[23:34:59 CEST] <thardin> but that doesn't help us make lavc nice and fast
[23:35:36 CEST] <thardin> I'd be in favor of using refcounting only in that fuzzing program
[23:36:07 CEST] <thardin> and maybe revert or at least look over all these timeout patches to see if they still timeout with refcounting enabled
[23:38:03 CEST] <BtbN> The other big issue with fuzzing is how every single thing it reports is treated as security bug, and thus only handled by a very small circle of people.
[23:38:10 CEST] <thardin> it certainly doesn't make sense trying to optimize for the older api
[23:38:25 CEST] <BtbN> imo it should be separated from the security list, and get its own, more accessible or even public list
[23:41:09 CEST] <jamrial> BtbN: lotharkript offered to do that, i think
[23:41:41 CEST] <thardin> some timeouts are a bit more important tho, like in lavf since that would make ffprobe slow
[23:42:27 CEST] <BtbN> Sure, there will still be timeouts, and a lot of them will be valid issues. But eliminating a whole class of timeouts that are not actual issues
[23:42:37 CEST] <lotharkript> jamrial: i'm ok to make the bugs closes only for Security, but some timeout could be a infinite loop. In this case, every one will see it.
[23:43:38 CEST] <lotharkript> but if there is something to chang ein the target_dec_fuzzer.c to make most timeout gone, please do
[23:44:07 CEST] <thardin> the class of "oh if I make a 65000x1000 file then it takes time to process!" is definitely silly
[23:45:45 CEST] <lotharkript> should we have then per codec a max resolution and/or max pixel per frame?
[23:45:52 CEST] <lotharkript> so we can abort faster?
[23:46:05 CEST] <thardin> a max resolution in the ffmpeg cli could be useful
[23:47:21 CEST] <thardin> say if a stream changes resolutions, which is something ffprobe wouldn't catch
[23:48:32 CEST] <jamrial> the fuzzer already sets 16mp as max frame size
[23:52:02 CEST] <BtbN> An infinite loop should be somewhat easy to detect though, shouldn't it?
[23:52:10 CEST] <BtbN> Compared to a two or ten second slowdown
[23:52:55 CEST] <BtbN> I can see a point in not making all the fuzzing results public, same as it is with the static analysis ones.
[23:53:27 CEST] <BtbN> It should be more like coverity, where everyone who is known gets access easily.
[23:57:51 CEST] <BtbN> Speaking about Static Analysis. michaelni_, can you cancel the "current" builds analysy? It's been stuck for a while now again.
[00:00:00 CEST] --- Wed Aug 21 2019