Sorry for resurrecting this thread but I'm still quite interested on
making this scenario work:
> OK, I've performed some tests with several resolutions and gop sizes,
here is the table with the results:
>
> Always playing 3 streams
>
> | Resolution | QP | GopSize | Kind of content | Result
|
> | 640x368 | 25 | 16 | Waving hands | time
shifts, no DEC_PIC_SUCCESS |
> | 640x368 | 25 | 0 | Waving hands | time
shifts, no DEC_PIC_SUCCESS |
> | 320x192 | 25 | 0 | Waving hands | time
shifts, no DEC_PIC_SUCCESS |
> | 320x192 | 25 | 16 | Waving hands | time
shifts, no DEC_PIC_SUCCESS |
> | 1280x720 | 25 | 16 | Waving hands | macroblock
artifacts and lots of DEC_PIC_SUCCESS messages |
> | 1280x720 | 25 | 0 | Waving hands |
Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS|
>
> * The issues always happens in the first stream, the other 2 streams
are fine.
> * With GopSize = 0 I can even decode 4 720p streams with no artifacts
>
> It looks like for small resolutions it suffers from time shifts when
multi-streaming, always affecting the first stream for some reason. In
this case gop size doesn't seem to make any difference.
>
> For higher resolutions like 720p using GopSize = 0 seems to improve
things a lot.
>
Philipp, you mentioned some possible issue with context switches in a
previous e-mail:
> I fear this may be some interaction between coda context switches and
> bitstream reader unit state.
Philipp, do these results confirm your theory? Are there any more tests
I could prepare to help get to the bottom of this or this is something
that belongs entirely to the coda firmware domain? Does anyone know if
the official BSP from NXP is able to decode 4 flows without issues?
