Hello Philipp,
On 14/03/18 16:11, Philipp Zabel wrote:
Hi Javier,
On Wed, 2018-03-14 at 15:35 +0100, Javier Martin wrote:
[...]
The encoder is running on a different system with an older 4.1.0 kernel.
Altough the firmware version in the code is 3.1.1 as well.
Do you think I should try updating the system in the encoder to kernel
4.15 too and see if that makes any difference?
I don't think that should matter. It'd be more interesting if GOP size
has a significant influence. Does the Problem also appear in I-frame
only streams?
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.
Regards,
Javier.
