ECS Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ecs] "Live" video question
Ingo Pakleppa
Wed, 07 Jan 2004 01:45:41 -0800

I think you may want to look into some commercial video transmission
protocols. There is more to it than just the UDP vs. TCP question.
Primarily, there are timing issues (if a few pixels don't arrive in
time, they might as well not arrive at all). On the other hand, there
are plenty of things that you can take advantage of to squeeze more data
across the line. For instance, typically, only a small portion of a
picture changes from one frame to the next, so you may only have to
transmit the fraction where there is movement. Or, depending on the
transmission quality, you can reduce the image quality, making the image
"chunkier".

All of that has been - more or less - solved in various streaming
protocols and video compression algorithms. Several such algorithms are
available in standards or the public domain, and some are implemented in
hardware, maybe even already built into the cameras.

So I would suggest you read up on the MPEG compression and see how they
solved essentially the same problem. Also of interest would be RTP. RTP
is essentially, almost, at the same level as TCP and UDP are, but
specifically designed for realtime data transfer, voice and video in
particular. RTP is based on UDP, by the way.

On Tue, 2004-01-06 at 08:22, Mark Gilmore wrote:
> I would like to add support for pseudo-live image updates (>=4/sec), but am 
> concerned
> that the such frequent/large packets could easily bog down TCP/IP over 
> remote connections.
> So I was thinking that UDP would be a solution, as it is not a "dependable" 
> protocol
> (i.e. packets can be dropped if traffic does not allow - at least, that's 
> how I understand it).
> But I now read that UDP packets may arrive "in any order" (obviously not 
> acceptable for video).
> Any suggestions ?
> Perhaps I should stick with TCP/IP, but somehow monitor for transmission
> backups and hold off on image updates when needed ?
> Thanks :-).,
> 
> Mark Gilmore
> http://OmnipotenceSoftware.com



  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.