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

[burek]

[01:14:07 CEST] <cone-493> ffmpeg 03Carl Eugen Hoyos 07master:d96d65dfebdd: lavu/utils: Use "__asm__" like everywhere else in the codebase.
[13:37:34 CEST] <ubitux> why is libopenjpg such a mess... T_T
[13:38:01 CEST] <JEEB> is that about the patch to add support for latest upstream or something?
[13:38:07 CEST] <JEEB> also didn't it have that AGPL fork thing?
[13:38:08 CEST] <ubitux> yeah
[13:38:27 CEST] <ubitux> like, everytime there is a new release we have to add a ton of crazy check to the configure
[13:38:31 CEST] <BtbN> did not break API or ABI, still renamed everything.
[13:38:32 CEST] <ubitux> wtf is going on
[13:38:36 CEST] <JEEB> lol
[13:38:47 CEST] <ubitux> it's like it's an entire new project after every release
[13:38:55 CEST] <ubitux> even though that's the same shit
[13:39:15 CEST] <ubitux> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
[13:39:17 CEST] <ubitux> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
[13:39:21 CEST] <ubitux> how long is this gonna go?
[13:39:24 CEST] <JEEB> :|
[13:39:47 CEST] <BtbN> have configure auto-generate it based on what version it finds
[13:39:58 CEST] <BtbN> and only code in actual api differences
[13:40:08 CEST] <ubitux> have you seen the libopenjpeg check?
[13:40:17 CEST] <BtbN> yep
[14:40:05 CEST] <RiCON> ubitux: with the removal of openjpeg 1.x after 3.4 it can probably get simpler
[14:52:28 CEST] <jkqxz> On the comment that the new libopenjpeg "contains many security-related fixes": should we infer from that that the old versions are unmaintained with known security issues and should therefore be dropped?
[14:53:08 CEST] <JEEB> sounds like it at least
[17:13:58 CEST] <cone-630> ffmpeg 03Michael Bradshaw 07master:41d6d6270243: lavc: add support for OpenJPEG 2.3.0
[17:14:41 CEST] <ubitux> ... ?
[17:16:13 CEST] <durandal_1707> wut?
[21:23:32 CEST] <relaxed> 3.4 will support libopenjpeg 2.3.0 ?
[21:24:07 CEST] <jamrial> judging by the latest commit, yes
[22:03:22 CEST] <nevcairiel> jkqxz: considering recent talk on the subject, did you consider a CBS filter for h264 to re-add x264 version metadata?
[22:04:52 CEST] <nevcairiel> although perhaps one doesnt even need CBS for that, its not filtering an existing bitstream as such, just adding a new SEI
[22:06:14 CEST] <jamrial> nevcairiel: the existing h264 metadata bsf can do that already
[22:06:24 CEST] <nevcairiel> oh
[22:06:41 CEST] <jamrial> the sei_user_data option adds an unregistered user data SEI with an arbitrary string
[22:07:05 CEST] <nevcairiel> oh yeah, just a bit hard to use
[22:07:10 CEST] <jkqxz> Yeah, you just want 'h264_metadata=sei_user_data=x264-uuid-which-is-long+x264 - core 42'.
[22:07:19 CEST] <jkqxz> Could be added to the docs?
[22:08:10 CEST] <jamrial> jkqxz: going to send a new version of the cbs set, or just push the one in the ml?
[22:08:25 CEST] <jamrial> were there outstanding changes that need a new revision?
[22:08:35 CEST] <nevcairiel> he just posted a new one
[22:08:39 CEST] <nevcairiel> hence why I remembered to ask
[22:08:49 CEST] <jamrial> oh
[22:08:53 CEST] <jamrial> my bad :p
[22:09:01 CEST] <jkqxz> Though note that it doesn't directly work on the sample in whatever the bug is on trac, because it only inserts the SEI in a unit with an SPS and the extradata isn't inline.
[22:09:37 CEST] <jkqxz> Not sure what to do to fix that.  Dumping to a raw stream and reading back gives you the right extradata and then it works.
[22:10:08 CEST] <jkqxz> Or it could just unconditionally insert it in the first access unit, maybe.
[22:10:27 CEST] <nevcairiel> thats where the x264 data would be anyway
[22:10:33 CEST] <nevcairiel> and only there, its not ever repeated later
[22:12:28 CEST] <jamrial> h264 sei messages are never in extradata anyway. they are not in avcc and we don't extract them from raw streams into extradata either
[22:14:51 CEST] <jkqxz> Oh, libx264 in lavc actually has code to extract that sei from the headers.
[22:20:57 CEST] <jkqxz> Yeah, always stuffing it in the first access unit is probably the best answer.
[22:28:20 CEST] <jkqxz> Yeah, that works nicely with the file on trac.
[22:29:21 CEST] <jamrial> that'd make a good fate test, btw
[22:30:07 CEST] <jamrial> for both the metadata filter and the backwards compat code for these old files
[22:33:04 CEST] <jkqxz> Do we have a test in fate already for that?
[22:35:17 CEST] <jamrial> don't think so, the whole compat code for these files is pretty recent
[22:36:00 CEST] <jkqxz> I mean, I thought one was added with it?  That would then want the SEI-stripping BSF to make the input, and I'm not sure I want to make that...
[22:36:13 CEST] <jamrial> http://coverage.ffmpeg.org/libavcodec/h264_cabac.c.gcov.html or maybe we do
[22:36:23 CEST] <jkqxz> (Tools which can only be used for evil, and all that.)
[22:36:32 CEST] <Luigi12> michaelni: not sure if you'd heard about this http://openwall.com/lists/oss-security/2017/10/02/1 but just letting you know if not
[22:36:40 CEST] <Luigi12> sorry for the double-ping, just moving this to the -devel channel where it belongs
[22:37:09 CEST] <jamrial> jkqxz: no, i mean, adding a sample encoded with old x264 that had the sei stripped, like in that ticket, then using the metadata filter to add a fake x264 sei so it decodes
[22:37:56 CEST] <JEEB> Luigi12: you might want to note what that is in general
[22:38:06 CEST] <jkqxz> I was thinking if there already is one then we could remove the SEI from it programmatically and avoid adding another sample.
[22:38:07 CEST] <cone-284> ffmpeg 03Marton Balint 07master:41569bbc66d8: ffmpeg: always use single threaded decoding for attached pictures
[22:38:13 CEST] <Luigi12> JEEB: Internet Bug Bounty project. They were going to include ffmpeg, but they needed to hear from upstream before OK'ing it.
[22:38:25 CEST] <JEEB> well that still doesn't explain what that is
[22:38:31 CEST] <JEEB> and what are the requirements from the project
[22:38:38 CEST] <JEEB> and/or anything else like that
[22:39:05 CEST] <jamrial> jkqxz: only if changing the sample doesn't breaks fate with old releases
[22:39:19 CEST] <jamrial> they all use the same rsync samples suite
[22:39:26 CEST] <Luigi12> JEEB: you really need to read the mailing list thread for full context
[22:39:34 CEST] <Luigi12> it's not that long
[22:39:53 CEST] <jkqxz> I can't find a test.  Maybe there actually isn't one.
[22:40:25 CEST] <jamrial> there is a sample, though, judging by the coverage link above
[22:41:02 CEST] <Luigi12> JEEB: short version is it's a project that pays bounties for security bugs with a PoC, but only for approved projects.  They'd like to add ffmpeg, but need to hear from upstream first.
[22:41:31 CEST] <Luigi12> they've already added libav, but obviously it'd be much more useful for people to audit ffmpeg
[22:41:34 CEST] <JEEB> well that part I kind of get without going further but the reason why they'd have to have explicit approval from the OSS project is interesting
[22:41:45 CEST] <JEEB> as in, what is there that might not be wanted by a project
[22:41:52 CEST] <jkqxz> That suggests that there is only a bad sample, and no good one?
[22:42:31 CEST] <jamrial> yeah
[22:42:46 CEST] <jkqxz> (And is that test really correct?  x264_build is -1 by default, which will invoke the bad path.)
[22:43:37 CEST] <Luigi12> JEEB: they don't explicitly address that question in the thread, but it sounds like they wanted to be sure that the project is interested in and prepared to deal with reports of security issues
[22:43:40 CEST] <jkqxz> Hmm, maybe it's a random conformance sample, and the decode is just wrong.
[22:43:49 CEST] <jamrial> jkqxz: i think that's why it checks for 151U
[22:44:19 CEST] <Luigi12> I know that FFmpeg has always been good about handling security issues in the past, but I guess they don't want to assume (since they're shelling out money)
[22:44:19 CEST] <jkqxz> Oh, integer promotion.  That's totally opaque.
[22:45:17 CEST] <jamrial> wouldn't be libavcodec otherwise :P
[22:59:08 CEST] <cone-284> ffmpeg 03Carl Eugen Hoyos 07master:f49c129dd494: lavd/decklink_dec: Do not claim to output transparency information.
[23:09:02 CEST] <cone-284> ffmpeg 03Carl Eugen Hoyos 07master:c2d155e11ee5: configure: Disable -Wbool-operation.
[23:16:30 CEST] <cone-284> ffmpeg 03Carl Eugen Hoyos 07master:cd01b3cbcf3b: lavu/opt: Use "&&" instead of "*" in boolean expression.
[23:36:16 CEST] <michaelni> Luigi12, ive found the mail and replied, yes we of course we want to be part of bug bounty stuff
[23:47:44 CEST] <cone-284> ffmpeg 03James Almer 07master:65c3a32836f4: configure: disable libxcb dependent features if libxcb is not enabled
[00:00:00 CEST] --- Mon Oct  9 2017