<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   pinchartl: <u>ezequielg</u>: agreed
   <br> but carrying out of tree changes to kernel headers should be an exception, not a rule
   ezequielg: I don't think out of tree changes is under discussion
   <br> Just version hell
   <br> Iiuc
   <br> Ie simply untangling the components
   pinchartl: in libcamera we have a copy of the relevant kernel headers, in a separate directory
   <br> and they are always updated together, in a standalone commit mentioning the upstream commit ID (or tag)
   ezequielg: Bingo!
   hverkuil: paulk-leonov: can you prepare a v8 HEVC series on top of https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.4l (which will hopefully be merged in our master branch soon)?
   <br> It needs to add DECODING_MODE and START_CODE controls as discussed before.
   <br> But once done I see no reason why it can't be merged for v5.4.
   <br> paulk-leonov: Second question: in order to merge the stateless decoder spec the only thing that needs to be done is that a driver (cedrus) adds support for the HOLD_CAPTURE_BUF flag and DEC_CMD_FLUSH.
   <br> What is the status of that work in cedrus?
   <br> If you have a working implementation for slices already, but it just doesn't use these new API additions, then that's something I might be able to work on for you.
   <br> if you don't have the time/money to do this yourself.
   <br> <u>ezequielg</u>: ping
   <br> paulk-leonov: what is the best supported board to test the cedrus driver on?
   ezequielg: <u>hverkuil</u>: pong
   hverkuil: <u>ezequielg</u>: good morning to you! :-)
   <br> quick question: if I want to test the hantro driver, which board is best maintained (by you or others) to do that testing on?
   ezequielg: Thanks! :)
   <br> Well, we are recommending rockpi.org, however in order to test h264 you either need rk3288 or imx8.
   <br> I'm using with great pleasure a radxa rock 2 rk3288 and a librecomputer h3
   <br> The latter for cedrus of course.
   hverkuil: h3 or h5?
   <br> I ordered an h5.
   ezequielg: Iirc, it's the same? I just have one bootlin gave me last year.
   <br> Not sure if the rock2 from radxa is still stocked.
   <br> Everything from radxa works pretty well
   hverkuil: Well, the librecomputer ALL-H3-CC actually comes in three variants.
   <br> https://libre.computer/products/boards/all-h3-cc/
   ezequielg: Yeah, but cedrus wise, is it different?
   hverkuil: No idea.
   <br> Hmm, I don't think it matters.
   <br> Same VPU specs for all three variants.
   ezequielg: Right.
   <br> Stocking yourself uh?
   hverkuil: Hmm, I see only the rock pi 4 (rk3399). Is rk3328 better for testing?
   paulk-leonov: <u>hverkuil</u>: pong
   <br> yes I'll try to prepare v8 soon, sorry about that
   <br> I don't have any implementation for the new features on cedrus
   <br> and I use the ALL-H3-CC-H3 for testing
   <br> it's slightly easier to setup than H5/A64/H6 since it's arm 32
   hverkuil: Are there any plans to add slicing support to cedrus in the near future? If not, then it would probably be better for me to create a stateless decode spec version without slicing support for decoding mode V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED and add that later.
   Kwiboo: <u>hverkuil</u>: for hantro g1 testing I can recommend asus tinker board s (rk3288) for testing, and the rock pi 4 (rk3399) if you want to test hantro rk3399 parts
   hverkuil: <u>Kwiboo</u>: does that tinkerboard now support CEC? IIRC the first version didn't.
   Kwiboo: yes, the S model supports CEC :-)
   hverkuil: Good. As CEC maintainer that's a prerequisite :-)
   Kwiboo: I asked jernej yesterday to test a ffmpeg version that sets V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED for cedrus, but I am unsure if the current slice based decoding in libreelec is part of mainline or require any wip patch
   paulk-leonov: <u>hverkuil</u>: as far as Bootlin is concerned we don't have time allocated to work on that
   hverkuil: paulk-leonov: good to know. I think I'll split off the slicing bits from the stateless decoder spec so the other bits can be merged without having to wait for someone to pick this up.
   paulk-leonov: <u>hverkuil</u>: I'm not sure what the best approach is -- cedrus decoding has been broken all along by assuming that only a single slice is passed and per-frame/per-slice mode doesn't really change that
   <br> so my suggestion would be to have cedrus report per-frame decoding as supported with the driver still broken
   <br> and switch it to per-frame once things are fixed
   <br> since for now, it supports per-frame decoding with 1 slice per frame only
   <br> switch to per-slice*
   ezequielg: <u>hverkuil</u>: rockpi is only rk3399, indeed.
   <br> that's why i was suggesting rk3288 rock2, but i've hear the tinker board is nice too. i don't have it.
   jernej: <u>hverkuil</u>: paulk-leonov: I can take a look at proper slicing support in Cedrus
   <br> from what I know, it shouldn't be hard and I would like to get rid of hack I'm using for this in LibreELEC
   hverkuil: <u>jernej</u>: that would be great!
   jernej: <u>hverkuil</u>: can you point me to documentation and patches?
   hverkuil: This is what is in my pull request: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.4l
   <br> This is my patch series: https://patchwork.linuxtv.org/project/linux-media/list/?series=588
   <br> patches 9-12 are not in the PR.
   <br> For slicing support patches 9 and 10 provide the API.
   <br> I can't merged those patches unless there is also a driver that uses those new API bits.
   jernej: are patches 9 and 10 considered to be good for merging? in other words, do I need to modify only Cedrus driver?
   hverkuil: In theory yes. They have never been tested with an actual driver, so there may be unexpected surprises :-)
   <br> That said, it looks straightforward.
   <br> But wait until my PR is merged, that makes life a bit easier.
   jernej: I have to study code a bit anyway, it has been a while since I've worked on Cedrus
   <br> <u>hverkuil</u>: IIUC driver should always advertise V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF, but only consider V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF when selected codec supports multiple slices per frame?
   hverkuil: <u>jernej</u>: yes. It's ignored if it makes no sense for the selected codec.
   jernej: does it make sense to create helper function to check if codec (pixel format) supports multi slice frames?
   hverkuil: If it helps the code, then why not? But I think it is easier to just set a bool in the driver state struct if a pixfmt is selected that supports multi slice frames.
   jernej: ah, that works too