Server-Push JPEG Stream

September 13th, 2007 at 23:46 · Filed Under Ada, Call Me a Geek, Computing, Hacking, Mac OS X, Software Development, Web

I am working on a video server project since last week. This project is to develop a client software running on Mac OS X to control a video server and to retrieve streams of JPEG images from it. And of course, I am going to develop with Ada together with AWS (Ada Web Server).

Up to this point, I am able to connect to the video server with AWS and retrieve a stream of JPEG images from the video server. I have been able to manually extract JPEG images from the stream identified by SOI (0xFFD8) and EOI (0xFFD9). But some of the images extracted from the stream are not recognized as JPEG file while some images appeared to be corrupted. I am totally puzzled by this behavior.

Could it be the size of the stream buffer (512 bytes) causing the corruption? Could it be the output of the received stream to a disk file delay the receiving process?

Here’s a snip of my Ada code:


     ...
     Data         : Ada.Streams.Stream_Element_Array (1 .. 512);
     ...
     loop
        AWS.CLient.Read_Some (Connection, Data, Offset);
        exit when Offset < Data'First or Count > 512_000;
        Ada.Streams.Stream_IO.Write (File_Handler, Data);
        Count := Count + Integer (Offset);
     end loop;
     ...

It is quite fun spending entire day hacking the server-push stream and the JPEG images. It has been a long time since my last hacking. Welcome back to the reality!

Get Shareaholic

Tags:

Comments

6 Responses to “Server-Push JPEG Stream”

Zhang Wei on September 14th, 2007 15:31 1

Hi Adrian,

I think it is the sequential execution of read and write that might be the contributor of the corruption of the incoming JPEG stream. Try to to parallel read and write using protected type. It may solve your problem.

It is interesting enough to find someone who is working on the same area of interest. I am working on a client on Solaris but the server pushes streams of raw binary data of digital signals. I think the situation is almost similar here.

张薇
Adrian Hoe on September 14th, 2007 15:43 2

Hi Zhang,

I don’t think so. It is a single stream and I think the socket layer of the OS has already taken care of the read-write-wait. Thanks for the suggestion. I will investigate into your suggestion and confirm what is contributing to the corrupted JPEG images.

The problem I have at hand is that I don’t have a video server running and I am connecting to a 3rd party video server given as a reference in the NDA. Again, I am quite limited to open discussion because of the NDA.

Unless, I have the access to the video server, I can download those images directly from the video server based on the time to run a diff against the stream I obtained from my program.
潜龙在天 on September 14th, 2007 21:27 3

Hi Adrian,

Nice to hear that you are hacking again!

Are your sure you are writing exactly the number of bytes read?

Happy hacking!
Adrian Hoe on September 14th, 2007 21:35 4
Yes! I was having the same thought and just got it all hacked and corrected.

I have a Data of 512 bytes in size. AWS.Client.Read_Some will not always read 512 bytes. When it reads less than 512 bytes, say, 500 bytes. Stream_IO.Write will always write 512 bytes. That means 12 bytes of garbage will be written after the useful 500 bytes.

I got around with that by writing to the next index of the last byte read. So I did this:
```
      Ada.Streams.Stream_IO.Write (File_Handler, Data, Index);
      Index := Index + Ada.Streams.Stream_IO.Positive_Count (Offset);
```
Zhang Wei on September 18th, 2007 16:01 5

That’s interesting. I am glad you have found a solution. Do you have any idea why Read_Some does not always read in 512 bytes?

张薇
Adrenaline Hack | Adrian Hoe’s WebLog on September 25th, 2007 14:39 6

[...] Server-Push JPEG Stream [...]