RTMPT keep alive & others

Hello,

I found Wowza really nice piece of software, but of course as a beginner user I have some problems and questions about it.

  1. How Wowza treats ICY protocol data in shoutcast mode? It only separates audio data and metadata from ICY and put this stuff into RTMP protocol fields? Is audio data untouched (any encoding/decoding mechanism)? I have icecast server streaming audio in ACC+v2 encoding and I want to know if “support for HE-ACC” means that ACC+ in version 2 (not onlly v1) is supported.

I configured Wowza to re-stream this aac+v2 audio and it looks that everything works good, but I want to be sure that there is no quality loss in e.g. treating AAC+v2 as AAC+v1 stream (which probably should work but sound quality will be lower).

  1. Also when I configured this all ICY restreaming stuff i want to measure bandtwith differences between original ICY and RTMP and RTMPT. So I have about 30kbps ICY stream, it looks that RTMP is almost the same (30 kbps) but I have really strange results for RTMPT (about 120kbps for the same stream!).

I call RTMP by url:

rtmp://localhost:1935/shoutcast

and RTMPT by url:

rtmpt://localhost:1935/shoutcast

I dumped some packets using tcpdump/wireshark and I saw that every request in RTMPT communication is made in new connection! So it looks that keep-alive is ignored in flash client or something?. I am using this example shoutcast flash player distributed with wowza. Keep-Alive is turned on server side in Wowza (I also see “Connection: Keep-Alive” in dumped HTTP packeds in response from Wowza). Am I doing something wrong? This 120kbps bandtwidth is not acceptable.

  1. I saw that I can define my own modules in Wowza, really cool! I want to create module which will work with shoutcast re-streaming and will add some “intro sound” for every user which connects to Wowza. It is possible? I saw method “addAudioData(byte[] data, int offset, int size)” in IMediaStream interface - will it work when I connect to onStreamCreate event and addAudioData some aac+v2 bytes with “intro sound”??

That’s all for now, thanks in advance for help.

Cheers,

Kamil

  1. How Wowza treats ICY protocol data in shoutcast mode? It only separates audio data and metadata from ICY and put this stuff into RTMP protocol fields? Is audio data untouched (any encoding/decoding mechanism)? I have icecast server streaming audio in ACC+v2 encoding and I want to know if “support for HE-ACC” means that ACC+ in version 2 (not onlly v1) is supported.

It does separate audio and metadata. Take a look at the examples/SHOUTcast example to see how it deals with metdata. It does support AAC+. We do not touch the audio packets. We are re-streaming them over RTMP.

  1. Also when I configured this all ICY restreaming stuff i want to measure bandtwith differences between original ICY and RTMP and RTMPT. So I have about 30kbps ICY stream, it looks that RTMP is almost the same (30 kbps) but I have really strange results for RTMPT (about 120kbps for the same stream!).

I call RTMP by url:

rtmp://localhost:1935/shoutcast

and RTMPT by url:

rtmpt://localhost:1935/shoutcast

I dumped some packets using tcpdump/wireshark and I saw that every request in RTMPT communication is made in new connection! So it looks that keep-alive is ignored in flash client or something?. I am using this example shoutcast flash player distributed with wowza. Keep-Alive is turned on server side in Wowza (I also see “Connection: Keep-Alive” in dumped HTTP packeds in response from Wowza). Am I doing something wrong? This 120kbps bandtwidth is not acceptable.

RTMPT is more chatty. I am suprised it is that much additional overhead. We do properly deal with KeepAlive. Not sure why the browser is ignoring it. I would expect maybe a 15% increase in bandwidth with RTMPT. Are you sure it is a new connection for each packet. There will be a new header for each packet. I would not expect to see a new connection. I would not expect a 400% gain. Something is not right. RTMPT is really just the same packets with an HTTP header.

  1. I saw that I can define my own modules in Wowza, really cool! I want to create module which will work with shoutcast re-streaming and will add some “intro sound” for every user which connects to Wowza. It is possible? I saw method “addAudioData(byte data, int offset, int size)” in IMediaStream interface - will it work when I connect to onStreamCreate event and addAudioData some aac+v2 bytes with “intro sound”??

