[04:43] <tfiga> ndufresne: good points, let me add them to my list of open questions
[04:43] <tfiga> thanks
[08:18] <hverkuil> ezequielg: I think you missed a mutex_unlock, and the commit log needs a bit more tweaking.
[08:23] <sailus> mchehab: Bom dia!
[10:44] <mchehab> sailus: moikka... please ping me next week... this week has been very tiring with the TZ changes and all stuff happening at oss-japan
[10:55] <sailus> mchehab: Ack.
[10:55] <sailus> It'd be great if you could check this when you have the time:
[10:55] <sailus> https://patchwork.linuxtv.org/patch/50464/
[10:55] <sailus> It includes compile fixes for the Cadence driver from Arnd.
[10:57] <sailus> It seems to be a regular source of kbuild bot failures at the moment.
[13:06] <ndufresne> tfiga, thanks
[13:06] <ndufresne> pH5, who's in charge of the DRM driver on IMX.6 ?
[13:07] <ndufresne> pH5, all the YUV formats display wrong colors here, with kmssink, it's not a mapping problem, kmssink has been tested with a pretty large amount of drm drivers
[13:23] <pH5> ndufresne: that would be me.
[13:23] <pH5> ndufresne: strange though, I regularly test kmssink on nitrogen6x and similar hardware with lvds panels or hdmi output.
[13:24] <pH5> could this be an alignment issue? we need scanlines to start at a multiple of 8 bytes
[13:24] <ndufresne> pH5, I have a DP connector, that I connect to my screen, but it goes on HDMI
[13:24] <ndufresne> pH5, even with DUMP buffers
[13:24] <pH5> so just gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12 (or I420) ! kmssink works here on two different devices
[13:24] <ndufresne> *DUMB
[13:25] <ndufresne> gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12 ! kmssink can-scale=0 connector-id=47
[13:26] <ndufresne> and same if I decode and display
[13:27] <ndufresne> let me send you a picture
[13:34] <ndufresne> pH5, just for the context, this is SabreLite, 4.17.0-rc4-linuxtv+ (checked out linuxtv master from yesterday), tested GStreamer 1.14 and master, no changes, no yocto hacks
[13:35] <ndufresne> pH5, do you have a clean gst build, I did saw in the past patches in some yocto that would flip the color mapping, pretending that userspace is wrong
[13:35] <ndufresne> DRM to V4L2/GST pixel format matching isn't trivial 1-1, it depends on the endianness
[13:37] <ndufresne> pH5, https://imgur.com/a/Gj9D0Ns
[13:45] <pH5> ah, so not an alignment problem, that's weird looking. BGRx works correctly?
[13:50] <ndufresne> yes, all BGR* and variants works for me, haven't tested 16bit yet
[13:51] <ndufresne> pH5, also, connector 47 is HDMI-A-1 even though it's a display port cable
[13:52] <ndufresne> I don't think I have a display to connect to lvds
[13:53] <ndufresne> just in case it's also useful, here's the selected trio, connector id = 47 / crtc id = 35 / plane id = 33
[13:55] <ndufresne> pH5, btw, everytime I try a new HW, I also try and enable all the pixel formats, I'll work on that for the IMX too
[13:55] <ndufresne> I'm unsure what AR12 is though
[14:12] <pH5> I have unpatched gst-plugins-bad, and I tried on vanilla 4.18-rc1. I get connector id = 47 / crtc id = 38 / plane id = 39 (HDMI) or connector id = 45 / crtc id = 30 / plane id = 31 (LVDS)
[14:15] <pH5> ndufresne: I think the bug might be that plane 33 advertises YUV support, but we only have colorspace conversion on one plane. I have no idea though why the second overlay plane is selected for you, but not for me.
[14:16] <pH5> I can enforce plane-id=28 connector-id=45 or plane-id=39 connector-id=47, that works as well
[14:18] <pH5> trying to force kmssink to use plane 33 with connector 45 fails.
[14:42] <pH5> ndufresne: I'd try to disable the parallel display in the DT to free up planes 28/31, or force plane 39. I'll fix the advertised format list for plane 33, thanks for the report.
[14:56] <ndufresne> pH5, ok, I'll give that a try
[14:57] <ndufresne> pH5, oh, wait, connector 45 ? I have no idea were that goes out, it says "800x480"
[14:57] <ndufresne> that's suppose to be DP right ? I have no idea why my screen nego HDMI instead of DP over a DP cable ...
[15:00] <ndufresne> ok, tried,  47 / crtc id = 35 / plane id = 39, that did go
[15:00] <ndufresne> hmm, I can force the CRTC in kmssink
[15:01] <ndufresne> * can't
[15:01] * ndufresne heading toward hacking the DTB a little
[15:03] <pH5> ndufresne: 800x480 is an LCD panel, I think connected to the parallel port. I'm not sure it is a good idea to have this enabled in the default DTB, but that's the way it is.
[15:04] <ndufresne> ok, best for me is to turn that off and try again, at least it will remove some noise
[15:04] <pH5> if you have a HDMI to DP cable, that probably has a converter chip inside, i.mx6 doesn't have DP encoder.
[15:04] <ndufresne> here I got DP to DP cable, so it's simply using the DP cable for HDMI signal apparently
[15:05] <ndufresne> (my laptop does that too if the screen supports it)
[15:06] <pH5> but sabrelite only has an hdmi connector?
[15:07] <ndufresne> arg, never mind, I'm confusing boards now, it's hdmi to hdmi, sorry for the noise
[15:09] <ndufresne> pH5, it's lcd_display that I need to disable ?
[15:12] <ndufresne> ok, parallel is gone, lvds is still on
[15:34] <ndufresne> pH5, ok, just turing off DP, ended up using another plane, and now CSC conversion works properly
[15:35] <ndufresne> I would turn off lvds too, but not sure how, I've turned off the backlight, the kernel wasn't happy, then I turned off the panel, that cause some infinit loop in the kernel
[15:37] <pH5> ndufresne: try setting status = "disabled" in the &ldb node
[15:37] <pH5> (that's short for lvds-display-bridge)
[15:38] <ndufresne> ah, missed that one, hehe, acronymes, I would have read the doc of course ;-P
[15:39] <ndufresne> pH5, ok, next, are you aware of b-frame reordering issues with that codec ?
[15:41] <ndufresne> I'm rendering bbb_sunflower_1080p_60fps_normal.mp4 and see frame miss-ordering
[15:46] <pH5> yes, I assume that is h.264 level 4.2 or higher?
[15:48] *** benjiG has left 
[15:49] <ndufresne> level=(string)4.2, profile=(string)high
[15:50] <ndufresne> pH5, maybe we should implement RO level/profile CID on the decoder too, just for the purpose of enumerating the supported one ?
[15:50] <ndufresne> tfiga, ^ what do you think about this proposal ?
[15:52] <pH5> ndufresne: coda960 only supports up to level 4.1, but I suppose even though we probably can't decode >= 4.2 in realtime, we should still recognize it and enable reordering.
[15:52] <pH5> try https://patchwork.linuxtv.org/patch/50465/
[15:55] <ndufresne> pH5, works
[15:59] <ndufresne> pH5, also, for that specific file, the decoder is fast enough, it does 67 fps avg, nothing under 60
[15:59] <pH5> ndufresne: perfect, and we haven't even overclocked the vpu yet
[16:00] <ndufresne> though, I'm sure there is streams with higher antropy then bbb
[16:00] <pH5> I think RO level/profile CID to report the available range is a good idea.
[16:01] <pH5> of course the actual value would be bogus until headers are parsed.
[16:05] <ndufresne> right, but that can be documented, though, I'm not sure how well supported this is in general
[16:05] <ndufresne> svarbanov, do you know if venus report back the detected profile/level ?
[16:05] <ndufresne> pH5, specially if the firware does not know about 4.2, it's maybe unlikely to report back ...
[16:08] <ndufresne> pH5, nice, first time I actually see renegotiation working
[16:09] <ndufresne> good start, far from optimal, but better then nothing
[16:09] * ndufresne starting to like the imx6 ;-P
[16:10] <pH5> ndufresne: yes, I was quite impressed seeing resolution changing h.264 streams decode properly for the first time after you added the big hammer method to v4l2videodec
[17:59] <ndufresne> pH5, any idea why do_idle in the kernel uses 93% of the CPU time while decoding ?
[18:05] <ndufresne> pH5, I've tried every hack I could, can't get kmssink to reach 60fps, it's stuck at 30 ....
[18:06] <ndufresne> I managed to get a really smooth 30 though ;-D
[19:06] <ezequielg> hverkuil: let me check that lock and fix the commit log.
[20:19] <ndufresne> pH5, I'm a bit stuck now, is it me or coda driver reset colorspace to what the output is setup ?
[20:20] <ndufresne> Idea here, and correct me if I'm missing something tfiga, but on encoder, we set the output format first, because that might affect the possible input pixel format, and res
[20:21] <ndufresne> ... but can't think of a working flow
[20:24] <pH5> ndufresne: hm, yes, that is 2c756c72c4cc ("media: coda: set colorimetry on coded queue"), which is stupid given my new understanding that capture colorimetry currently can't be set at all
[20:28] <ndufresne> also, I'm a bit worry, since if we report colorimetry on the capture port, but set the capture port format first
[20:28] <ndufresne> then the flow is, S_FMT(CAPTURE), S_FMT(OUTPUT), G_FMT(CAPTURE), for the case the encoder do color conversion
[20:29] <ndufresne> and if not, the S_FMT(OUTPUT) ends-up changing the CAPTURE format ...
[20:30] <ndufresne> I'm not sure how much of this we want (one S_FMT changing the other side FMT)
[20:31] <ndufresne> And if I set the format on OUTPUT first, the encoder might not know how to align in case each codecs have different alignments
[20:32] <ndufresne> (the down side of having multiple codecs single interface)
[20:32] <pH5> what if the encoder can do configurable colorspace conversion? S_FMT(CAP)(pixelformat) -> S_FMT(OUT)(size,colorimetry) -> S_FMT(CAP)(target colorimetry) ?
[20:34] <pH5> If colorimetry is to be set on the output queue, I think gstreamer must ignore CAPTURE colorimetry completely unless there is a source change event.
[20:34] <ndufresne> even for GStreamer, that is just so unusual, the decoder conversion is already quite giving me a hard time
[20:34] <ndufresne> have you notice that v4l2h264dec ! videorate ! video/x-raw,framerate=xxx ! fails on the second negotiation ?
[20:35] <ndufresne> hmm, a source change event on en encoder ...
[20:36] <ndufresne> ok, I think I'll sleep on that, and see what are the solutions
[20:38] <pH5> ndufresne: that would be great, there's still time to revert/fix that patch for v4.18.
[20:39] <pH5> I just have no idea yet, how :)