Oddity since upgrading to Wowza 4

Wowza Streaming Engine
1

I upgraded from wowza 3.x to 4.x this weekend and the first live video streams I did, I noticed pixelation and “smearing” of the video. Now, my understanding is that wowza is and has always taken the video data repackaged it in the correct container (HLS) in this case and sent it along. (Not using the transcoder etc). However I saw this issue on live streams as well as VOD streams where I had not before. I can easily reproduce it on my Nexus 5 using HLS. But I have had people reporting it on iPads and on websites via JW player Pro using HLS.

If I request the MP4 directly from the server using Apache to host it, the video plays as expected. If I request the same file utilizing wowza things start to look odd. I believe it is related to the key frames at 2 seconds but this was not an issue I ever recall seeing in wowza 3.x

direct file link:

http://simplethoughtproductions.com/data/hosted/encoder/RMBBALLVsFLSouthernOvertime/video-hd.mp4

Wowza 4.x link:

http://stream.simplethoughtproductions.com/simplevideostreaming/b/data/hosted/encoder/RMBBALLVsFLSouthernOvertime/video-hd.mp4/playlist.m3u8

Link to a segment where I see the issue:

http://stream.simplethoughtproductions.com/simplevideostreaming/b/data/hosted/encoder/RMBBALLVsFLSouthernOvertime/video-hd.mp4/media_w357834901_5.ts

Example of issue via HLS:

Best description I can give is that the keyframe isnt actually being put at the start of the new segment.

Thanks,

-Josh C.

2

Hi Josh, are you using Wowza 3.x config files with Wowza 4.x? This is not recommended as it can cause unexpected behavior. Previous config files should be used as a reference for creating new config files.

If this is not the issue, it could be a bitrate vs available Bandwitdh issue, and lowering stream quality may help. You could test this theory by playing the stream locally to eliminate the possible bandwidth limitation.

Another idea is to provide ABR streaming, to provided the highest quality stream that the client’s bandwidth can handle:

How to do adaptive bitrate streaming

Salvadore

3

Josh,

That looks like FFprobe or FFmpeg output, which is the same output I see from HLS streams also, and is similar to what you see in FFprobe from analyzing one of the .ts chunks.

Input #0, mpegts, from ‘c:\temp\media.ts’:

Duration: 00:00:11.21, start: 10.000000, bitrate: 645 kb/s

Program 1

Stream #0:0[0x102]: Unknown: none ([21][0][0][0] / 0x0015)

Stream #0:1[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p, 424x240, 24 fps, 24 tbr, 90k tbn, 48 tbc

Stream #0:2[0x101]: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 107 kb/s

It’s not a problem

Richard

4

Josh,

Did you have these cupertino settings previously?

Try setting cupertinoChunkDurationTarget to “2000”. As I understand FFprobe, you have a two second key frame frequency (tbc/fps) and should get 2 second duration chunks with that setting.

Richard

5

Josh,

Let’s move this over to a support ticket so we can take a closer look. Zip up conf and recent access logs showing your test and send them to support@wowza.com. Include link(s) to players showing your streams, and include a link to this thread for reference.

Thanks,

Richard

6

What are the encoding details? Do you have b-frames turned on? Do you know what the key frame frequency is? A two second key frame frequency seems to be ideal. See if you can modify the encoding to achieve that, and try without b-frames if you are using that. Key frame frequency is key frame interval (or gop) / FPS. So if key frame interval is 48 and FPS is 24 the stream will have a two second key frame frequency.

Richard

7

Hi,

I installed a fresh copy of Wowza 4.x. All of the events I do are ABR. This does not appear to be a case of not enough bandwidth (you see buffering) not glitches like this usually. The closest thing I have seen to this is UDP streaming when you lose data packets. With that being said, you can download the segment I provided (removing bandwidth). And see the same glitch when you play it in VLC as well as a number of the segments. If you download the MP4 that is the same source for Wowza and Apache you will no longer see the issues. I am trying to inspect the segments as it really appears to be an issue where segments are not correctly starting with iFrames.

Thanks,

-Josh C.

8

Yes it does:

