Seeing some weirdness with the transcoder add on (using Wowza 4.x). Some background info...
We're trying to transrate the source stream down to 2 lower bitrates, specifically 1200 Kbps down to 500 and 200. The source stream (1200) looks great, very fluid framerate, overall looks awesome. Now the 2 transrated streams (500 and 200) look smooth until we start seeing a lot of movement on the stream (dancing / arms flailing, etc) where it begins to look as if the framerate gets cut in half. CPU on the server is around 50%, so I don't think this is an issue with server stress.
When each stream's publishing has begun, I can see the JNI:VideoDecoderH264.updateDecodeInfo entry in the info log shows the proper framerate for each stream (24 fps). Switching between the different bitrates works great, keyframes are aligned properly and the transitions are smooth... so not sure if that's telling. We are not using an EC2 GP class instance due to cost, could it be that the instance we are using just can't handle drawing those frames?
The lower bitrate streams (500 and 200) are all set to passthrough for every setting except the codec (set to h264) so we can transrate down. If I monitor these 2 (not source) streams in VLC, I can see the number of lost frames grow at around 15 or more per second.
It sounds like the movement in the source video is the only factor, a not uncommon issue in encoding and compression. You might test for comparison one of the
G2 instances with NVENC. Or reducing load on that transcoding session in some way, either lower source specs or encoding parameters.
And you can look at what you have available on your system for
other mainconcept parameters. The available parameters varies from server to server, and we have no documentation or examples of their use, but I see this param in my system:
INFO server comment - # long: scene detection: visual content scene detection, 0: OFF, 1: IDR (see vcsd_mode_flags)
I am not sure that will help, but it sounds like it might.