I'm folowing Apple's proposal in https://datatracker.ietf.org/doc/html/draft-pantos-http-live-streaming-01.
Trying a dummy HTTP Live Streaming to my iphone, I wrote a webservice with Django corresponding to a .m3u8 file. I'm begining the response with
#EXTM3U
#EXT-X-TARGETDURATION:#10
#EXT-X-MEDIA-SEQUENCE:#0
I then write the URLs of the segments (6 segments of 10 seconds each )inside the response:
#EXTINF:10,
http://...../sample_low-1.ts
...
and that's all. I change the part containing URLs of segments every minute, so in theory I'm expecting a continuous live stream.
However, when I check the stream with my iphone I observe the following:
The phone connects to ...m3u8 , gets its contents, starts downloading .ts files and starts showing the video. Then, after downloading 6th segment(last segment in the .m3u8) it reaches end of file, sees no
EXT-X-ENDLIST
and searches for the new .m3u8. The new .m3u8 is ready at the server at this point, as I renew the contents of .m3u8 every 60 seconds.
However, the phone pauses, and I cannot achieve a continuous stream on the phone.
So, obviously I make a huge mistake somewhere. Any helps and suggestions are very welcome.
Edit : Turns out that incrementing media sequence works.
How do you send the response back?
If you return the Django response object, then the server is simply sending a response with the six segments, and then will sit quietly, waiting for a new request from the client.
If you want to continuously send data from the server, you should instead yield the result, and use some kind of synchronization, so that you are sure you are not sending the same data over and over again.
Related
I'm using an ESP8266 with ESP8266WiFi and ESP8266HTTPClient libraries. My app doesn't have enough memory to download the entire JSON file that I need, but all I really need is a few fields from it, so I can discard most of it as I read it in.
What I don't understand is how to start, stop, or otherwise slow down the incoming data so that I can process it and pick out what I need as it comes in from the server. I have to use a fairly small buffer when I make the connection due to memory limitations caused by the rest of the program.
Is there a way to fill the buffer from the server, pause the transmission, process and clear the data in the buffer, and then resume the transmission until the whole JSON file is processed?
Sounds like you will want to use a streaming JSON parser. There are a couple of forks of such a library on GitHub. https://github.com/mrfaptastic/json-streaming-parser2 seems to be the one still maintained.
I need to send a stream of data to Play server. The length of the stream is unknown and I need to get a response every line break \n or for every several lines. Rather then wait for the whole data to be sent.
Think of the following usecase:
lets say i'm intended to write a console application, that when launched, connects to my web server, and all the user input are being sent to play on every line break, and gets responded asynchronously. All above should be performed on a single connection, i.e. I don't want to open a new connection on every request I send to Play (a good analog would be 2 processes communicating through 2 pipes).
What is the best way to achieve this?
And is it possible to achieve with a client that communicates with the server only via http (with a single http connection)?
EDIT:
my current thoughts on how to approach this are as follows:
i can define a new BodyParser[Future[String]] which is basically an Iteratee[Array[Byte],Future[String]]. while the parsing takes place, i can compute the result asynchronously and the action can return the result as ChunkedResult in the future's onComplete method.
does this sound like the right approach?
any suggestions on how to achieve this?
Maybe you should look at websockets.
Java: http://www.playframework.com/documentation/2.1-RC3/JavaWebSockets
Scala: http://www.playframework.com/documentation/2.0/ScalaWebSockets
I have an iOS app that I'm migrating from the very slow and clunky SOAP to a custom data format (basically CSV with some extra bits).
My priority is getting initial data to the client as quickly as possible while letting it still load more in the background. The server side is written to continuously flush data instead of caching the response.
So I'd like to parse out every line as they arrive at the client, instead of waiting for the full response.
If I view it in a browser I get progressive loading. However, using MKNetworkKit or ASIHTTPRequest or similar, I'm only able to get the full response which takes several seconds longer.
Does anyone know what the best options could be?
NSURLconnection can do what you want. You set the delegate and use -connection:didWriteData:totalBytesWritten:expectedTotalBytes: callback to read in a chunk of the data as it's downloading.
It will be up to you to properly handle splitting up the lines and handling chunks containing partial lines.
I would like to know what is the best method to get data in iPhone as soon as a user entered or modified data in server. I can send a request for a small time interval to server to check any modifications done in server(Like Polling). I know it is very awkward. Pleas suggest a best one !!!
EDIT
I am not talking about push notifications. I need some Data something like while having a cricket match, when each time score updates in server I need to get that data (via XML,JSON, or any other medium) in my iPhone.
You're talking about push notifications: http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
These let you send specific messages from your server, to devices that opt in to receiving push notifications from your app.
What you are looking for is known as "Push Technology" (there are several variations of the same idea). In your case, what I think is best suited is "long polling". In short:
you poll specifying a very long timeout;
the server will not reply until it has some new data, so your request will be kept open as long as timeouts allow;
as soon as the server has got new data, it will reply, and you get the changes immediately;
when the timeout expires, you send a new request.
The fact of having a long poll will reduce the overhead you are worried about with "short" polling. Indeed, with short polls the idea is sending frequent requests, with a very short round-around time. This will make you send constantly requests to check for new data. With long polling you send a request only when you have got new data, or when a timeout fires (which can be several minutes).
In this S.O. post, you will find a way to implement it.
Once a month the mp3 streams messes up and the only way to tell it has messed up is by listening to it as it streams. Is there a script or program or tool I can use to monitor the live streams at a given url and send some kind of flag when it corrupts?
What happens is normally it plays a song for example or some music but once a month, every month, randomly, the stream corrupts and starts random chimpmunk like trash audio. Any ideas on this? I am just getting started at this with no idea at all.
Typically, this will happen when you play a track of the wrong sample rate.
Most (all that I've seen) SHOUTcast/Icecast encoders (going straight from files) will compress for MP3 just fine, but assume a fixed sample rate of whatever they are configured for. Typically this will be 44.1kHz. If you drop in a 48kHz track, or a 22.05kHz track, they will play at different speeds while causing all sorts of random issues with the stream.
The problem is easy enough to verify. Simply create a file of a different sample rate and test it. I suspect you will reproduce the problem. If that is the case, to my knowledge there is no way to detect it, since your stream isn't actually corrupt... it just sounds incorrect. You will have to scan all of your files for sample rate. FFMPEG in a script should be able to help you with that.
Now, if the problem actually is a corrupt MP3 stream, then you have problems on your encoding side. I suspect simply swapping out whatever DLL or module you're using with a recent stable version of LAME will help.
To detect a corrupt MP3 stream, your encoder must be using CRC. If you enable it, you should be able to read through the headers of each frame to find the CRC, and then run it on the audio data. In the event you get an error (or several frames with errors), you can then trigger a warning.
You can find information on the MP3 stream header here:
http://www.mp3-tech.org/programmer/frame_header.html