[02:45:45 CET] <atomnuker> why does FFSIGN return -1 when the input is 0? [03:09:00 CET] <Zeranoe> jkqxz: I've now testing your patches on three machines and no issues. Plus I haven't had a hang yet. I'd love to see this applied upstream [08:58:35 CET] <durandal_1707> is git server down for everybody? [13:48:50 CET] <jkqxz> Zeranoe: RiCON: Thank you for your testing efforts! [13:49:11 CET] <jkqxz> So, is there any outstanding reason not to apply the series? [14:04:17 CET] <RiCON> jkqxz: no issues from me, but i'm not a heavy user of qsv [14:09:53 CET] <BtbN> how do I edit wiki pages? [14:11:14 CET] <jkqxz> Be logged in and press "edit this page"? [14:11:24 CET] <BtbN> I am logged in, can't edit the HWAccelIntro page [14:12:33 CET] <jkqxz> Works for me. What is going wrong? [14:12:46 CET] <BtbN> well, there simply is no such button. [14:13:06 CET] <BtbN> they are present on other pages though [14:13:49 CET] <BtbN> uBlock is getting rid of them oO [14:15:09 CET] <jkqxz> Weird. It's just a normal submit button with some styling. [14:16:32 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:042faa847fee: avcodec/8bps: Check side data size before use [14:16:33 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:121be3106078: avcodec/cinepak: Check side data size before use [14:20:56 CET] <BtbN> god damn there are more nvenc_h264 [14:20:58 CET] <cone-883> ffmpeg 03Mark Thompson 07master:e8634fb92e2f: openssl: Allow newer TLS versions than TLSv1 [14:24:19 CET] <jkqxz> BtbN: Better not try googling it... [14:24:39 CET] <BtbN> Well, it was the official name for quite a while [14:24:47 CET] <BtbN> And was only somewhat recently deprecated [14:26:07 CET] <DHE> so the syntax is $CODECNAME_$METHOD for consistency then? [14:26:38 CET] <BtbN> yes [14:29:17 CET] <jkqxz> Like h264_libx264. [14:32:16 CET] <sopparus> jkqxz, noticed the merge. Thanks for helping out. here is another ticket I noticed which you can close https://trac.ffmpeg.org/ticket/5905 [14:32:37 CET] <BtbN> libx264 doesn't offer multiple codecs though [14:32:45 CET] <BtbN> originally nvenc was called just nvenc, when it just supported h264 [14:36:50 CET] <jkqxz> sopparus: Yep; thank you! [14:40:34 CET] <JEEB> 9 [15:39:35 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:a2b8dde65947: avcodec/idcinvideo: Check side data size before use [15:39:36 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:2d99101d0964: avcodec/kmvc: Check side data size before use [15:47:08 CET] <atomnuker> YCOCG SUPPORT FOR VF_COLORSPACE! [15:47:30 CET] <atomnuker> does that mean the future is here? [15:47:39 CET] <JEEB> no, the future is in dolby's thing 8) [15:48:30 CET] <JEEB> ICt whatever it was [16:59:39 CET] <jkqxz> jamrial_: nevcairiel: I shall apply the qsv merge series. Ok? [16:59:48 CET] <jkqxz> (These six patches <http://ixia.jkqxz.net/~mrt/ffmpeg/qsv-merge/>, which includes one from Zeranoe to fix a Haswell failure.) [18:36:19 CET] <nevcairiel> jkqxz: i'll give it a final read later tonight or early tomorrow [18:38:53 CET] <Chloe> yay qsv merge is near :D [18:59:10 CET] <jkqxz> nevcairiel: Ok; thank you. [19:31:44 CET] <DHE> Going through the filter code, it looks like lavfi only supports threading on a per-filter basis. For example if I have a pipeline of 3 filters it's not possible to have each one execute a different frame in a separate thread. Does that sound right? Something that would be beneficial? [19:34:33 CET] <nevcairiel> that sounds right, but it would probably be quite complicated to sync everywhere [19:35:01 CET] <DHE> yeah, was thinking about that. there becomes a need for a blocking vs nonblocking buffersink operation and so on... [19:35:19 CET] <nevcairiel> i bet someone already had the idea :) [19:35:26 CET] <nevcairiel> the slice threading on a filter level was trivial in comparison [19:35:33 CET] <nevcairiel> so it was a low hanging fruit [19:36:47 CET] <DHE> I'm running '[0:v] split=4 [out1][out2][out3][out4]; ...' where each one then gets further processing. so threading there seems to make a lot of sense. but it still doesn't really answer what to do next... [19:37:25 CET] <DHE> I have a patch in the mailing list to allow users to limit the thread pool size. My machine has 80 CPUs and I don't think slice processing at that level is beneficial [19:53:07 CET] <philipl> BtbN: slow mailing list: https://github.com/philipl/FFmpeg/commit/76329c947ff535cccca0b4dce6ecc543073... [19:53:52 CET] <BtbN> I don't think it should be removed. [19:54:06 CET] <BtbN> First of all, it's essentialy a breaking change. [19:54:27 CET] <BtbN> And doesn't it just fail straight away anyway? [22:39:44 CET] <cone-078> ffmpeg 03Andreas Cadhalpun 07master:14e4e2655969: interplayacm: check for too large b [22:39:45 CET] <cone-078> ffmpeg 03Andreas Cadhalpun 07master:5540d6c1343e: interplayacm: validate number of channels [23:21:21 CET] <philipl> BtbN: it fails, but at least mpv doesn't fall back. It just grinds to a halt. [23:21:50 CET] <philipl> I'm not sure how it's really a breaking change if it never worked. [23:25:01 CET] <BtbN> does it automatically select it? If it's explicitly requested, sure, a hard fails seems about expected. [23:29:09 CET] <philipl> It will auto-select in mpv based on the logic in mpv. If it wasn't there, it would just use the regular decoder. [23:31:15 CET] <BtbN> Shouldn't that be fixed in some other way then? VP9 will have the same problem, if the user doesn't use a Pascal-Card. [23:38:40 CET] <philipl> BtbN: The hardware doesn't support it and has never supported it. I made a mistake. [23:39:02 CET] <philipl> I told it to use the mpeg4-asp decoder for h.263 [23:39:26 CET] <philipl> It doesn't fail at decoder creation because the decoder is valid. [23:40:25 CET] <BtbN> Oh, so there simply is no h263 decoder in cuvid. [23:40:30 CET] <iive> you know that mpeg4-asp and h263 are quite different? [23:40:32 CET] <philipl> right. [23:40:47 CET] <philipl> Yes, I do. late in the game, but yes. [23:41:38 CET] <BtbN> Yes, then it should be removed again, of course. [23:42:14 CET] <iive> if i remember correctly, mpeg4-asp could decode h263, there was something about short headers. [23:43:33 CET] <philipl> Well, it's possible that this is a limitation in the cuvid parser rather than decoder, but either way it doesn't work. [23:44:30 CET] <philipl> vdpau can do wmv3, which really should mean cuvid can too but the parser can't handle it, even if the decoder could. [23:45:15 CET] <philipl> BtbN: anyway, I' [23:45:17 CET] <philipl> ll push that [23:52:47 CET] <cone-078> ffmpeg 03Philip Langdale 07master:21b68cdbae65: avcodec/cuvid: Don't claim to decode h.263 (it doesn't) [00:00:00 CET] --- Mon Oct 31 2016