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

[burek]

[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/76329c947ff535cccca0b4dce6ecc5430730ce91
[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