15:17 <blathijs> jernej: ndufresne: With your suggestions, I managed to get H264 hw decoding work. The decoding is now superfast, which is nice. I'm still struggling with the NV12 format though. It seems kmssink supports rendering NV12 according to drm_info and debug output, but only on plane 0, which produces no output for me (I have to explicitly pass a plane-id for planes 1/2/3 to get any HDMI

15:17 <blathijs> output). Does that ring a bell maybe?

15:20 <ndufresne> blathijs: yes, you can set a plane property to fix that, the "overlay" is in fact an underlay

15:20 <ndufresne> so its there, but under the opaque fbcon

15:20 <ndufresne> give me a sec

15:20 <blathijs> Right, that's exactly the thought that was forming in my head just now :-)

15:20 <blathijs> Thanks :-)

15:21 <ndufresne> On most HX board, I think you can change the z order like this kmssink plane-properties=s,zpos=1

15:21 <blathijs> Cool, let me try that

15:22 <blathijs> I also see that plane1 has an FB_ID set according to drm_info, so it indeed seems that that plane is used by the fb

15:23 <ndufresne> Works for me on Tritium/H3

15:24 <ndufresne> by default, kmssink looks for an overlay, and will use that, its a bit of a strange behaviour, but kmssink is a bit of a test thing for now

15:24 <blathijs> Yeah, that worked! (with zpos=2, the primary plane already had zpos=1 according to drm_info)

15:24 <ndufresne> cool cool

15:24 <ndufresne> which chip do you run on for my record ?

15:25 <blathijs> Ah, that was another question I had, how are these defaults determined. I do still wonder: why is this "overlay" not above the primary by default (which I guess is drm/kernel decided, right?)

15:25 <blathijs> H3

15:25 <blathijs> orange pi PC

15:29 <ndufresne> I think the default are reflective of the state of the HW after reset

15:30 <ndufresne> arguably, underlay is what you want if you make an app like khodi, or want to use mpv under your UI

15:36 <blathijs> Right, though (naively) I would think that the UI would be *another* overlay maybe. Or both planes should be primary maybe.

15:43 <blathijs> Or hide the primary fb plane maybe

16:11 <jernej> blathijs: only one plane can be primary

16:15 <blathijs> Yeah, that makes sense

16:17 <blathijs> Also, it seems that just using "playbin" actually already correctly uses the v4l2codecs decoder (and now that I manually set the zpos=2 once, the video is also actually displayed right away). This originally did not happen, but that was because I was accidentally using an MP4 encoded file rather than H264 :-P

16:23 <jernej> MP4 is container, do you mean MPEG4 part 2 (used by divx, etc.)?

16:25 <jernej> H264 is MPEG4 part 10, so either can be called MPEG4 :)

16:26 <blathijs> jernej: I think "file" said "divx", so I think I mean MPEG4 part 2, yes. Terminology is tricky indeed :-p

16:27 <jernej> if you really want to confuse people, you can say AVC instead of H264 :)

20:02 <blathijs> jernej: ndufresne: Many thanks for your help, I think I should be to make my project work with this. I'll have to convert my player python script from using libvlc to using gstreamer, but from reading the gstreamer documentation the past days, I think this will be a pleasant experience :-)

20:04 <ndufresne> cool cool!

20:05 <ndufresne> for that kind of low level playback, I only know gst and mpv as viable options, I never seen any effort in libvlc to handle things like bare metal display

20:10 <blathijs> ndufresne: On the rpi, I think vlc implements some hardware-specific module (that interfaces with a binary GPU blob I think), where you can just shove a h264 stream into the GPU and it will handle decoding and rendering completely in the binary blob, no X involved. So that was superconvenient and fast, but not really portable. Before that I was using omxplayer, which really did

20:10 <blathijs> not much more than shoving data into the GPU (and audioplayback), that was a direct evolution of the example program that came with the binary blob, I think.

20:13 <blathijs> I do hope that I can get gstreamer to also do this hw decoding on the rpi, so I do not need to also keep supporting vlc for those boards...

20:14 <blathijs> But it seems there are some "omx" plugins for GST, so it will probably work.

20:32 <ndufresne> blathijs: they should not need to use such massive hack on newer RPI stack

20:32 <ndufresne> the decoder is a V4L2 M2M device, which is well supported mainline ffmpeg

20:32 <ndufresne> and the GPU is a mesa driver and supports zero-copy from dmabuf produces by the decoder

20:33 <ndufresne> omxplayer was another story, it would pipeline the omx component, in a way that in fact the entire player was running on the co-processor and rendering on the co-processor too

20:34 <ndufresne> you need a year 2000 design to support this (running stuff on baseband)

20:34 <blathijs> ndufresne: Ah, that would be even nicer. Does that mean that decoding and rendering now uses open code, or is it still binary blobs that do the actual work?

20:35 <ndufresne> there is a blob on the firmware side, but that's all

20:35 <blathijs> Clearly you know more about this than what I've found out so far :-)

20:35 <ndufresne> the GPU is now managed by the CPU not the baseband

20:35 <jernej> for HEVC it will be entirely open driver, but it's not mainlined yet (API is not complete)

20:35 <ndufresne> yeah, HEVC decoder is managed by the CPU now

20:36 <ndufresne> jernej: you seen Ben first iteration of a final uaPI ?

20:37 <ndufresne> he spent few days on that this week, and ported hantro and cedrus driver, if you can test that there is no regression on cedrus, could be nice

20:37 <ndufresne> and comment back about the offsets

20:37 <jernej> ndufresne: yes, I've seen, but I don't have much spare time until Monday

20:37 <ndufresne> blathijs: in short, the HEVC core on RPi4 is a massive bump in term of tech, 4K HDR, very powerful

20:38 <ndufresne> jernej: same for me

20:38 <jernej> there is another issue with bit offset, I'll explain in response, early next week

20:40 <blathijs> Cool :-)

20:40 <jernej> in short, Cedrus requires bit offset to be right after header, before padding bits, while in uAPI you would expect that padding bits are included in bit offset

20:41 <jernej> I hope I could convince HW to work with expected offset

21:06 <ndufresne> jernej: yeah, this one is massive odness of cedrus, perhaps there is a workaround, otherwise we'll just add "padding bit size" and you will have to substract

21:06 <ndufresne> it no worst then hantro skip ?

21:07 <jernej> no, it's not worst, but I really hope it will not come to that

21:08 <jernej> hopefuly start code detection or something like that would allow to skip it

21:08 <jernej> *enabling