Doing pre-roll using server side Java code is not practical or necessary. It is much easier to just play a static MP3 file using the NetStream.play command, wait for it to complete then play the radio stream. It is a few lines of client side Flash code.

Charlie

  1. There is not a practical way to do it server side. Client side is the way to go.

  2. Take a look at the stream name alias package:

http://community.wowza.com/t/-/47

Charlie

I know that on client side it is easy, but I want this “intro sound” logic on server side. There are many intro sounds, and I want to decide for each user which intro should be played. Also there might be couple of different clients so duplicating this logic on every client does not look good.

Do you think that it is wrong idea? If not, how to implement this on server?

Implementing a preroll client side is very easy. You would not be duplicating logic. You can decide which preroll to play server side and just send the command to play the content from the player. It is very simple. It is as easy as creating a NetStream object and executing the play method to start the content. You can use the onPlayStatus event to monitor the end of the stream.

Charlie

RTMPT is more chatty. I am suprised it is that much additional overhead. We do properly deal with KeepAlive. Not sure why the browser is ignoring it. I would expect maybe a 15% increase in bandwidth with RTMPT. Are you sure it is a new connection for each packet. There will be a new header for each packet. I would not expect to see a new connection. I would not expect a 400% gain. Something is not right. RTMPT is really just the same packets with an HTTP header.

I see TCP FIN and SYN packets for every RTMPT packet and increasing client port numbers for connections so it seems that it is connection per packet. For me, this 400% gain also looks very strange but it is fact on my computer (ubuntu, firefox + flash 9). Do you have any ideas what is happening wrong? This Shoutcast example flash player is respecting keep-alive connection without any additions?

Doing pre-roll using server side Java code is not practical or necessary. It is much easier to just play a static MP3 file using the NetStream.play command, wait for it to complete then play the radio stream. It is a few lines of client side Flash code.

Charlie

I know that on client side it is easy, but I want this “intro sound” logic on server side. There are many intro sounds, and I want to decide for each user which intro should be played. Also there might be couple of different clients so duplicating this logic on every client does not look good.

Do you think that it is wrong idea? If not, how to implement this on server?

Cheers,

Kamil

I see TCP FIN and SYN packets for every RTMPT packet and increasing client port numbers for connections so it seems that it is connection per packet. For me, this 400% gain also looks very strange but it is fact on my computer (ubuntu, firefox + flash 9). Do you have any ideas what is happening wrong? This Shoutcast example flash player is respecting keep-alive connection without any additions?

It looks that it is problem on ubuntu (maybe all linux distros) because on windows with firefox everythink looks OK, I see one connection and bandtwith is about 50kbit/s which is acceptable.

I know that on client side it is easy, but I want this “intro sound” logic on server side. There are many intro sounds, and I want to decide for each user which intro should be played. Also there might be couple of different clients so duplicating this logic on every client does not look good.

Do you think that it is wrong idea? If not, how to implement this on server?

Please, could you post opinion on this “intro stuff” which I explained above? How to do that on server side?

Cheers,

Kamil

Implementing a preroll client side is very easy. You would not be duplicating logic. You can decide which preroll to play server side and just send the command to play the content from the player. It is very simple. It is as easy as creating a NetStream object and executing the play method to start the content. You can use the onPlayStatus event to monitor the end of the stream.

Charlie

  1. Ok, I understand that it is very easy on client side, but IF I want do this on server side, it is possible? And how? My first idea of using addAudioData will work? How to use it?

  2. Second question: Example flash client which is distributed with WOWZA has field where I have to write url for shoutcast server, is this possible to configure this url on server side (not even hardcoding this on client)?

Thanks for replies,

Kamil