Can someone from Wowza tell me which modules should be running on Wowza (not sure if it matters that it’s EC2 or not) in order for the best experience with Strobe Media Playback? I figure it wants to call something for bandwidth checking, so I’ve tried enabling FLVPlayback and Bandwidth modules on the Wowza instance, but I’m not see Wowza and/or Strobe do any stream switching with a F4M manifest. Any thoughts?
Are you using a smil file for multi-bitrate streaming? The versions have to be key frame aligned for switching. For live streaming Wirecast 4 should work, and for video on demand the best encoder is MS Expression 4, and there are some suggestions and presets you can use here:
BWCheck module is for rtmp streaming, it won’t work with Sanjose streaming which calculates bandwidth in other ways.
You can use the same smil file with Sanjose streaming. The url is:
The same smil file will work for Smooth and Cupertino
The contents of the smil is generic as shown in the multi-bitrate sections of the tutorials:
Sanjose is Flash HTTP streaming, segmented streams delivered over http similar to Cupertino and Smooth streaming. Sanjose is not “adaptive” by itself. You have to use smil file and multiple bitrate options for it to be adaptive, i.e., switch streams as conditions change.
We have a guide for the hosted Strobe player here:
Regarding RTMP dynamic vs HTTP multi-bitrate adaptive, a couple of things to consider. In IPhone at least I think it is the first item not the lowest bitrate that start first. Not sure about Flash HTTP or Smooth, but assuming those start with lowest bitrate first, it is faster.
Also, btw, the Wowza OSMF example player will do Sanjose single and multi-bitrate, and it does Flash dynamic streaming if you copy a smil file to the web server alongside the player and rename it with .xml extension and play like this: rtmp://[wowza-address]:1935/vod/myStreams.xml
From what I understand and experienced, http segmented streaming is better for adaptive switching because the ongoing calculations needed are a by-product of the segmented streaming.
Yes, copy the server-side smil file to the web server, in same location as the player, then change extension from smil to xml
The player could consumed the smil file, as long as the web server can serve it, but you have to add a mime type to do that so it was is easier to change to xml which works on all web servers I think. The contents of the file does not need to be changed.
The Wowza OSMF example player is mainly provided for Sanjose streaming, but the OSMF framework also handles dynamic streaming so we added this feature for good measure. It’s not documented, I don’t think it’s been mentioned before. Try it out. From my testing though, I think the JW player might do this better than the OSMF framework.
I thought the SMIL file implementation for Wowza was just for Cupertino and Silverlight HTTP adaptive streaming. For Flash, I’m using F4M files (not hosted on the Wowza server) that point to RTMP urls (Wowza based). For RTMP/Flash-based streaming, I’m presuming that I don’t need both FLVPlayback and BWCheck modules loaded for an application instance, as they probably conflict/override each others methods.
Thanks again, Richard. Is Sanjose streaming HTTP adaptive or RTMP adaptive? I’d prefer to use manifests with RTMP adaptive. Is there a distinction from the Wowza perspective?
Richard, thanks again for the reply. Flash RTMP adaptive is much responsive than Flash HTTP adaptive, and I was hoping I could build my own f4m manifests that use RTMP instead of HTTP. Strobe Media Playback (and other Flash-based players) can make a bandwidth check against RTMP to pick an optimized first stream, whereas HTTP delivery picks the lowest bitrate and then scales up from there. I’m already very familiar with Wowza’s SMIL based schema, as I’ve been using it on videoRx.com for the last eight months. If I generate my own f4m files using Wowza RTMP urls, is there any reason it shouldn’t work? I just implemented the HTTP Adaptive with my prototype here:
That’s using the smil:… /manifest.f4m you pointed out. If I use my own F4M with RTMP, such as http://s3.videorx.com/NDEQ1/adaptive_desktop.f4m, it works with Strobe Media Playback, but I’m getting random Error #1009 reported in Strobe on stream switches (same MP4 files in either case). Do you have any suggestions for why that would be the case with RTMP?
Also, has the API for IMediaStreamNameAliasProvider2 updated for Sanjose streaming, or does it just use the same HTTPStreamer methods that the others use? (I presume yes, but I wanted to ask to be sure.)
Oh, and you can test the RTMP f4m url I provided directly in the configurator for Adobe’s Flash Media Playback (pretty much the same thing as Strobe Media Playback, but hosted by Adobe):
Thanks again for the update, Richard. I’m curious about your OSMF player and your instructions to use smil/renamed-as-xml. So, if I have a working SMIL file on Wowza, I can put that on my web server? Why is the URL example in your post using rtmp:// if the XML file is on the web server and not the Wowza server? thanks again.
Well, I think i’m getting closer at the root of the problem. One of the ActionScript classes in OSMF uses the stream name to determine the index of the stream to switch to, and since I’m using stream aliases with Wowza, the path in my F4M manifest doesn’t match what Wowza returns as the full stream name at runtime. I guess that’s by design, right? I didn’t realize that if I have a stream name like “R4T21/My_Movie_Trailer.mp4” and then have my Wowza custom resolvePlayAlias return “mp4:amazons3/s3.videorx.com/R4T21/My_Movie_Trailer.mp4” that the Flash Player would actually get that path—i thought it was just used by the Wowza server internally to find the path to the file and then start streaming it to the client.