On 19/07/17 10:32, Philipp Zabel wrote:
On Wed, 2017-07-19 at 10:15 +0100, Ian Arkver wrote:
On 19/07/17 09:09, Philipp Zabel wrote:
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:
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.
I took a look at where ctx->frame_mem_ctrl is used, i.e.
coda_start_encoding and __coda_start_decoding. Is it possible to have
one instance of coda open for encode and one for decode at the same
time?
Sure, when transcoding with a decoder / encoder pair, for example.
If so, how is the CODA_REG_BIT_FRAME_MEM_CTRL setting
updated between runs, eg. for differing CODA_FRAME_CHROMA_INTERLEAVE?
Yes. coda_command_async writes ctx->frame_mem_ctrl to
CODA_REG_BIT_FRAME_MEM_CTRL with each PIC_RUN command at from
prepare_encode/decode.
Totally missed that somehow. Thanks for the pointer.
This code is in the start_streaming path rather than the prepare_run
path. Does each context switch stop & restart streaming?
No, see above.
regards
Philipp
