Sorry if this is a noob question, but I can’t seem to find the answer in the documentation anywhere. It talks about packetizers and HTTPStreamers, but never really tells you exactly what they do. For example, to get Apple’s HTTP Live Streaming to work, you need to break an H.264 stream down into small file chunks. Is it the packetizer or HTTPStreamer that does this? Also, how much knowledge of the underlying video format do packetizers have? I don’t think they can transcode between video formats (right?), but in order to break an H.264 stream into file chunks, you need to have some knowledge of the underlying format, like where the edge of a frame is, which are key frames, and how many FPS the video is at. Does the packetizer have a knowledge of the H.264 video format? Does the HTTPStreamer?
The packetizer breaks the H.264/AAC/MP3 stream into chunks and wraps them in MPEG-TS. The HTTPStream does the delivery. Yes, we do inspect the H.264 just enough to so that we can find key frames. We also look at the SPS and PPS NAL units to determine the profile, level and frame size of the video.
Charlie
We really don’t have any sample code for how to setup on the fly transcoding. The Publisher API (see the server-side API guide) is the way to inject raw media packets into the server. This would required advanced Java and media skills.
Charlie
Yes, WowzaMediaServer_ServerSideAPI.pdf. Again, we don’t have detailed instructions. The closets we have is the server-side API guide and this post that illustrates audio injection using Speex:
http://www.wowza.com/forums/showthread.php?t=7100
Charlie
You have to consider 2 things when you’re looking at a video format; the underlying video codec, and the container format. RTMP is going to support Spark, VP6, and maybe H.264 (though maybe not). HTTP Live Streaming is going to support only H.264. An RTP stream could come in as MPEG1 video.
Here’s my fundamental problem: Wowza seems to support transforming input from one container format into output to multiple different container formats. But that’s only one half of what must be considered, the other being the underlying video format. It doesn’t support changing that.
So, what you’re really stuck with when it comes to officially-supported stuff is receiving H.264 video, and outputting… H.264 video… to multiple different container formats. You could rename it, H.264 Media Server. Trouble is, I’m receiving video in a different underlying format (MP4V-ES), and need to output to different underlying formats (H.264 and Spark in the case of RTMP). Wowza wasn’t designed to do that. 
How feasible, though, do you think it would be to implement that functionality using Java modules to extend Wowza, with Xuggler (a Java wrapper for ffmpeg) for the transcoding? The documentation for Java modules seems to consist mostly of Javadoc stuff, with nothing in the way of tutorials about how to do anything like this.
I think, by the way, that you should make more of an effort to emphasize that you really need to have H.264 as the underlying video format to do any of the officially supported stuff in Wowza. I suspect much of people’s confusion comes from the fact that you’re just saying you can “take in RTP and output RTMP and Smooth Streaming” (yeah, I know H.264 is mentioned, but it feels like an aside rather than a fundamental point), which is a bit like saying that the human body can take in chemical energy and output kinetic and heat energy. The specific types of chemical, kinetic, and heat energy are very important. Don’t try ingesting coal and moving at 100MPH; likewise, don’t try putting Spark into Wowza and getting H.264 and MPEG1 out.
We already do transcoding with Red5. We just want to do what we do now, but also with HTTP live streaming support.
Are you referring to the WowzaMediaServer_ServerSideAPI.pdf file that comes with Wowza (less of a guide and more of a reference)?
I think it’s pretty clear from their docs that you really should be shipping in h.264 to Wowza.
However, i can understand why many would want to transcode. The issue is, transcoding generally sucks down major amounts of CPU. It’s fine if you’re only transcoding a few streams here and there to do some software based transcoding on the server. However, I think far too many people would try to transcode every stream and then they’ll whine about performance being an issue.
–Chris
