First of all - I am new to Wowza and if the question I ask is somewhat idiotic or it has been answered somewhere - sorry, don't kill me :)
I am trying to re-stream a RTMP stream to iOS device. I did my setup following the tutorials and pretty much got the stream working. But here is the interesting part - the audio was perfect, but video was very very choppy. Unfortunately I cannot demo it, because the server is internal, but to put it in words - every second you see the frames go 1,2,3,..,24 and back to the first. Then comes the next pack. Something like that.
For the sake of experiment I did setup the same input stream via ffmpeg and a segmentizer and got it working perfectly. But I am kinda curious why it doesn't work with Wowza? Any ideas what settings I could try to play with?
I have no control over the input stream. It does come from another Wowza server. I tried accessing the m3u8 file on the original server and the result was the same - video was not good. I could not make it work with other RTMP streams (did not even get it to start - I just can't figure what should I use for [stream-name] in the URL?!) so maybe the problem is with the input stream?
And if that sounds a bit messy I will put it this way - has anyway seen such a problem or has anyone made live rtmp->http streaming work?
My first guess would be the h264 encoding inside the original stream. Is it the playback on the iPhone that is choppy? I would also trying playing the video with quicktime on OSX (although this may use the same HLS player as iOS) or try playing the original stream over RTSP/RTMP and making sure it looks fine there as well.
If the origin is not Wowza (FMIS most likely), then still use StreamType "liverepeater-edge" but set LiveStreamPacketizers to "cupertinostreamingpacketizer", if you want to playback on iOS. The idea is that packetizing has to happen somewhere once (only). In an all Wowza liverepeater system it is most efficient to do it in the origin, but otherwise you can do it on the edge.
To better understand Liverepeater, avoid using originURL for the moment because it obscures what the stream really is on the edge: restreamed rtmp where the actual stream name takes the form: