The iPad issue with Livu has been resolved in iOS 5. Upgrading to iOS 5 will allow the use of Livu on the iPad without any issues. I have also fixed the issue with streaming from the front camera. The video stream is no longer mirrored. I will push an update within the next couple of weeks.

I have noticed an issue with Livu and wifi. Sometimes I can stream at a full 3.5Mbps over wifi, and other times I can barely get 500Kbps consistently out of the device. I tested two different routers, and both had the same issue. I then setup a test with a 1Mbps H264 encoding rate. Wifi would cap out arond 600Kbps. 3G did not exhibit the same issue. Also I noticed that Wifi would bounce around a lot. This leads me to believe there is an issue with Wifi on the iPhone 3GS/4. Someone also has said they have the same issue with the iPod Touch 4G.

I did some testing and found that the send function for a BSD socket is getting blocked for a long time. I dug out the TCP Control Block to calculate the usable send window. I know for a fact there is enough space in the TCP buffers to send out the data. Something else is going on in the iOS kernel. I will have to do some profiling with the iOS 5 SDK as the new Instruments has a network profiling module. Unfortunately I will not be able to install iOS 5 until it is released.

Further testing has shown this problem is mostly with TCP. When using UDP there is some packet loss, but for the most part the stream stays together.

I really messed up and submitted the wrong archive. Last time I keep beta archives in my list. I have asked for an expedited review, so with a little luck the update will be ready tomorrow. I have pulled Livu from sale, so other people that have not updated and new customers will not be effected by this. The main issue was you could not select the video size of the stream.

I have submitted 1.2.0 for review. It should be available next week. Whats new is:

Auto restart on network failure.

Audio, Video or Audio/Video streaming

Digest authentication support

The Audio only streaming is a bit rough. I do not really give any indication on the stream status. I had to release earlier then I wanted as a customer needed the auto restart features ASAP. In the future I will add an input volume indicator and bitrate display to give visual feedback on audio only broadcasts.

I am at a point where I feel comfortable releasing Livu with the new RTP library. I am going to start working on the following features:

Auto restart – Will attempt to restart the stream if a network error occurs.

Multiple profiles – You can configure multiple named profiles.

Audio / Video only – Streaming of audio or video only.

Better feedback – The messages will give you more information (e.g. Bad User/Pass and not Stream Error)

Remote control via a web interface.

640×480 over cellular – Assuming this passes approval by Apple.

Streaming of prerecorded content *

Mixing of Live and prerecorded content **

* Streaming of prerecorded content will require a some work on my part. Sense I have removed FFmpeg from my project I will have to write the code to do this myself. It is not hard work, but it will require me to write some tedious parsing code.

** Assuming I complete the prerecorded content streaming, then this will follow after. I don’t see this feature as much of a problem to implement.

Another feature I will be working on is a site configuration “API”. This will allow Livu users to only have to specify a host, user name and password. Livu will then call to the domain to log the user in. The response will be streaming parameters for Livu. This work will be done after the major features requests are complete and in the store.

I have been working on building RTSP/TCP interleave streaming into the RTP library. Needless to say this was not as easy from the design side of things. There are a few things left to do at this time, but they will not effect anything from the perspective of Livu. Once I get some time I will think about how to best handle the interaction between interleaved streaming through the RTP library while still allowing RTSP messages to be sent and the result returned while publishing or streaming.

I have the ‘new’ RTSP/RTP/SDP network stack in place. I will be making it more general over the coming week. Once this is complete I will start working on all the feature requests that have been requested. The first feature to be implementd is auto restart. I will put this in before I do any UI work. After this it will take some time before the next update as I will need to redesign the UI for many of the features. Be prepared for some really nice changes over the coming months.

I am now starting to remove FFmpeg from my project. I am only using it as a RTP library. I will be writing my own RTP client over the next month or so. This will be an open source project, so once it is done I will post it to github.

I have been traveling and have come across issues with UDP over various cellular networks. The problem appears to be a timeout issue with the RTSP connection. I will be increasing the timeout value to 15 seconds. TCP does not exhibit this problem.