I am using a transcoder stream name group for Apple HLS streaming. It works, but the Apple mediastreamvalidator tool doesn’t like the reported bitrate in the playlist vs. the actual average bitrate ie. it is exceeded by more than 10%. Is there a way that I can change the bitrate tag in the playlist to be different than what the transcoder is targeting, or otherwise fix this problem? Thank you 
If you adjust the system-bitrate to what the validator is reporting, you won’t get that warning.
Salvadore
It is difficult to say why the ngrp MediaList system-bitrate is not agreeing with the validator, but reverting to a smil to give you the control you need to adjust to it is a good solution.
Richard
It would probably have something to with the source. The bitrate of Wowza Trancoder renditions are variable but constrained within limits. If you enable “cupertinostreamingpacketizer” in the Application.xml /LivestreamPacketizers list (or in the Manager Application setup), then Wowza will log the first 10 chunks it packetizes for HLS, and you can look at those in the log file, see how many audio, video and key frames (a/v/k) are in each chunk, and their duration, Or you can use JW player’s HLS playback and look at details of each .ts chunk in the Console > Network tab, which is nice because you can see size and download time, and you can download the chunks directly.
You can look at chunks being created from the source, and ones created from a rendition. You might look at source with Transcoder turned off, and look at one rendition at a time when you turn it on
Richard
It looks okay. Each chunk is very uniform, most are 10.3 seconds, with 4 key frames, and 116 video frames. They are probably close to the same size. So there is not apparently higher bandwidth. But these chunks are delivered as fast as possible, they are not throttled like RTMP, which might be what you are seeing?
You can add maxChunkLogCount Property to the Application.xml /LiveStreamPacketizer Properties container set to “0”, Wowza will log all chunks (be sure to disable in production), so you can see this data for the entire stream. It looks fairly consistent, but look at the a/v/k and duration numbers to verify.
<Property>
<Name>maxChunkLogCount</Name>
<Value>0</Value>
<Type>Integer</Type>
</Property>
Richard
You can download the chunks, which is shown in this guide, and you can see .ts chunks downloading in JW Player (in premium or enterprise versions when doing HLS on desktop) in the browser console, which shows size and download time.
Richard
Try changing the cupertinoChunkDurationTarget. The default is 10000 (10 seconds) and you can see the target is being hit sometimes, but inconsistently, which means the key frame frequency is not a factor of 10 seconds. If the key frame frequency is 3 seconds (the default for FMLE, e.g.) then setting chunk target to “3000” will result in even 3 second duration chunks. The duration in the previous log snip you sent was more consistent.
Richard
Are you just trying to satisfy Apple App Store requirements for a 64kbs stream? The best way to do that is encode with a 64kbs audio channel and use this Wowza technique to extract just the audio into a separate stream, provided along with the video and audio stream in a MediaList (smil file). Or if you already have multiple renditions you can add this to your own .smil file, as shown in that guide.
Richard
For that test, I would use the audio track extract method. The audio track is going to be a steady bitrate. If you really want your low stream to include video, you can continue to work on that, but fluctuation in video is normal.
Richard
What encoder are you testing with, and video encoding settings? If I can replicate the source locally I can knock it around.
There are these Transcoder params that may (depending on your system) include CBR related settings, which might be worth looking at and experimenting with, however, they have not seemed very effective in my own tests and customer reports. These params are undocumented and easy to misuse.
Richard
You do have the setting available, and I will show you how to use it, but, again, it has not worked as hoped in some reports. It is mainconcept.bit_rate_mode, which is defaults to H264_VBR (2). The options are: 0=H264_CBR, 1=H264_CQT, 2=H264_VBR or 3=H264_TQM
INFO 200 - # long: bit_rate_mode: bit rate stuff: 0=H264_CBR, 1=H264_CQT, 2=H264_VBR or 3=H264_TQM
INFO 200 - mainconcept.bit_rate_mode: 2
So you will add this to one or more of you transcoder template’s /Encode /Paramaters
<Parameter>
<!-- 0=H264_CBR, 1=H264_CQT, 2=H264_VBR or 3=H264_TQM -->
<Name>mainconcept.bit_rate_mode</Name>
<Value>2</Value>
<Type>Long</Type>
</Parameter>
Richard
Great! Glad that helped. Thanks for the update and info.
Richard
Yes, you will need to do this test within a .smil file.
Salvadore
If you adjust the system-bitrate to what the validator is reporting, you won’t get that warning.
Salvadore
Sorry, does that mean I need to use a SMIL file? Right now I’m just using a transcoder stream name group and I can’t find any examples where the system-bitrate is configured in a transcoder template.
I have a large number of streams and by using ‘ngrp’, I can easily make one template that can be used for all of the streams by string matching in the URL. It looks like with SMIL files I have to actually go and make a SMIL file for every single stream, and if I want to change the settings, I would have to change all of the SMIL files for every stream. So it’s really too bad that I can’t do this with ngrp 
For the first ~5 segments after the stream starts, the bandwidth used is greatly higher. For example I have a stream that passes validation when I set the SMIL bitrate to 63Kbps, but it fails if I try to validate soon after the stream is started, with bitrates of around 180-200Kbps. Why does this happen?
Thank you. I have been looking at the log trying to find useful information, but if it’s there I don’t know how to see it. This is the log of the packets being made; 22503.stream is the source and 22503.stream_050 is transrated to 50 Kbps video.
2014-04-17 14:11:21 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.init[mobile-phone-hls/_definst_/22503.stream_050]: chunkDurationTarget: 10000 - - - 4.566 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:21 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.init[mobile-phone-hls/_definst_/22503.stream_050]: audioGroupCount: 3 - - - 4.566 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:21 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.init[mobile-phone-hls/_definst_/22503.stream_050]: playlistChunkCount:3 - - - 4.567 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:21 PDT comment server INFO 200 - MediaStreamMap.getLiveStreamPacketizer[mobile-phone-hls/_definst_/22503.stream_050]: Create live stream packetizer: cupertinostreamingpacketizer:22503.stream_050 - - - 4.567 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:21 PDT comment server INFO 200 - CupertinoPacketHandler.startStream[mobile-phone-hls/_definst_/22503.stream_050] - - - 4.568 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:21 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.handlePacket[mobile-phone-hls/_definst_/22503.stream_050]: Video codec:H264 isCompatible:true - - - 4.569 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:21 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.handlePacket[mobile-phone-hls/_definst_/22503.stream_050][avc1.66.21]: H.264 Video info: {H264CodecConfigInfo: codec:H264, profile:Baseline, level:2.1, frameSize:320x240, displaySize:320x240, frameRate:12.0, PAR:1:1} - - - 4.57 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:23 PDT comment server INFO 200 - firstPacket: TCP:$1 - - - 6.257 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:31 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:1 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10397 - - - 13.97 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:31 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:1 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10397 - - - 14.763 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:41 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:2 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 24.333 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:42 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:2 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 25.115 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:51 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:3 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 34.598 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:11:52 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:3 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 35.398 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:02 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:4 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 44.918 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:02 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:4 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 45.677 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:12 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:5 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 55.276 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:13 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:5 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 56.03 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:20 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:6 mode:TS[H264,NOAUDIO] a/v/k:0/87/3 duration:7758 - - - 63.04 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:20 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:6 mode:TS[H264,NOAUDIO] a/v/k:0/87/3 duration:7758 - - - 63.83 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:30 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:7 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10397 - - - 73.389 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:31 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:7 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10397 - - - 74.182 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:40 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:8 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 83.709 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:41 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:8 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 84.459 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:51 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:9 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 94.072 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:12:51 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:9 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 94.886 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:13:01 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:10 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 104.391 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:13:02 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:10 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10317 - - - 105.162 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:13:11 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream]: Add chunk: id:11 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 114.667 - - - - - - - - - - - - - - - - - - - - - - - - -
2014-04-17 14:13:12 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.endChunkTS[mobile-phone-hls/_definst_/22503.stream_050]: Add chunk: id:11 mode:TS[H264,NOAUDIO] a/v/k:0/116/4 duration:10318 - - - 115.439 - - - - - - - - - - - - - - - - - - - - - - - - -
I tried viewing the stream in safari with JW player and I couldn’t see the chunks under Network Requests. Were you talking about the console in Safari or something else?
I’m packetizing both the source stream (~300 kbps) as well as that stream transrated to 50 kbps video by Transcoder. When viewing the log, the a/v/k counts are the same for both of these but the source stream uses higher bandwidth. So isn’t there another factor in determining the size of the chunks other than a/v/k?
Thank you, I was having trouble figuring out how to view the chunks. Here are the results for the first 10 chunks:
Duration Transrated Non-transrated
Name (sec) Size(KB) kbps Size(KB) kbps
media_1.ts 2 52 208 69 276
media_2.ts 10 265 212 275 220
media_3.ts 10 252 201.6 278 222.4
media_4.ts 10 204 163.2 276 220.8
media_5.ts 10 77 61.6 277 221.6
media_6.ts 10 77 61.6 281 224.8
media_7.ts 10 77 61.6 280 224
media_8.ts 10 79 63.2 279 223.2
media_9.ts 7 58 66.3 212 242.3
media_10.ts 10 79 63.2 281 224.8
For comparison I recorded the chunks packetized without any transrating.
This matches up with what the mediastreamvalidator was reporting-- the first 4 chunks are larger before the kbps becomes uniform. Where can I go from here?
I did a bunch of experiments changing the chunk duration target as well as camera stream settings. Even when I get the chunk duration and video/key frames to be consistent, it still takes ~30-70+ seconds depending on settings before I can get the kbps to be within 10% of 64kbps. Comparing two chunks, one near the stream start and one after this 30-70 sec period, they can have the exact same duration and a/v/k counts but have different data sizes. Is there anything else that I can try to enforce a bitrate cap on the transcoder output or at least decrease the amount of time before it stabilizes?