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

[burek]

[00:44:16 CEST] <kierank> durandal_1707: it's not hack
[00:44:25 CEST] <kierank> same way ffmpeg don't support all the drc and loudness stuff in ac3
[00:44:27 CEST] <kierank> it matters in real world
[00:44:34 CEST] <kierank> but not in neckbeard players like mplayer
[00:47:59 CEST] <durandal_1707> lies
[00:56:39 CEST] <BradleyS> HandBrake does, feel free to borrow code but it's probably GPL 2.0
[00:57:24 CEST] <BradleyS> i forget what in ffmpeg is lgpl
[00:59:17 CEST] <jamrial> everything except some ancient filters
[01:13:18 CEST] <J_Darnley> I think I have some flac assembly under gpl
[01:20:44 CEST] <cehoyos> Correct
[01:33:20 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:cf3ca3363a84: LICENSE: Fix path to libswresample test file.
[01:42:05 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:8abbe717f847: LICENSE: Remove a file that does not exist anymore.
[01:47:38 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:9fdc7f1b0390: LICENSE: Add missing filters licensed under the GPL.
[01:51:29 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:00aa096202ce: LICENSE: Clarify that lensfun is GPLv3+.
[01:56:51 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:02c0268d5c0f: LICENSE: Update list of GPLv2 libraries.
[02:27:13 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:aecf5cbd6802: LICENSE: Add missing libraries that need --enable-version3.
[08:46:53 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:cd460f4da04c: avcodec/hnm4video: Optimize postprocess_current_frame()
[08:46:53 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:9e0e9a5f3619: tools/target_dec_fuzzer: Limit number off all pixels decoded
[09:00:22 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:faa9cd312f02: tools/target_dec_fuzzer: Add missing breaks
[11:15:09 CEST] <atbd> hi, i'm currently adding EPG support to libavformat/mpegts. For now, i succeed to packetize them in AVPacket. But i'd like to know if i can export a simplified struct to read them (EPGEvent struct) or do i need to export them through AVFrame sidedata or metadata ? Having a specialized struct to interact with users would also simplified writing EPG data 
[11:15:37 CEST] <atbd> If I can make it available where do I can put it ?
[11:45:56 CEST] <Lynne> side data.
[11:59:50 CEST] <atbd> okay thanks. Can I put the struct in libavutil like others describing sidedata ?
[12:02:07 CEST] <Lynne> yes
[12:02:42 CEST] <atbd> cool, ty !
[14:52:10 CEST] <durandal_1707> michaelni: if you do not reply i wil nak every single of your patches!
[14:56:23 CEST] <kierank> durandal_1707: lol maybe michaelni blocked you
[16:25:07 CEST] <ubitux> https://picsum.photos/
[16:25:30 CEST] <ubitux> didn't know that; can be useful to get (picture) sample for specific filters
[16:28:02 CEST] <ubitux> mmh, looks like it's artificial filters; i was under the impression it was querying random pictures with special properties
[16:28:09 CEST] <ubitux> i guess it's less useful then
[16:41:48 CEST] <durandal_1707> michaelni please answer me
[16:49:56 CEST] <durandal_1707> you are living proof that ffmpeg is just organization under your dictatorship
[16:49:59 CEST] <nevcairiel> you sound like a whiny child, get yourself together, not everyone sits on irc 24/7
[16:51:43 CEST] <durandal_1707> why you tolerate michaelni dictatorship, you two share something in common?
[17:00:50 CEST] <durandal_1707> im calling out for exraordinary ffmpeg meeting!
[17:03:03 CEST] <durandal_1707> 1. topic is: michael unresponsive behaviour
[17:06:26 CEST] <Lynne> "fixing" timeouts in one fuzzed paintbrush pcx file is more important than responding
[17:06:38 CEST] <Lynne> as we speak thousands of bad people are sending youtube that one file causing their servers to cry because it decodes 2s slower than it could
[17:12:48 CEST] <durandal_1707> its shame
[17:30:08 CEST] <durandal_1707> i should switch to Libav...
[17:32:29 CEST] <bencoh> >_>
[17:34:39 CEST] <nevcairiel> even better make your own fork!
[17:40:42 CEST] <durandal_1707> you clearly can not tolerate my presence, so why should i listen to you?
[17:45:16 CEST] <jamrial> durandal_1707: please, calm down
[18:13:24 CEST] <durandal_1707> i hereby relicense all my code to AGPL. please comply with this or i will be forced to remove all my contributions
[18:15:33 CEST] <nevcairiel> good luck with that
[18:16:46 CEST] <BtbN> Is CC extraction even the job of the hardware decoder? Or should the common h264 parsing code do it?
[18:22:53 CEST] <kierank> BtbN: decoder
[18:23:00 CEST] <kierank> Need reordering
[18:23:07 CEST] <kierank> Ergo it's a decoder problem
[18:23:25 CEST] <BtbN> So a53 CCs are broken on all native hwaccels?
[18:23:31 CEST] <kierank> Hardware decoders are useless anyway
[18:23:50 CEST] <kierank> Decoding h264 is fast and easy
[18:24:08 CEST] <BtbN> Firefox and Twitch stats disagree
[18:24:19 CEST] <BtbN> majority of peoples CPUs are too slow to decode 1080p60
[18:27:16 CEST] <durandal_1707> michaelni:  i did not ask if you need help, i requested subscription. please comply.
[18:28:39 CEST] <durandal_1707> but CC needs to be displayed by law
[18:40:52 CEST] <kierank> BtbN: probably single threaded or otherwise crap decoding pipelinr
[18:41:04 CEST] <kierank> I can decode that in CPU on some 50 dollar sbc
[18:41:17 CEST] <BtbN> You underestimate how ship some peoples CPUs are
[18:41:20 CEST] <BtbN> *shit
[18:41:42 CEST] <BtbN> And even if the CPU can do it, it's a waste of resources and energy, cause the hwdec can do it way more efficiently
[18:41:50 CEST] <durandal_1707> everyone use potatoes as computers
[18:42:52 CEST] <kierank> Can't do 4:2:2 or 10-bit
[18:43:07 CEST] <kierank> Or closed captions
[18:43:08 CEST] <kierank> Or afd
[18:43:17 CEST] <kierank> Or other things needed to watch correctly
[18:43:32 CEST] <BtbN> a53 cc are not the job of the hardware
[18:43:44 CEST] <durandal_1707> its blackbox
[18:45:21 CEST] <nevcairiel> the native hwaccels should do stuff like CC or AFD just fine, since they behave much like a software decoder and only send s lices to the hardware
[18:45:31 CEST] <nevcairiel> at least how ffmpeg builds them
[18:45:33 CEST] <kierank> BtbN: it's the job of the hardware to reorder
[18:45:42 CEST] <nevcairiel> not in ffmpeg, no
[18:45:45 CEST] <BtbN> no it's not, ffmpegs parsers do it
[18:45:51 CEST] <nevcairiel> we only decode slices with hardware
[18:45:55 CEST] <nevcairiel> litereally anything else is software
[18:46:16 CEST] <kierank> For all hardware?
[18:46:39 CEST] <nevcairiel> for all that exposes that capability
[18:46:51 CEST] <nevcairiel> which at least covers the one we were talking about regarding that issue
[18:47:02 CEST] <kierank> Ok
[18:47:18 CEST] <BtbN> I'd be very surprised if CCs are generally broken on all hwdecs. But I'd also be confused if it's only broken on nvdec, cause... how?
[18:48:38 CEST] <nevcairiel> the ticket looks like he uses cuvid though
[18:48:39 CEST] <nevcairiel> not nvdec
[18:48:42 CEST] <nevcairiel> so there is your answer
[18:50:09 CEST] <kierank> durandal_1707: you have answer from michaelni
[18:51:15 CEST] <durandal_1707> 2nd one? 1st one i already read and replied here
[18:56:10 CEST] <kierank> durandal_1707: reply on ml
[19:00:31 CEST] <BtbN> hm, with the CUDA filters being freed now, I'd very inclined to officially slap a deprecated sign on cuvid
[19:01:39 CEST] <BtbN> Only thing missing for full feature parity is vf_transpose_cuda, which I might find time too look into the next couple days
[19:02:15 CEST] <BtbN> hm, and vf_crop_cuda I guess
[19:02:23 CEST] <durandal_1707> write hw pad filter instead
[19:03:39 CEST] <BtbN> Could just write one filter that exposes both the crop and the pad interface
[19:17:41 CEST] <durandal_1707> anybody happy with my sierpinski video source?
[19:21:15 CEST] <durandal_1707> be honest,  stop hiding your feelings
[19:22:10 CEST] <BtbN> sierpinski as in the fractal?
[19:23:46 CEST] <durandal_1707> sierpinski carpet fractal
[19:24:18 CEST] <BtbN> That seems like a decent video encoder test pattern
[19:25:10 CEST] <durandal_1707> how so? its useless, i write only useless stuff
[19:25:57 CEST] <BtbN> Hm? It's seemingly "random" tons of moving stuff. As compared to the other static test sources.
[19:26:03 CEST] <BtbN> While not being white noise
[19:26:55 CEST] <durandal_1707> i need to add colors and little of panning
[19:27:13 CEST] <durandal_1707> it already have zoom
[19:29:12 CEST] <Lynne> anything with sharp edges is a good encoder test pattern, unless you're av1 or vp9, then you deny their existance
[20:01:11 CEST] <BtbN> I do not undestand what that guy is saying.
[20:09:36 CEST] <nevcairiel> apparently its slower
[20:12:02 CEST] <nevcairiel> probably needs to set the hwaccel output format?
[21:36:52 CEST] <durandal_1707> typical ffmpeg developer behavior: https://youtu.be/U1FxfR3lg6Q
[21:47:26 CEST] <Compn> durandal_1707,  then ask on the ml to get security access with a vote
[21:47:29 CEST] <Compn> like always
[21:48:11 CEST] <Compn> i'm torn between voting foryou to have access just to stfu or starting a vote to have you removed for harassing michaelni 
[21:48:32 CEST] <Compn> i am not sure why kierank is encouraging your behavior either
[21:49:35 CEST] <durandal_1707> you are all leader's peasant
[21:50:32 CEST] <BradleyS> i haven't seen the source but it sounds like nyancat
[21:51:05 CEST] <BradleyS> maholcat
[21:51:24 CEST] <durandal_1707> what?
[21:51:41 CEST] <BradleyS> your sierpinski source
[21:52:04 CEST] <durandal_1707> watch video it explains everything
[21:52:31 CEST] <durandal_1707> sierpinski have nothing to do with cat
[22:04:00 CEST] <durandal_1707> cehoyos: do you have access to security ml?
[22:05:07 CEST] <cehoyos> Yes, but I cannot recommend it
[22:06:16 CEST] <durandal_1707> why?
[22:08:34 CEST] <cehoyos> The amount of unreadable emails from Google is very large
[22:10:30 CEST] <durandal_1707> how so? michaelni claims it get lower as code coverage stays same
[22:18:36 CEST] <cehoyos> I missed an appointment a month ago because of the huge number of emails, I am not saying it gets lower or bigger
[22:19:49 CEST] <BtbN> So far every project I have seen where Google dropped their Fuzzing mails was mostly annoyed by it.
[22:20:08 CEST] <BtbN> Some super aggressive and short tampered person shows up, claiming to have found 900 security bugs.
[22:20:25 CEST] <durandal_1707> huh?
[22:20:52 CEST] <BtbN> Seen that happen at 5 independend projects. Always thought it was a troll at first. But it was actually Google having run a fuzzer.
[22:22:41 CEST] <durandal_1707> this is different. now overflows and timeouts are of security importance
[22:22:58 CEST] <durandal_1707> whats next step?
[22:23:13 CEST] <BtbN> Yes, for some reason, everything a fuzzer finds, is automatically a security bug.
[22:24:02 CEST] <durandal_1707> previously reports would be done differently
[22:24:20 CEST] <durandal_1707> now its one big mess
[22:24:21 CEST] <BtbN> Maybe the fuzzing stuff needs a dedicated ml of some kind?
[22:26:48 CEST] <durandal_1707> aha, eureka: next step is fuzzing filters
[22:29:05 CEST] <nevcairiel> its really only encoded bitstreams that can be fuzzed
[22:29:14 CEST] <kierank> nevcairiel: you can fuzz aac encoder
[22:29:19 CEST] <kierank> I found real bugs
[22:30:03 CEST] <nevcairiel> probably unexpected float nan/inf
[22:30:13 CEST] <nevcairiel> but integer stuff in filtering?
[22:30:41 CEST] <BtbN> I'm sure you can find some super long running loops or edge cases by piping in the right garbage
[22:30:46 CEST] <durandal_1707> nevcairiel: nope, there are even commits that fix bugs in one filter with using certain parameters
[22:31:07 CEST] <nevcairiel> well i suppose can fuzz config parameters, instead of raw input data :D
[22:31:13 CEST] <Lynne> with timeout bugs you need some really really really ridiculous probabilities to form the exact sequence to slow the decoder by 2s
[22:33:30 CEST] <BtbN> Why is "encoder hangs for 2s" even an issue that needs fixed? Hangs forever with 100% CPU sure is, but hanging for 2s?
[22:33:39 CEST] <kierank> nevcairiel: divide by zero
[22:38:14 CEST] <Lynne> BtbN: After asking the same question so many times I still don't know
[22:38:54 CEST] <thardin> hum, mxfenc regression
[22:38:57 CEST] <Lynne> like how is a 2, even 10s delay on an astronomically improtably combination of bits a security issue
[22:40:17 CEST] <Lynne> even the samples are treated the same way actually imporatant issues are like arbitrary code execution
[22:41:00 CEST] <durandal_1707> because it may kill path that leads to real security one
[22:43:01 CEST] <BtbN> a non-overflow path, where all it does is cause a loop to run for very long?
[22:43:26 CEST] <durandal_1707> but it is  like winning loterry
[22:43:39 CEST] <Lynne> my favorite ones are the timeouts that get fixes by pseudo-SIMD like AV_RN/WNXX hack
[22:44:26 CEST] <durandal_1707> yes
[22:44:31 CEST] <thardin> you can DoS certain services with bugs like that
[22:44:39 CEST] <BtbN> With a 2s hang?
[22:44:44 CEST] <durandal_1707> lol
[22:45:15 CEST] <thardin> well, if it's a tiny file and I can somehow upload a bunch of them quickly
[22:45:24 CEST] <Lynne> they're not even hacks, you can't argue they don't speed every platform up but seeing some weird bitops instead of adds/mults is just dubious
[22:46:03 CEST] <thardin> or just make the file longer. I'm sure there's plenty of cases
[22:46:10 CEST] <durandal_1707> lets stop this nonsense, and let reports in old fashioned way?
[22:46:20 CEST] <BtbN> trac would die
[22:46:55 CEST] <durandal_1707> huh? not really
[22:47:12 CEST] <BtbN> It's already struggling with the current volume of users hitting on it
[22:47:17 CEST] <kierank> thardin: you should limit timeouts at the OS
[22:47:31 CEST] <kierank> when handling untrusted data of any sort
[22:49:06 CEST] <thardin> myes, sandboxing and so on
[22:56:52 CEST] <tmm1> jkqxz: i bisected that vbr regression to https://github.com/FFmpeg/FFmpeg/commit/2562dd9e7831743ba6dc5680501fb7d26a2ec62c
[23:14:45 CEST] <thardin> bisecting #8077
[23:31:36 CEST] <jamrial> thardin: there were some recent changes to mxfenc mostly for h264 streams
[23:34:30 CEST] <thardin> this is d10 tho, so mpeg2
[23:35:37 CEST] <cehoyos> Why do you want to bisect 8077?
[23:35:49 CEST] <thardin> because I'm lazy
[23:37:10 CEST] <cehoyos> You can also open the ticket;-)
[23:45:18 CEST] <thardin> ah, now I see what you mean
[23:48:18 CEST] <thardin> I don't really think this is a bug with mxfenc but rather the way the mpeg2 stream is encoded
[23:48:40 CEST] <thardin> since it should be CBR but evidently isn't
[23:52:50 CEST] <thardin> but then again, how could you make CBR with NTSC?
[23:53:12 CEST] <thardin> 1001 doesn't divide 50000000
[23:58:24 CEST] <thardin> S356m has some specific frame size limits that I don't see mentioned in mxfenc.c
[23:58:47 CEST] <thardin> or mxf.*
[00:00:00 CEST] --- Tue Aug 13 2019