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

[burek]

[00:19:15 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:f8b17fe33233: avcodec/opusenc_psy: Fix warning: ISO C90 forbids mixed declarations and code
[00:19:16 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:9f1b99e7d076: avcodec/sbc: Fix non static function prefix
[00:19:17 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:3dfe3436ac78: avcodec/sheervideodata: Fix libavutil include
[00:19:18 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:c0bce367e493: avcodec: Fix AVClass .version
[00:19:19 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:13b77af2f0b5: avdevice/android_camera: Fix AVClass.version
[00:36:20 CEST] <rcombs> do we have a way to pass options to a HWAccel?
[00:37:38 CEST] <atomnuker> why would you want to pass options to decoders?
[00:42:09 CEST] <whs> Hi, I have problem following the tutorial http://dranger.com/ffmpeg/tutorial01.html
[00:42:55 CEST] <whs> I have tried may times but the line pCodec=avcodec_find_decoder(pCodecCtx->codec_id);
[00:43:04 CEST] <whs> Always returns error
[00:43:40 CEST] <whs> It seems that the codec_id is always 0 for whatever inputs
[00:44:17 CEST] <whs> Could you please help?
[00:44:38 CEST] <nevcairiel> you want #ffmpeg for help using the libraries
[00:53:54 CEST] <whs> Would it be a bug that avformat_find_stream_info doesn't set the codec_id correctly?
[01:52:23 CEST] <cone-535> ffmpeg 03Stephan Holljes 07master:7b6b8c92652d: lavf/http.c: Free allocated client URLContext in case of error.
[02:22:45 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:860293a9a29b: doc/APIchanges: Fix typos in hashes
[02:22:46 CEST] <cone-535> ffmpeg 03Rahul Chaudhry 07release/4.0:ef9902560391: swresample/arm: remove unintentional relocation.
[02:22:47 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:df56bc18efd2: avcodec/cinepak: move some checks prior to frame allocation
[02:22:48 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:ecb375684d7b: avcodec/cinepak: Skip empty frames
[02:22:49 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:5888679ae331: avcodec/dfa: Check dimension against maximum
[02:22:50 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:bfe61bbd0076: avcodec/dsicinvideo: Propagate errors from cin_decode_rle()
[02:22:51 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:66bdf8f14593: avcodec/dsicinvideo: Fail if there is only a small fraction of the data available that comprises a full frame
[02:22:52 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:bc2ceeb3ac34: avcodec/opusenc_psy: Fix warning: ISO C90 forbids mixed declarations and code
[02:22:53 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:e36830c6959d: avcodec/sbc: Fix non static function prefix
[02:22:54 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:8b019be79b6b: avcodec/sheervideodata: Fix libavutil include
[02:22:55 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:5cc6370a1501: avcodec: Fix AVClass .version
[02:22:56 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:b2b7cb0f606c: avdevice/android_camera: Fix AVClass.version
[02:22:57 CEST] <cone-535> ffmpeg 03Stephan Holljes 07release/4.0:b9b3ef4f5a51: lavf/http.c: Free allocated client URLContext in case of error.
[02:22:58 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07release/4.0:ace829cb45cf: Changelog: replace <next> by 4.0
[02:34:19 CEST] <atomnuker> so that's it? 4.0 is out?
[02:34:24 CEST] <nevcairiel> no
[02:34:30 CEST] <nevcairiel> tomorrow
[02:50:37 CEST] <jamrial> atomnuker: release is made when it's tagged
[03:25:15 CEST] <rcombs> atomnuker: in this case to indicate whether using the videotoolbox hwaccel on a device without a hardware HEVC decoder should result in a failure, or a software fallback
[03:25:24 CEST] <rcombs> in the corresponding encoder there's an option for that
[03:46:57 CEST] <atomnuker> I think we have something for that
[04:01:27 CEST] <rcombs> if we do, pls inform tmm1 
[04:02:45 CEST] <atomnuker> well, we don't really have any way to tell the decoder to forbid it
[04:03:06 CEST] <atomnuker> but there's a way to tell if a hardware decoder can fall back to software
[04:03:08 CEST] <atomnuker> AV_CODEC_CAP_HYBRID
[04:08:58 CEST] <rcombs> that's for full codecs, not hwaccels
[04:09:21 CEST] <rcombs> (it'd be nice if VT was a full codec but >reordering)
[04:17:49 CEST] <mistym> I saw there's discussion of a new release coming tomorrow! Would someone be up for reviewing a patch I have on the mailing list before then? It fixes a minor issue with one of the new features that would be in the new release.
[04:36:32 CEST] <jamrial> mistym: the segafilm patch?
[04:42:05 CEST] <mistym> jamrial: Yeah, that's right
[04:52:52 CEST] <jamrial> mistym: should be ok, will push in a bit
[04:53:29 CEST] <jamrial> mistym: for that matter, you got the keyframe flag wrong. it's 0 for intra and 1 for inter
[06:31:05 CEST] <atomnuker> jkqxz: sent a new version of my vulkan patches, I think I addressed all of your original notes
[07:31:34 CEST] <cone-171> ffmpeg 03Steven Liu 07master:002e45b40760: avformat/dashenc: change the hls version from 6 to 7
[07:36:15 CEST] <mistym> jamrial: There's some context on that in this thread http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227014.html
[08:40:10 CEST] <cone-171> ffmpeg 03Vishwanath Dixit 07master:30940be3593a: avformat/http: flushing tcp receive buffer when it is write only mode
[11:42:21 CEST] <jkqxz> tmm1: rcombs:  Add AV_HWACCEL_FLAG_ALLOW_SOFTWARE?
[11:46:10 CEST] <Chloe> atomnuker: vulkan will be 4.1 unfortunately I Think
[11:53:25 CEST] <Chloe> atomnuker: also all your patches which have new files are missing your name
[11:56:38 CEST] <wm4> <jkqxz> tmm1: rcombs:  Add AV_HWACCEL_FLAG_ALLOW_SOFTWARE? <- or AV_HWACCEL_FLAG_STRICT_HARDWARE
[11:57:37 CEST] <wm4> what I do _not_ want is when the hwaccel is somehow slower than sw... but I guess you can't always detect that
[11:57:42 CEST] Action: wm4 stares at Intel hybrid hwaccel
[12:17:13 CEST] <cone-171> ffmpeg 03Vishwanath Dixit 07n4.0:HEAD: avformat/http: flushing tcp receive buffer when it is write only mode
[12:20:17 CEST] <Chloe> what is n4.0:HEAD
[12:20:48 CEST] <Chloe> typo?
[12:21:18 CEST] <jkqxz> wm4:  Sure, fair enough.  The hwaccel flag is still the right way to do it.
[12:21:52 CEST] <jkqxz> Chloe:  It's just the bot doing funny things with tags, I think.  It looks fine elsewhere.
[12:26:39 CEST] <nevcairiel> yeah thats what it says when you push a tag
[12:29:21 CEST] <Chloe> nevcairiel: oh so that's a new tag being pushed then?
[12:29:33 CEST] <Chloe> what's the difference between 4.0 and release/4.0?
[12:29:43 CEST] <nevcairiel> release/4.0 is the branch
[12:29:46 CEST] <nevcairiel> n4.0 is the tag
[12:30:07 CEST] <Chloe> oh right
[13:36:58 CEST] <durandal_1707> i have strange buffer overflow bug in vc1, anybody interested?
[13:40:30 CEST] <atomnuker> Chloe: that's okay, I wasn't targeting 4.0
[13:50:34 CEST] <Compn> durandal_1707 : make an exploit for it, then claim the bounty when you fix :P
[13:53:55 CEST] <durandal_1707> Compn: ffmpeg does not give it
[14:18:48 CEST] <durandal_1707> what is variable ACT within DNxHD 444 files?
[14:33:40 CEST] <Chloe> Compn: there are no public bounties other than videolans
[14:36:26 CEST] <nevcairiel> occasionally some people put bounties on trac tickets, from outside the project
[14:38:39 CEST] <Compn> iirc there was some project paying for open source vuln fixes a few years ago
[14:38:41 CEST] <Compn> anyways it was a joke
[14:38:52 CEST] <Compn> durandal_1707 : post bug, people are interested in fixing such overflows
[15:02:36 CEST] <jdarnley> On the subject of bounties, I recall some third-party website which was letting people post and accumulate bounties for opensource projects.
[15:02:52 CEST] <JEEB> VideoLAN's wiki has some bounties
[15:02:53 CEST] <jdarnley> Without the projects' approval though.
[15:02:58 CEST] <JEEB> oh
[15:03:26 CEST] <JEEB> yea there's some thing that lets people put such things forward, I think? but under the project's account in that system
[15:03:26 CEST] <jdarnley> Yeah, which is what made it sound dodgy.
[15:03:35 CEST] <JEEB> don't remember how it was named
[15:03:41 CEST] <jdarnley> ditto
[15:20:33 CEST] <nevcairiel> why does a Mac build still uncondintially link against some Mac-framework shit I didn't explicitly request? I thought linking was supposed to be smart now
[15:24:45 CEST] <Chloe> nevcairiel: is it an issue to link with frameworks not explicitly requested? They will always be there
[15:25:11 CEST] <Chloe> Which ones specifically were  causing problems?
[15:25:53 CEST] <nevcairiel> i need to make sure this binary still works on 10.7+, and with unnecessary link-time stuff showing up, it doesnt fill me with confidence
[15:26:56 CEST] <nevcairiel> i dont enable any of the osx platform features
[15:34:44 CEST] <BtbN> Might actually be the OSX compiler deciding it itself unless explicitly disabled?
[15:35:19 CEST] <nevcairiel> no, its configure
[15:35:28 CEST] <nevcairiel> i commented the shit out and surprise stuff still builds
[15:36:21 CEST] <wm4> the problem is that it's too hard to make configure changes that are actually correct
[15:39:59 CEST] <JEEB> yea, every time I think of adding a pkg-config check I need to remember how exactly that was to be done
[15:40:07 CEST] <JEEB> esp. if it's an autodetected thing like zlib
[15:40:38 CEST] <JEEB> (yes, zlib has a pkg-config file and I often use cross-prefixes which are not sysroot for mingw-w64)
[15:52:36 CEST] <j-b> Thilo?
[15:52:56 CEST] <nevcairiel> dont think he  hangs around here
[16:37:02 CEST] <klaxa> reading old ML threads about ffserver >arm & mips used native ffmpeg as the qemu i used seems to lack execvp()
[16:37:18 CEST] <klaxa> right, it did something crazy like calling ffmpeg...
[16:47:59 CEST] <wm4> woah
[16:54:11 CEST] <JEEB> yea, ffserver used to muck around ffmpeg
[17:11:45 CEST] <klaxa> >ffserver has been serving our purpose in a 24/7 fashion for about 7 years now.
[17:11:58 CEST] <klaxa> wow
[17:22:19 CEST] <wm4> where
[17:47:05 CEST] <CounterPillow> now that is gross
[17:47:38 CEST] <CounterPillow> I like how 4.0 still isn't on the "News" page
[17:48:27 CEST] <CounterPillow> >4.0 release made, ill leave writing the news entry to people who can write english without a spell checker
[17:48:29 CEST] <CounterPillow> classic MiNi
[17:48:46 CEST] <nevcairiel> a patch for a news entry is on the ML; wont be much longer
[17:49:58 CEST] <BtbN> I really don't see how no news for a day or even half a day is a big issue.
[17:50:24 CEST] <BtbN> Other projects make releases and then stay silent for weeks, so distributions can catch up, and then go and announce it.
[17:50:51 CEST] <CounterPillow> inconsistencies are not nice.
[17:51:04 CEST] <BtbN> inconsistencies where?
[17:51:22 CEST] <BtbN> The only place where the release is announced is on the ml, git and in the topic of the -devel channel.
[17:51:31 CEST] <durandal_1707> and twitter
[17:51:38 CEST] <BtbN> FFmpeg has Twitter?
[17:51:52 CEST] <durandal_1707> yes
[17:52:21 CEST] <BtbN> https://twitter.com/ffmpeg this?
[17:53:18 CEST] <jamrial> CounterPillow: i'll kindly ask you to drop it
[17:53:31 CEST] <jamrial> i sent a patch for the news entry. it's a non issue
[17:55:20 CEST] <CounterPillow> jamrial: I just mentioned it, wtf
[17:55:52 CEST] <jamrial> CounterPillow: the "classic MiNi" line was absolutely unnecessary
[17:56:32 CEST] <durandal_1707> mini me, it's me
[18:13:53 CEST] <BtbN> Faszinating, ISP remote-rebooted mid day, and switched me from native IPv4 to DS-Lite
[18:17:53 CEST] <wm4> mid day maintenance is the best
[18:26:57 CEST] <klaxa> wm4: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/210229.html you even replied :D
[18:31:42 CEST] <BtbN> not maintenance. They rebootet my home-router, and I didn't have a public IP anymore.
[18:31:55 CEST] <BtbN> Called them immediately, and they reversed it.
[18:40:49 CEST] <wm4> why the fuck is libcuda calling accept4()
[18:43:23 CEST] <wm4> this isn't even with hw decoding
[18:43:38 CEST] <wm4> well, mostly
[19:21:47 CEST] <philipl> wm4: how do you get yourself into these situations? :-)
[19:23:28 CEST] <BtbN> probably just looking at an strace, and seeing an accept4 when there is no network stuff happening?
[19:33:59 CEST] <wm4> actually I looked at "show threads"
[19:34:08 CEST] <wm4> and noticed a bunch of cuda threads, one in accept4
[19:34:16 CEST] <wm4> this is with mpv, just the cuda interop is loaded
[19:34:23 CEST] <wm4> big wtf
[19:34:49 CEST] <philipl> Must be how their remote control agent works :-)
[19:35:08 CEST] <philipl> What is the socket?
[19:35:08 CEST] <wm4> uses unix domain sockets as far as I can see
[19:35:22 CEST] <philipl> Maybe a debug thing?
[19:42:02 CEST] <BtbN> it talks to the driver that way iirc
[19:42:13 CEST] <BtbN> opens the /dev/nvidia thing
[19:52:43 CEST] <atomnuker> fucking opus specifications
[19:53:30 CEST] <atomnuker> "lets change decoding and make 2 outputs valid because one fucking person had a 2.1 system he liked very much without a dedicated bass speaker channel"
[19:53:58 CEST] <atomnuker> "ambisonics is becoming really popular, we should add support for that"
[19:54:28 CEST] <atomnuker> "lets just make 16/255 channel mappings experimental and not specify anything!"
[19:55:29 CEST] <atomnuker> and so opus supports ambisonics in that if you signal some magic bits and use one implementor's idea of how ambisonics are meant to work it'll work
[20:07:01 CEST] <atomnuker> oh its all fine, the RFC isn't finalized yet
[20:07:33 CEST] <atomnuker> ...but the reference implementation has implemented all this in its master branch
[20:11:05 CEST] <wm4> well that doesn't affect ffmpeg yet or does it
[20:11:13 CEST] <wm4> ffmpeg needs a way to represent that ambisonic stff
[20:11:16 CEST] <wm4> *stuff
[20:14:51 CEST] <atomnuker> it does because we need to analyze the header to figure out which of the decoding APIs to initialize and run
[20:15:19 CEST] <nevcairiel> what I dont understand is why there is different  APIs in the first place, shouldnt that just be  metadata
[20:17:47 CEST] <wm4> not sure if I follow
[20:18:20 CEST] <wm4> oh, libipus
[20:18:23 CEST] <wm4> *libopus
[20:18:39 CEST] <wm4> it really has different APIs, wut
[20:19:02 CEST] <kierank> hmmm #aomedia discussion reminds me about h264 closed captions bug
[20:20:25 CEST] <atomnuker> wm4: it has 3 decoding APIs
[20:20:34 CEST] <atomnuker> currently anyway
[20:24:11 CEST] <wm4> but why
[20:26:20 CEST] <atomnuker> I believe its for downmixing
[20:27:28 CEST] <atomnuker> yeah, seems like so, the API can do demixing if you give it a matrix
[20:40:37 CEST] <BtbN> why is that the job of a decoding library
[20:42:25 CEST] <atomnuker> it shouldn't be, I've pointed that out in my respose
[20:42:51 CEST] <wm4> lavc also can downmix in the decoder
[20:42:58 CEST] <wm4> but at least it's only an option
[20:45:47 CEST] <nevcairiel> very few decoders implement that, and usually its not as much "downmixing" but just skipping additional substreams or the like
[20:53:38 CEST] <atomnuker> I don't know if ambisonics should be handled like this, demixing them is non-trivial
[21:13:35 CEST] <cone-955> ffmpeg 03Aman Gupta 07master:fd6e89586c01: avformat/utils: ignore outlier durations on subtitle/data streams as well
[21:13:35 CEST] <cone-955> ffmpeg 03Aman Gupta 07master:7b8daa771cbd: avformat/utils: refactor upstream_stream_timings
[21:13:58 CEST] <KGB> [13FFV1] 15michaelni pushed 2 new commits to 06master: 02https://git.io/vpm9j
[21:13:58 CEST] <KGB> 13FFV1/06master 143bc7c2e 15Dave Rice: grammar/wording updates
[21:13:58 CEST] <KGB> 13FFV1/06master 144ead389 15Dave Rice: correct reference to chroma subsample values...
[21:23:15 CEST] <TD-Linux> atomnuker, so I guess I can reply on the list, but the "downmixing" is not the decoding of ambisonics into 5.1 or whatever
[21:23:28 CEST] <TD-Linux> but rather it's mapping internal opus streams into ambisonics channels
[21:23:33 CEST] <TD-Linux> it's not position dependent
[21:25:54 CEST] <cone-955> ffmpeg 03Aman Gupta 07release/4.0:0502602d3757: avformat/utils: ignore outlier durations on subtitle/data streams as well
[21:25:55 CEST] <cone-955> ffmpeg 03Aman Gupta 07release/4.0:8cd79c2e73d4: avformat/utils: refactor upstream_stream_timings
[21:32:13 CEST] <tmm1> kierank: which bug?
[21:33:05 CEST] <kierank> Threaded h264 decode with field coded pictures and captions
[21:33:34 CEST] <kierank> Sent a patch ages ago but BBB wasn't happy with modifying previous thread data
[21:34:12 CEST] <BBB> you can ignore my comments, I was asked to shut up so if nobody else sees it as a concern, feel free to apply it
[21:34:40 CEST] <kierank> I mean I dislike doing it but I see no other way
[21:34:50 CEST] <kierank> Dunno who told you to shut up
[21:35:13 CEST] <BBB> not you :-p
[21:35:34 CEST] Action: kierank was on holiday, can't have told you to shut up :)
[21:36:15 CEST] <BBB> nice people dont tell fellow people to shut up
[21:36:18 CEST] <BBB> anyway
[21:36:21 CEST] <BBB> not the point
[21:36:49 CEST] <BBB> my point was: Im not in a position to be concerned and I cant improve upon your patch anyway
[21:46:38 CEST] <KGB> [13FFV1] 15michaelni closed pull request #110: CRC part is also possible with v0/v1 (06master...06crc_v0) 02https://git.io/vA5VK
[21:51:27 CEST] <durandal_1707> you pushed web stuff without my aproval! :(
[21:52:41 CEST] <durandal_1707> why VC1 motion vectors are off by one?
[21:54:59 CEST] <atomnuker> they are?
[21:55:28 CEST] <atomnuker> that should cause visible artifacts, shouldn't it?
[21:56:03 CEST] <durandal_1707> atomnuker: yes, i inspecting artifacts in sample http://trac.ffmpeg.org/ticket/2557
[21:56:21 CEST] <durandal_1707> it is interlaced fields
[21:56:44 CEST] <durandal_1707> and there is off by one causing bit reader desync
[21:57:11 CEST] <durandal_1707> because of hybrid predicion
[21:58:35 CEST] <durandal_1707> bacically sum is 32 but it should be 33
[21:59:58 CEST] <durandal_1707> and trigger reading more bits
[22:09:38 CEST] <durandal_1707> ideas?
[22:35:49 CEST] <atomnuker> is there a spec?
[22:37:13 CEST] <durandal_1707> atomnuker: there is lot of stuff
[22:38:32 CEST] <durandal_1707> look at multimedia wiki entry
[22:39:27 CEST] <atomnuker> this only happens with interlaced, right?
[22:41:13 CEST] <durandal_1707> atomnuker: interlaced field mode
[22:41:29 CEST] <durandal_1707> 2 consecutive frame, each single field
[22:53:16 CEST] <JEEB> huh, did 4:4:4 AVC decoding change recently other than lossless?
[22:55:13 CEST] <durandal_1707> no
[22:56:07 CEST] <nevcairiel> there were several fixes to that, all related somewhat
[22:56:56 CEST] <JEEB> because my test suite contains an old 4:4:4 non-mod2 height sample and I'm getting corruption on it locally and from an old upload, so corruption is unlikely
[22:57:51 CEST] <JEEB> http://www.cccp-project.net/beta/test_files/444_not_mod2_pupa_sample.mkv
[22:58:25 CEST] <nevcairiel> that looks like the typical 4:4:4 cabac failure
[22:58:34 CEST] <nevcairiel> ie. broken encode from way back when
[22:58:39 CEST] <JEEB> ok
[22:58:46 CEST] <JEEB> and since it's a cut sample it has no x264 SEI
[23:00:57 CEST] <jamrial> use the h264_metadata filter to add a custom x264 sei
[23:01:20 CEST] <wm4> JEEB: yeah, works with mpv's --vd-lavc-assume-old-x264
[23:01:39 CEST] <wm4> which means the SEI was stripped somehow
[23:02:10 CEST] <wm4> funny, the sample name indicates it was for some other problems
[23:02:24 CEST] <wm4> now it's a sample for at least 2 bugs
[23:02:42 CEST] <JEEB> yea, non-mod2 4:4:4 used to have a bug in DirectShow :)
[23:02:52 CEST] <JEEB> so yes, now it has two things that can go wrong
[23:07:30 CEST] <JEEB> also it seems like explorer.exe's favourite reason to freeze are audio files today
[23:31:59 CEST] <rcombs> protip don't watch pupa
[23:33:11 CEST] <nevcairiel> so its good that the sample was only pixel soup?
[23:33:26 CEST] <JEEB> rcombs: hey it was some of the best cringes I had in a while then
[23:33:42 CEST] <JEEB> esp. the sounds
[23:33:45 CEST] <JEEB> munch munch
[23:34:48 CEST] <atomnuker> hey, anyone with a kaby lake with an intel gpu on linux here?
[23:35:03 CEST] <nevcairiel> yes, yes, no
[23:35:43 CEST] <atomnuker> jkqxz?
[23:39:47 CEST] <jkqxz> Yes, yes, yes.
[23:41:58 CEST] <atomnuker> jkqxz: could you compile and run https://github.com/ascent12/drm_info
[23:42:18 CEST] <atomnuker> someone on another channel is wondering whether newer intel cpus have lots of overlay planes
[23:42:43 CEST] <jkqxz> Can I run modetest instead?
[23:43:12 CEST] <jkqxz> Also I know offhand without running anything that you get a primary, two overlays and a cursor on each pipe.
[23:44:29 CEST] <atomnuker> if it prints that, yeah
[23:46:31 CEST] <jkqxz> Hmm.  My coffee lake only gives me one overlay plane.  I know apollo lake gives me two, though.
[23:47:35 CEST] <atomnuker> are you sure?
[23:47:50 CEST] <atomnuker> that tool prints 3 sets of (primary, overlay, cursor)
[23:47:55 CEST] <atomnuker> on my skylake
[23:47:59 CEST] <jkqxz> Kaby lake also gives one.
[23:48:05 CEST] <jkqxz> On each pipe.
[23:50:00 CEST] <atomnuker> still 3 pipes?
[23:50:50 CEST] <jkqxz> <https://0x0.st/sSIo.txt>.  card0 is Coffee Lake, card1 is a Polaris 11 with DC.
[23:52:49 CEST] <jkqxz> Apollo Lake definitely has two overlays, though, because I've recently been writing some stuff on one using all of them.
[23:56:31 CEST] <atomnuker> thanks
[23:57:26 CEST] <atomnuker> suprising that the CPU has 1 plane with 10 bit support
[23:57:51 CEST] <atomnuker> *all primary ones
[23:58:58 CEST] <atomnuker> skylake just give me https://0x0.st/sSIK.log
[23:59:55 CEST] <atomnuker> oh wait, just noticed mine does support 10 bit primary planes too, I thought they used to be special and not very popular
[00:00:00 CEST] --- Sat Apr 21 2018