[00:35] *** b-rad has quit IRC (Ping timeout: 240 seconds)
[06:12] *** bparrot has quit IRC (Remote host closed the connection)
[08:44] *** kaspter has quit IRC (Quit: kaspter)
[08:53] *** fling is now known as goffee
[08:56] *** goffee is now known as fling
[09:11] *** nst has quit IRC (Read error: Connection reset by peer)
[11:18] *** NiksDev has quit IRC (Remote host closed the connection)
[11:23] <grohne> hi. I'm about to submit a RFC patch for a media/i2c driver. the driver supports onsemi mt9m024 and onsemi ar0141cs (aptina was acquired by onsemi). what is a good name for such a driver? a) use mt9m024 as it is the older one b) submit two very similar drivers c) something else?
[11:24] <grohne> I got an ok from onsemi to publish a gpl driver based on nda documents for both devices (<- unbelievable!).
[11:28] <grohne> it also works for mt9m022 with a few changes, but we don't have permission to publish that part. :-(
[11:42] *** nsaenz has quit IRC (Read error: Connection reset by peer)
[11:57] <hverkuil> grohne: start with calling it mt9m024. It's an RFC patch, so we can always change our mind later.
[12:07] <grohne> thank you.
[12:48] *** al has quit IRC (Quit: al)
[15:05] <stormer> bbrezillon: hverkuil: Do you think there would be a way in the v4l2 compilance test to verify that statefull and stateless codecs that has profile and levels do implement this control
[15:05] <stormer> This is kind of really important for userspace with software fallbacks
[15:05] <stormer> (stormer == ndufresne)
[15:07] <hverkuil> stormer: do implement which control?
[15:10] <stormer> PROFILE / LEVEL when applicable for the codec
[15:11] <stormer> basically the FORMAT is insufficient to know if the driver will be able to decode that stream, you also need PROFILE constraint, and sometimes they don't support full range of LEVEL, so that is also needed
[15:11] <stormer> for some codec it's really simpe, vp8/9 have profile 1 2 3 (or something like this), each are subset
[15:12] <stormer> other are more complex, but all we need is a list, we can handle the contraint in userspace
[15:14] <hverkuil> If someone gives me a list of required controls for stateful/less codecs, then it is very easy to check for those in v4l2-compliance.
[15:17] <stormer> ok, I'm adding to my todo
[15:19] <stormer> I think it's useful for m2m, for v4l2output (if those still exist), for capture, we can always parse that, so it seems very option, would make sense if you can tell the capture card encoder what to pick
[15:28] <bbrezillon> hverkuil: do we have specific 4CC for YUV with 10/12/16 bit per component?
[15:35] <bbrezillon> ndufresne: there's something I don't quite understand with the rkvdec+VP9 implem
[15:37] <bbrezillon> looks like the IP block is only able to out NV12 (8bit per component), but some VP9 profiles want 10 or 12bits per component.
[15:37] <bbrezillon> how can that work for ref-frames
[15:38] <hverkuil> bbrezillon: I don't think we have 4CCs for that.
[15:39] <bbrezillon> oh, and it seems that bits_depth (AKA bits per components) can change dynamically in VP9
[15:47] <bbrezillon> stormer: actually, it's not clear if the rkvdec support VP9 profiles > 0
[15:48] <bbrezillon> but the driver in the chromium tree seems to take bit_depth into account when calculating strides
[16:05] *** benjiG has left 
[16:15] <svarbanov> ndufresne, stormer, about HDR10+ dynamic metadata payload see this https://www.atsc.org/wp-content/uploads/2018/02/S34-301r2-A341-Amendment-2094-40.pdf
[16:21] <stormer> arg, so they pack this up with the CC and AFB, I hate ATSC style, but howwell
[16:22] <stormer> is it my reader or the indent is the syntax is totally broken ?
[16:23] <stormer> svarbanov: thanks for the link, I'll drop it in GStreamer related issue
[16:30] <svarbanov> stormer, I haven't look deeply (just saw 2094-40), for it is binary blob :p
[16:30] <svarbanov> * for me
[16:35] <stormer> There is issues with considering these Binary blobs, as there is load of overlaps int he various standards
[16:35] <stormer> what we usually want in GStreamer, is to break it down, so it can be converted between standards
[16:36] <stormer> also, with video converters, you will very unlikely pass a blob
[16:37] <stormer> if lucky, you just compute the right matrix for that frame, and that's what your converter wants, but sometimes HW will be close to one standard
[16:37] <stormer> and you can't figure-out the params from the computed matrix
[16:39] <stormer> And quickly it becomes driver problems, so they have to deal with high level data, ideally parsed, and compute these matrix
[16:39] <stormer> (userspace or kernel space drivers, but we don't really have an infratructure for userspace drivers in linux-media)
[17:35] <bparrot> hverkuil: ping
[17:37] <bparrot> DT related question...
[17:38] <bparrot> i have a bridge driver with let say two ports and define using the ports { port@0 {}; port@1 {} }; type construct in a dtsi file.
[17:40] <bparrot> Now when building a dts file which refer to these port using a phandle for example then it builds without issue. However if i put a similar construct in a DT overlay files (.dtso) when i build it it complain with this warnring:
[17:40] <bparrot>  Warning (graph_port): /fragment@1/__overlay__: graph port node name should be 'port'
[17:41] <bparrot> of course if I removed the @1 or @0 from the port name the warning goes away but then that wrong I think.
[17:42] <bparrot> Any thoughts?
[17:47] <mripard_> bparrot: can you paste the DT's?
[17:49] <bparrot> mripard_: the overlay or dtsi or both?
[17:49] <mripard_> both
[17:53] <bparrot> mripard_: https://pastebin.ubuntu.com/p/jKNCyZ4Zqx/
[17:57] <mripard_> I guess it's a false positive
[17:57] <mripard_> https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/checks.c?id=df536831d02c51556a8e88cd8da0be0244484156 introduced it
[17:57] <mripard_> Judging from the commit log, Rob didn't take the overlay case into account
[18:00] *** lucaceresoli has quit IRC (Remote host closed the connection)
[18:02] <bparrot> mripard_: yeah not sure how the "match" is done there, i need to study that code
[20:21] *** elGamal has quit IRC (Quit: ZNC 1.7.4 - https://znc.in)