Since I’m wanting to do RTMP to RTSP, is liverepeater-edge my solution?
Oh, I think the difference is that I need to take an existing RTMP stream from Akamai and use Wowza to convert it to RTSP. We’re not currently doing RTMP out of Wowza.
I do have RTP/Authentication/PlayMethod set to ‘none’.
It works enough to tell that there’s video there, but it’s so choppy that it’s unintelligible. I’m not sure what’s up.
Here’s the URL:
rtsp://live.hopetv.org:1935/live/HopeChannelNorthAmerica_1.stream
I get the same choppiness even with our lowest-bitrate stream, which is only 56 kbps, so I don’t think it’s due to bandwidth.
rtsp://live.hopetv.org:1935/live/HopeChannelNorthAmerica_4.stream
It’s very strange. If you take a quick look, you’ll see that the video is arriving in one-second-long, out-of-order pieces.
Okay, I just tried it, and it doesn’t seem to make a difference. I also tried increasing the rtpDePacketizerPacketSorterBufferTime from 500 to 5000 and it didn’t seem to change anything.
Okay, good point. I changed it back to 500.
I made the config change in VLC, and it doesn’t seem to have made a difference.
They’re actually live video streams, not VOD.
Does the fact that the server is chunking the incoming streams for Apple HLS have anything to do with with the weird RTSP output? Like maybe it’s getting confused and chunking to RSTP as well?
Did you find any solutions? I have same problem with live video, rtsp and VLC.
Hi piotrg. No, still no solution, unfortunately. I think at this point RTSP on Wowza isn’t ready for use in a production environment. Please let me know if you figure something out, because it’s still a problem for me as well.
What is the problem you are having? With Wowza Server 2.2.4.01 it should work great!
https://www.wowza.com/docs/wowza-streaming-engine-software-updates
I see your stream. You might try turning off B-frames or reduce them to 1 B-frame (in a row). There are problems with streams that have more than 1 B-frame in a row.
Charlie
Hi Charlie,
Thanks for the patch.
Here’s the RTSP stream from my EC2 instance running 2.2.4:
rtsp://live.hopetv.org:1935/live/HopeChannelNorthAmerica_1.stream
Here’s the same RTSP stream from an EC2 instance with the patch to 2.2.4.01:
rtsp://ec2-204-236-155-15.us-west-1.compute.amazonaws.com:1935/live/HopeChannelNorthAmerica_1.stream
There doesn’t seem to be a difference in the streams.
B-frames was already set to zero on my encoder. It certainly looks like a B-frame issue to me, but since B-frames are off, I’m not sure what’s causing the trouble.
I’m using the Inlet Technologies Spinnaker 5000.
I’m curious how you checked for the presence of B-frames. Is there a tool I don’t know about?
I’ve added a sort buffer like you specified above, but it doesn’t seem to make a difference.
What does the stream look like when using the QuickTime player? It is usually a lot better.
Verify that it is indeed baseline. You can pull in the stream (either rtsp re-stream or rtmp re-stream with .stream file) and turn on Cupertino packetizer. This will provide validation through the reporting of codec information in the log file.
Is this deprecated and replaced with the following? If not, what’s the difference?
Hello Charlie hasn’t been with Wowza for over 2 years and this post is very old- all the way back to 2011.
I would suggest you ask a brand new question in a new post as I am going to delete this one. Too much outdated information, but the jitter buffer article you referenced is current.
