Random delay when using TStream for reading custom stream from http server

Question

I am using TIdHttp (from Indy components) for connecting to a camera that supports Sony Remote Api. The camera sends live view stream to an http connection as a response of an HTTP GET command. I wrote a TStream subclass and used it as a streaming class. Here is my code for connecting to live stream:

  liveStream := TLiveStream.Create;
  IdHttp1.Get('http://192.168.122.1:8080/liveview/liveviewstream', liveStream);

Definition of TLiveStream class is as follows:

TLiveStream = class(TStream)
public
    constructor Create;
    function Read(var vBuffer; aCount: Longint): Longint; override;
    function Write(const aBuffer; aCount: Longint): Longint; override;
    function Seek(const aOffset: Int64; aOrigin: TSeekOrigin): Int64; override;
end;

Program is connecting to live stream successfully and starts receiving live view from camera. But it randomly stops receiving anything from camera for five seconds (program is idle and does not freeze). I replaced TIdHttp with THttpCli from ICS but the problem does not resolve.

Any help would be greatly appreciated!

Edit:

I used curl tool to find out whether the problem is within my program, but the problem remained. I sniff packets transmitted between camera and PC, here is the screenshot of the delayed time:

Can you show the HTTP response headers which the server is sending? — mjn, Jul 21 '15 at 11:39
`HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked` — Hossein, Jul 21 '15 at 11:54
Read this: http://www.indyproject.org/sockets/Blogs/ChangeLog/20140305.EN.aspx — mjn, Jul 21 '15 at 12:10
@mjn: `application/octet-stream` is not a MIME type, though. The option that blog refers to only works for `multipart/...` types. Unless the camera really is sending MIME-encoded data but is sending the wrong `Content-Type` value. — Remy Lebeau, Jul 21 '15 at 17:58
@Hossein: without seeing the actual response, I can only assume that the camera is sending each HTTP chunk with a 5-second delay in between them. Using HTTP's `chunked` transfer encoding is an odd way for a camera to send streaming media. `multipart/x-mixed-replace` and many other streaming formats are better suited for that task. The fact that ICS also exhibits the same delay means it is happening on the camera side of the connection. — Remy Lebeau, Jul 21 '15 at 18:01
@mjn: for what it is worth, there is a TODO in Indy to add a similar option flag for handling `chunked` responses. — Remy Lebeau, Jul 21 '15 at 18:06
@RemyLebeau: When I connect to live view stream with a tcp connection (with curl tool), I receive messages without any delay. Is it a good idea to connect to the camera with a tcp connection and parse http headers manually? — Hossein, Jul 22 '15 at 16:27
There should be no reason for Indy/ICS to experience delays but Curl does not. Something else is going on. Try using a packet sniffer, like WireShark, to find out what is actually going on over the wire. If you see the live data arriving on the NIC without delay, then something odd is going on in your app. — Remy Lebeau, Jul 22 '15 at 18:38

Random delay when using TStream for reading custom stream from http server

0 Answers0