Video Streaming Server

Daniel Goertzen <>
Sat Aug 12 23:21:09 CEST 2006


Hi James.

A linked-in port driver would be the most efficient way to move data
into your Erlang node, however such a driver is harder to write and will
bring down the entire Erlang node if it crashes. A standard port (or C
socket server as David suggests) will incur some overhead because data
has to travel through a pipe or socket to reach your Erlang node,
however it will be easier to write and will not bring down the whole
node if it crashes.

The standard port mechanism really is a nice way to interface with C
programs, and I think you overestimate the performance impact that the
extra socket/pipe io will incur. But the only way to know for sure is to
try it out. :)

See http://www.erlang.org/download/erlang-book-part1.pdf page 134 for an
explanation of ports.

Cheers,
Dan.


lang er wrote:
> Thank you for your suggestion.
>
> Do you mean a C program reads video stream from device and transfer
> data to Erlang server using local socket, then Erlang server streams
> video data to client?
>
> In surveillance system, QoS( network delay especially) is very import,
> I think your solution may introduce some additional network delay .
> Normally, 200-500 ms is acceptable, I will write a prototype to test
> it.
>
> I wonder if this is the standard way Erlang program use external SDK.
> I have read some posts in this list, and got a impression that Erlang
> is used in telecommunication device systems and hardware controller
> programs. Don't they need interact with SDK(dynamic linked library)?
>
> Best Regards!
> James
>
>
> 在 06-8-12,David Hopwood<> 写道:
>> lang er wrote:
>> > 1. We need connect to many different kinds of video devices, some of
>> > these device vendors provide communication protocols to us, and we can
>> > implement them in native Erlang code. But some vendors only provide
>> > SDK(no source code), so should we use linked-in Port Drivers? And If
>> > SDK use native OS thread, are there any problems?If there are, How can
>> > we get out of these problems? or What is the best way to use these
>> > SDKs in Erlang?
>>
>> I would suggest to use each vendor's SDK in a separate process running
>> a C program, and communicate with these processes over local sockets.
>> The C program can translate the video to a vendor-neutral protocol. This
>> avoids any potential conflicts over threads or other resources within a
>> process, which you might not be able to solve without source code. It
>> also means that any instability in a vendor's code can be worked around;
>> if its process crashes then you can restart it, and you can also restart
>> it periodically to avoid potential memory leaks.
>>
>> I don't know whether the inability to use shared memory to communicate
>> with the Erlang program would result in performance problems; probably
>> not if the video streams are coming over a network to start with.
>>
>> -- 
>> David Hopwood <>
>>
>>
>>
>
>




More information about the erlang-questions mailing list