Thanks for the info.
Charlie
Install this patch (be sure to update the config files in the conf folder of the patch):
WowzaMediaServer2.0.0-patch9.zip
Charlie
OK, let’s back up. Describe in detail your setup. what are you trying to do? What type of content are you trying to stream. What is the whole story?
Charlie
Again, as noted on the support email, you have to supply a 64bit version. Take a look at the multi-bitrate Video On Demand sections of these guides:
Video on Demand
http://www.wowza.com/community/t/-/64
Live Streaming
https://www.wowza.com/docs/how-to-set-up-live-streaming-using-an-rtmp-based-encoder
And apply the latest patch in any case.
Richard
Okay. I suggest you apply the latest patch, and supply a 64kbs version, then see if that gets accepted.
Richard
As far as I know, you should be referencing a smil file following the guide:
https://www.wowza.com/docs/how-to-set-up-live-streaming-using-an-rtmp-based-encoder
I add a 64kbs option:
<smil>
<head>
</head>
<body>
<switch>
<video src="myStream_700" system-bitrate="700000"/>
<video src="myStream_350" system-bitrate="350000"/>
<video src="myStream_200" system-bitrate="200000"/>
<video src="myStream_64" system-bitrate="64000"/>
</switch>
</body>
</smil>
That would seem to take care of the warning:
WARNING: The playlist should use relative URIs to reduce its size.
Richard
As far as I know you can do both. Serve a smil file with playlist.m3u8 like this:
http://[wowza-address]:1935/[appName]/smil:yourSmil.smil/playlist.m3u8
Where “yourSmil.smil” is a smil file in the Wowza content folder along-side the videos.
Richard
We cleared up the error
ERROR: Playlist must have at least 3 media URIs if it does not have an ENDLIST tag.
by changing the value of chunk count from 2 to 3 in the Application.xml
(LiveStreamPacketizer/Properties/Property/playlistChunkCount)
From Figmented’s report:
ERROR: Invalid response from the validator helper: a track is missing the ‘type’ property.
6: media_22.ts?wowzasessionid=1357219487
According to Apple’s HTTP Live Streaming Overview pdf, page 12, it says the m3u8 files should be ‘application/x-mpegURL or vnd.apple.mpegURL’
Figmented’s report says it should be either ‘application/vnd.apple.mpegurl’, ‘audio/x-mpegurl’ or ‘audio/mpegurl’
I’ve patched my 2.0 installation with patch9, and when I wget -S the m3u8 files with a wowzasessionid and without I get the following:
HTTP request sent, awaiting response…
HTTP/1.0 200 OK
Date: Wed, 03 Mar 2010 22:03:10 GMT
Content-Type: application/vnd.apple.mpegurl
Server: FlashCom/3.5.2
Cache-Control: no-cache
Content-Length: 146
Length: 146 [application/vnd.apple.mpegurl]
I’ve patched up to patch9 but there is the lingering ‘type’ error.
Ah, my apologies. I’m a coworker with Figmented. We’re trying to get an iphone app passed that has live streaming video.
We had the app rejected with vague details on what didn’t pass inspection. From what we could tell it’s the video part that’s holding it up.
We’re using Wowza 2.0 (patched today to patch9). One of the techs pointed us out to the stream validator program. Its output is a little vague but we believe that there were two problems:
- Our Application.xml had a chunk count of 2 but Apple wants 3 (or more) for live streaming.
- It said we needed a baseline stream of 64k +/- 10%. This is to accommodate both wifi and 3G connectivity.
- It says the ‘type’ of the media_XXX.ts chunk is missing or invalid. According to the docs, it needs to be application/vnd.apple.mpegURL or similar. According to wget -S the mime type should work
I think you hit the nail on the head. We re-enabled audio and that ‘type’ problem of the .ts files goes away.
While we were initially trying to troubleshoot the problem we limited bandwidth to 60k, then 32k, then 48k. To get the best video quality we disabled audio.
It turns out to pass inspection from the mediastreamvalidator program with a live feed you need audio or audio+video at 64k and a chunk count of 3.
Wow, a total of 64k for audio & video? That’s gotta look & sound just wonderful.
I wonder how many people actually continue to run that rate after getting in the appstore?
–Chris
Well in the documentation, Apple says you can have multiple feeds each at a different bitrate. But it’s mandatory that you have at least an audio, audio+video, or audio+image feed at 64kbps for 3G users.
That’s cool.
We fixed the .ts ‘type’ problem by using both audio and video. If video only is not an option then here’s at least a workaround.
We will let you know if our app gets approved. Thank you for the help.
We got our app passed. It seems it was just being held up by those little things mentioned earlier in the thread.
Wow, a total of 64k for audio & video? That’s gotta look & sound just wonderful. 
I wonder how many people actually continue to run that rate after getting in the appstore?
–Chris
Apple are quite picky when it comes to live streaming over 3G. So far by using their validator I have found the 3 stream process mentioned in their live FAQ is the only thing that passes without too much of a fuss with the audio only streaming being the lowest bit rate.
You can also reduce the warnings generated by modifying your playlist to take into account what the http overhead will be.
I once submitted an app with only 42K video + audio, it got rejected so it really seems to be down to the adaptive bit rate playlists which dictacte if you will pass or not.
hi charlie,
i’m having same problem with app store…rejects because the 64 kbps…the patch will solve my problem too?
see my m3u8
regards,
