On Wed, 22 May 2019 15:39:37 +0900 Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > > It would be premature to state that we are excluding. We are just > > trying to find one format to get things upstream, and make sure we have > > a plan how to extend it. Trying to support everything on the first try > > is not going to work so well. > > > > What is interesting to provide is how does you IP achieve multi-slice > > decoding per frame. That's what we are studying on the RK/Hantro chip. > > Typical questions are: > > > > 1. Do all slices have to be contiguous in memory > > 2. If 1., do you place start-code, AVC header or pass a seperate index to let the HW locate the start of each NAL ? > > 3. Does the HW do support single interrupt per frame (RK3288 as an example does not, but RK3399 do) > > AFAICT, the bit about RK3288 isn't true. At least in our downstream > driver that was created mostly by RK themselves, we've been assuming > that the interrupt is for the complete frame, without any problems. I confirm that's what happens when all slices forming a frame are packed in a single output buffer: you only get one interrupt at the end of the decoding process (in that case, when the frame is decoded). Of course, if you split things up and do per-slice decoding instead (one slice per buffer) you get an interrupt per slice, though I didn't manage to make that work. I get a DEC_BUFFER interrupt (AKA, "buffer is empty but frame is not fully decoded") on the first slice and an ASO (Arbitrary Slice Ordering) interrupt on the second slice, which makes me think some states are reset between the 2 operations leading the engine to think that the second slice is part of a new frame. Anyway, it doesn't sound like a crazy idea to support both per-slice and per-frame decoding and maybe have a way to expose what a specific codec can do (through an extra cap mechanism). The other option would be to support only per-slice decoding with a mandatory START_FRAME/END_FRAME sequence to let drivers for HW that only support per-frame decoding know when they should trigger the decoding operation. The downside is that it implies having a bounce buffer where the driver can pack slices to be decoded on the END_FRAME event.
