I’m using the transcoder addon for Wowza 4.0.3 to take a 720p 1.6 Mbps stream and drop it down to a 360p 0.4 Mbps stream for IOS/Android. The lower quality stream generally looks good, but occasionally, every few minutes or so, the quality drops and the image gets very blurry and pixelated. After looking at the performance monitor, I can see the CPU spike at same time as the image getting blurry. The server CPU hovers around 20-30% and when it spikes, it only hits 40% or so. The server is a Virtual machine running on VMware with two dual core CPUs assigned and 6 GB of RAM. I’ve checked the Java Tuning guide for Wowza 4 and it basically says to set everything to automatic, which it is. I do have it running in production not developer mode. I know it’s not a network issue, because my old encoder does transcoding and it can send out both stream and they run through the server to the same endpoints with no trouble. Is there anything I can do to prevent these drops in quality?
Do you see any messages like this in the access log?
TranscodingSession.updateBehindFilter[transcoder/definst/myStream]: Video behind filter state change. New state: SKIP1FRAME
TranscodingSession.updateBehindFilter[transcoder/definst/myStream]: Video behind filter state change. New state: ALLFRAMESON
If so, this means that machine is not keeping up with transcoding. Take a look at the Transcoder Benchmarks to get an idea of server capabilities and limitations.
Richard
This is Wowza reporting on what it is receiving, which is an issue either with the network or the encoder. It might be inadequate connection on the encoder side.
Richard
Do you see the same in RTMP playback in the desktop? Android is difficult. What are the frame sizes? Try these frame sizes:
800x480
480x320
240x160
Also make the video Profile Baseline, if not already.
Richard
Ethan,
I think we’ll have to take a closer look. First re-start Wowza, start up the stream and test playback in Flash on the desktop and Android device, then zip up the /conf and /transcoder folder and the current access log showing your re-start and tests and send to support@wowza.com. Include links to your stream, and include link to this post for reference
Thanks,
Richard
Hey guys!!
Been a while since I posted, so hope all is well with the Wowza team.
Seeing some weird stuff with using the transcoder regarding quality at lower bitrates, similar to what the OP was experiencing, except we don’t have any CPU spikes or lines in the logs that suggest an issue with either the source stream, hardware, or transcoder itself.
Some background info:
We’re sending a very small stream (640 x 360) at 3 different bitrates: 1200, 500, 200. Once the audio is added they become 1392, 692, and 392. The profiles for the 692 and 392 bitrates are passthrough for framesize, keyframe interval, audio codec, etc. We’re only adjusting the bitrate itself down from the input source at 1392 (1200 + 192).
At some points, usually when there is a lot of movement on the source stream, the quality of the lower bitrates gets really, really poor. Very blocky, but no stuttering or jerky movements. Only very pixelation and visual distortion, the audio however, is fine, no issues.
Video is h264 w/ AAC audio, 640 x 360 - Main profile 4.1. Serving to desktop clients, not mobile devices.
Any insight? Lemme know if you would like / need more info, I’d be happy to provide it! :o)
bump? 
Hey Salvatore,
No worries on the late reply, I understand y’all are busy. :o)
Is it elements being recorded that are moving, or the camera itself?
If there are a lot of changes between frames (ie, movement) that’s when the distortion/pixelation occurs. Recording doesn’t seem to affect either way (but maybe I misunderstood that one).
What are the fps and keyframe frequency(GOP) of the source?
24 FPS with KF every 2 secs
You might want to increase fps, and decrease GOP length, and try different bitrate combinations. A key frame every two seconds may not be enough to ensure stream quality while motion occurs.
I’ll try these out and post back any findings! Cheers, buddy.
Hello Benny, sorry we did not get to this question sooner.
So you say you do not see any indication of an issue in the logs? You can start Wowza in stand alone mode [install-dir]/bin/startup.bat|startup.sh and view the output in real time in the console.
Is it elements being recorded that are moving, or the camera itself?
What are the fps and keyframe frequency(GOP) of the source?
You might want to increase fps, and decrease GOP length, and try different bitrate combinations. A key frame every two seconds may not be enough to ensure stream quality while motion occurs.
Kind regards,
Salvadore
I didn’t find those specific errors, but I did find these.
WARN server comment 2014-04-09 03:18:54 - 26.664- LiveStreamPacketizerSmoothStreaming.handlePacket[live/definst/offline_low]: Fragment duration greater than suggested range of 1-4 seconds. Adjust keyframe interval accordingly: Fragment durations: [4.9,4.9,4.9]
WARN server comment 2014-04-09 18:40:53 - 55346.337 - SanJosePacketHandler.handlePacket[live/definst/high]: Timecode out of order [video]: 55358366:55358833
WARN server comment 2014-04-09 18:40:53- 55346.338- LiveStreamPacketizerSmoothStreaming.handlePacket[live/definst/high]: Timecode out of order [video]: 553583660000:553588330000
WARN server comment 2014-04-09 18:40:53- 55346.338- CupertinoPacketHandler.handlePacket[live/definst/high]: Timecode out of order [video]: 55358366:55358833
WARN server comment 2014-04-09 18:40:54- 55346.94 - LiveStreamPacketizerPacketHandler.handlePacket[live/definst/high]: Timecode out of order [video]: 55358366:55358833
I used to run key framing every 120 frames which is the Wirecast default I believe. I changed it to 60 the other day, and I think it reverted to the old setting. I’ve updated that and will see if it helps. Any thoughts on the time code errors? They would have been around the time we were broadcasting last night.
We ran a broadcast again last night. There were no errors in the log and it was still exhibiting quality issues on the transcoded stream. I don’t think it’s a bandwidth issue, we ran transcoding locally on the encoder for a full year before we switched to server side encoding and we didn’t have any bandwidth issues before. The server and encoder are on the same LAN connected at 1 Gbps. Our VM server is reasonably close to Server 1 on the Transcoding benchmark. We are just running a single transcode, 1.6 Mbps to 0.4 Mbps, and the CPU is only peaking at 40%. Is there anything else that I can check or update to help this?
PC Normal
PC Quality Drops
Android RTSP Quality Drops
Server Performance
Here are my encoding settings. I’m not running at any of those suggested resolutions, but the problem shows up on both Android and Flash player (JW player). I used to run these exact setting encoding both on Wirecast rather than using Wowza to transcode and I did not have issues with Android or Flash. The reason I am not using Wirecast for transcoding now is because sometimes we use a Teradek Vidiu for events which can only send one stream and I don’t want to have to reconfigure the server every time we have an event outside our main recording area.
Source from Wirecast
Codec: H.264
Resolution: 1280x720
Frame Rate: 30 fps
Av Bit Rate: 1500 kbps
Profile: High
Key frame every: 60 frames
Audio: 128 kbps
Transcode Settings
Codec: H.264
Resolution: 640x360
Frame Rate: 30 fps
Av Bit Rate: 450 kbps
Profile: Baseline
Key frame every: 60 frames
Audio: 128 kbps (passthrough)
From everything I read these settings should work fine and shouldn’t be taxing the server. The CPU shows that the server is not being taxed, but the quality is still poor. Is there anything else I can try?