Transferring frames of a Video over Socket

Question

I have frames of a Video with 30FPS in my C# code and I want to broadcast it in local host so all other applications can use it. I though because it is a video and there is no concern if any packet lost and no need to connect/accept from clients, UDP is a good choose.

But there are number of problems here.

• If I use UDP Unicast speed is enough, about 25FPS (CPU Usage is 25% that mean 100% on one thread in my 4 core CPU which is not ideal. But at least it send enough set of data). But unicast cant deliver data to all clients.
• If I use broadcast speed is very low. About 10FPS with same CPU usage.

What can I do?! Data are in same computer so there is no need to remote access from LAN or etc. I just want a way to transfer about 30MBytes of data per second between different applications of same machine. (640x480 is fixed size of Image x 30fps x 3byte per pixel is about 27000KByte per second)

1. Is UDP Multicast has better performance?!
2. Is TCP can give me better performance even if I accept each client and send to them independently?!
3. Is there any better way than Socket?! Memory sharing or something?!
4. Why UDP broadcast is that much slow?! Only about 10MBytes per second?!
5. Is there a fast way to compress frames with high performance (to encode 30fps in a sec and decode on other part)? Client apps are in C++ so this must be a cross platform way.

I just want to know other developers experiences and ideas here so please write what you think.

Edit:

More info about data: Data are in Bitmap RGB24 format and they are streaming from a device to my application with 30FPS. I want to broadcast this data to other applications and they need to have this images in RGB24 format again. There is no header or any thing, only bitmap data with fixed size. All operations must perform on the fly. No matter of using a lossy compression algorithm or any thing.

Answer 1

I experiment Multicast in an industrial environment, it's a good choice over a not staturated reliable network.

In local host, shared memory may be a good choice because you may build a circular queue of frames and flip from one to the next only with a single mutex to protect a pointer assignment (writter side). With one writter, several reader, no problem arise.

On Windows with C++ and C#, shared memory is called File Mapping, but you may use system paging file (RAM and/or disk).

See these links to more information

• http://msdn.microsoft.com/en-us/library/system.io.memorymappedfiles.aspx
• http://msdn.microsoft.com/en-us/library/dd997372.aspx
• Mixing C++ and C# : How to implement shared memory in .NET?
• Fully managed shared memory .NET implementations?

The shared memory space isn't protected nor private but it'd named.

Usually, the writer process creates it, and the readers opens it by its name. Antivirus softwares takes a look at this kind of I/O in a same fashion as they do for all others but don't block the communication.

Here is a sample to begin with File Mapping:

char shmName[MAX_PATH+1];
sprintf( shmName, "shmVideo_%s", name );
shmName[MAX_PATH] = '\0';
_hMap =
   CreateFileMapping(
      INVALID_HANDLE_VALUE, 0, PAGE_READWRITE, 0, size, shmName );
if( _hMap == 0 ) {
   throw OSException( __FILE__, __LINE__ );
}
_owner = ( GetLastError() != ERROR_ALREADY_EXISTS );
_mutex = Mutex::getMutex( name );
Synchronize sync( *_mutex );
_data = (char *)MapViewOfFile( _hMap, FILE_MAP_ALL_ACCESS, 0, 0, 0 );
if( _data == 0 ) {
   throw OSException( __FILE__, __LINE__ );
}

Answer 2

Use live555 http://www.live555.com/ for streaming in combination with your favorite compressor - ffmpeg.