Hi Ian, On Wed, 2017-07-19 at 08:16 +0100, Ian Arkver wrote: > Hi Philipp, > > On 02/03/17 10:19, Philipp Zabel wrote: > > I don't know what the BWB unit is, I guess W is for write and one of the > > Bs is for burst. All I know is that there repeatedly have been issues > > with it hanging on certain streams (ENGR00223231, ENGR00293425), with > > various firmware versions, sometimes blocking something related to the > > GDI bus or the GDI AXI adapter. There are some error cases that we don't > > know how to recover from without a reboot. Apparently this unit can be > > disabled by setting bit 12 in the FRAME_MEM_CTRL mailbox register to > > zero, so do that to avoid crashes. > > Both those FSL ENGR patches to Android and VPU lib are specific to > decode, with the first being specific to VC1 decode only. The first one is older, I suppose VC1 is where the issue has been observed first. I have seen sporadic BWB hangups when decoding h.264 RTP streams. > > Side effects are reduced burst lengths when writing out decoded frames > > to memory, so there is an "enable_bwb" module parameter to turn it back > > on. > > These side effects are dramatically reducing the VPU throughput during > H.264 encode as well. Prior to this patch I was just about managing to > capture and stream 1080p25 H.264. After this change it fell to about > 19fps. Reverting this patch (or presumably using the module param) > restores the frame rate. > > Can we at least make this decode specific? The VPU library patches do it > in vpu_DecOpen. I'd guess disabling the BWB any time prior to stream > start would be OK. Yes, since ENGR00293425 only talks about decoders, and I haven't seen any BWB related hangups during encoding yet, I'm inclined to agree. > It might also be worth adding some sort of /* HACK */ marker, since > disabling the BWB feels very like a hack to me. I don't think HACK in itself is very descriptive, but a reference to the original workaround could be helpful in the future. regards Philipp