I am using the default installed VOD app to play back. To be clear. I see this in lots of places now and I never saw it before. Live streams being encoded via Wirecast at 720P 2Mbit to Wowza and Transrated to lower bitreates (all renditions show the glitching randomly), vod on assets I have used for months without issue prior to the upgrades, and finally on the demo video. Load on server is low at the glitches and they are repeatable so I do not think it is load related as it would likely be more random. The glitch below was repeatable at that time stamp on my Nexus 5. In live streams I have not noticed it nearly as frequently but I did get a few reports of “really blocky video” during my last few live streams despite confirming they were watching the the 720P stream. They confirmed that it was similar to the screen shots posted above when I showed them.

One thing I had not noticed before on wowza 3.x (may have been there all along) is an extra data stream when using HLS over the direct mp4:

Stream 0.0 is unknown etc:

Input #0, hls,applehttp, from ‘http://stream.simplethoughtproductions.com/vod/sample.mp4/playlist.m3u8’:

Duration: 00:09:35.00, start: 10.000000, bitrate: 0 kb/s

Program 0

Metadata:

variant_bitrate : 572079

Stream #0:0: Unknown: none ([21][0][0][0] / 0x0015)

Metadata:

variant_bitrate : 572079

Stream #0:1: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p, 424x240, 12 fps, 24 tbr, 90k tbn, 48 tbc

Metadata:

variant_bitrate : 572079

Stream #0:2: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 107 kb/s

Metadata:

variant_bitrate : 572079

Vs the direct MP4:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘http://simplethoughtproductions.com/data/sample.mp4’:

Metadata:

major_brand : qt

minor_version : 512

compatible_brands: qt

creation_time : 1970-01-01 00:00:00

encoder : Lavf52.73.0

Duration: 00:09:56.46, start: 0.000000, bitrate: 524 kb/s

Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 424x240, 420 kb/s, 24 fps, 24 tbr, 24 tbn, 48 tbc

Metadata:

creation_time : 1970-01-01 00:00:00

handler_name : DataHandler

Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 99 kb/s

Metadata:

creation_time : 1970-01-01 00:00:00

handler_name : DataHandler

9

Ok, thanks for the extra info. Still driving me mad trying to figure out why the live streams and VOD files that did not have issues with wowza 3.x are having them with 4.x (only change I made this weekend).

Thanks,

-Josh C.

10

Yes, I stuck with the Apple suggested 3 Segment size for live with 10 second chunks (divisible by the 2 second keyframe encoding that I utilized). The VOD was 10 second segments until I hit the end of the file so the setup is very similar if not the same. I backed up my conf files and I am reviewing them now to see if I can find any differences but so far I have not.

11

rrlanham,

Considering that the sample video and default vod app show this behavior there is something else going on?

Thanks,

Josh C.

12

Done.

Request #85928

13

For those following along a resolution has been found:

cupertinoOnChunkStartResetCounter

false

Boolean

This was defaulted to true in the 4.x update and was the culprit. After setting this off the issue went away.

It was most apparently in Android devices but I have seen it as well as had reports of the same issue when using JW Player’s HLS so hopefully this will resolve that as well.

Thanks,

-Josh C.

14

Do you see the same odd results when testing playback of sample.mp4?

Salvadore

15

I have this problem for months, previously posted here

@support: Can you provide more info why this issue exists and how exactly to solve it.

Josh’s post says to use the above code

[COLOR=#333333]<Property>[/COLOR]
[COLOR=#333333]<Name>cupertinoOnChunkStartResetCounter</Name>[/COLOR]
[COLOR=#333333]<Value>false</Value>[/COLOR]
[COLOR=#333333]<Name>Boolean</Name>[/COLOR]
[COLOR=#333333]</Property>[/COLOR]

, where exactly does this properties go in the xml configuration?

Should I put it in LiveStreamPacketizer/Properties or…?

Regards,

16

Ok I found out that it goes in LiveStreamPacketizer/Properties if you use origin/edge the properties should be on the origin server.

Do you have idea why the same issue exists with the nDVR, on chunk change the pixelization appears, it was present in version 3.x and now also in 4.x?

Regards,