hverkuil: an interesting question: if we have a request with buffers for 2 different queues and we stop streaming on one of the queues, what should happen with the request and the other queue?
I suppose the request should be completed, but does that mean that we need to return the buffers from the other queues too?
pinchartl: sailus: ^^
to make it even more complicated, what if there are some requests without a buffer from the queue being stopped
tfiga: I think streamon/streamoff makes less sense with requests. we're trying to make two very different APIs work together, and it shows its limits. regardless of what we decide to do in this particular case, we'll have hacks
is this for a video codec ?
pinchartl: indeed, that was a bit of my thought as well :(
for an ISP
think of a similar model as IPU3 IMGU, but using Request API
one option would be to ignore streamon/off on all queues but the main one (you can pick pretty much any queue as the main one)
and a VIDIOC_STREAMON/OFF on the main video node would then start/stop all queues
bbrezillon: ezequielg: is the RK3399 VDPU related to hantro in any way?
seems to have different codec ops in the driver
paulk-leonov: it is
the fields are just shuffled
bbrezillon: ah I see
so it's also a G1 and probably a G2 for HEVC/VP9?
but you'll find exactly the same fields and it works the same way
okay thanks
nope, they have their own block for HEVC/H264(4K)/VP9
ah ok
AFAICT it's not based on the G2
that's what they call VPU2?
they call it rkvdec
VPU2 is the G1 with reg-fields shuffled IIRC
well, it's actually a G1/H1 combo
right
so rk3288 has a G2 then?
(I see HAVE_HEVC_DEC in mpp)
hm, I don't think it has a G2
bbrezillon: so my understanding is that rockchip came up (or sourced) an h265 IP that they used in rk3288 and later improved it to become the rk3399 h264/hevc/vp9 engine
apparently mpp has only a single implementation for hevc
so I'm assuming it must be the same on both rk3288 and rk3399
clocks between rk3288 hevc and rk3399 rkvdec seem to match