Hey all!
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?
just wanted to add a little bit more info…
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.
Are there any SKIP FRAME messages in the Wowza access and error logs? If so, the machine is probably not adequate, or might need to be tuned
Also, refer to Wowza Transcoder benchmarks
Richard
Hi Benny,
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.
Richard
Nice, you’re welcome, Benny. Let us know!
Richard
Hey Richard!
Not seeing any skip frame messages in access logs, log messages look “normal” and nothing in the error log. We’re using one of the pre-built EC2 AMIs (Wowza Streaming Engine 4) and I double checked after getting it mounted that it was auto-tuned properly.
We’re currently testing and just getting the feel for the new release, so this is currently not a production server. But we’re running the test streams on a c3.xlarge instance, so CPU / Memory is quite low for the tests, averaging around 15%.
Any ideas on what else it could be? Again we only see it when there are increases in activity (ie, more drawn frames).
Hey Richard,
Thanks so much for the thoughtful answer, dude. We’re looking to move these servers off of EC2 and onto Rackspace for the additional juice. I’ll see what we can accomplish there and be sure to post any findings on this thread.
Cheers, buddy. Thanks!
Hey guys!
So hopefully this may help other people experiencing the same issue with seeing jerkyness when using the transcoder.
At a really high level, it must have been all about resources and server juice. With a more powerful server on Rackspace the improvement is significant. I would imagine with hardware acceleration it would look/perform even better.
Not sure why the node on EC2 was chugging even though resources looked like they weren’t really stressed, but that’s a question for smarter dudes to answer.
So, in short… if it looks like 8-bit megaman, get a bigger serverman.