Hi Kumar,
The latency calculation is ideal if you are using UDP/IP in LAN.
If you are using TCP/IP, extra delay for TCP/IP. If you are using UDP/IP
in WAN, streaming buffer for that have extra delay.
To decrease the latency, you have to change the encoding/decoding
processing parally with the others.
in encoder side, parral three parts: 1. image capture, 2. video
encoding, 3. network transmitting.
the process like this:
1.while imager finished scaning the lines and transfer data to memory
by DMA, you will know how many line have been transfered to memory.
2. now start to encoding the first a few lines of the images.
3. while finished encoding the first lines, start transfer the data
immediately to receiver.
The rest of the encoder side will like this:
1. Image encoder keep transfer data to memory by DMA, it should much
faster than encoder encoding data.
2. encoder will keep continue encoding with the tranferred image
lines.
3. every a few encoded block data network module will transmit to
receiver immediately
Now the transmit latency become:
First a few lines delay between imager and encoder + a few blocks
encoding delay + network transmitting
total is much less than 100 ms.
The decoder side also similar, don't wait the whole image data
transmitted complete, once received the a few block data, start to decoding.
finally, the whole system latency is much less.
of course, it is the perfect condition. while in implementation, there
are a lot of thing make it difficult.
You have to control the imager, modify the structure of encoder,
control the UDP/IP module, change the decoding processing structure of
decoder. and consider the UDP/IP lost package and arrive un-sequence. all
those things make the system complex and difficult to handle.
It is possible but have to spend much more time on it. And finally,
maybe the network delay become the major latency.
Regards
Tonald DL
2008/7/30 Kumar Bala <[EMAIL PROTECTED]>
> Hi,
> Thats what I do now, I have a ping-pong buffering scheme.
> Jon, thanks for the information. Any idea what the best systems offer.
> Coz we want to beat that !
>
>
> Albert Burbea wrote:
> > hi
> > actually it can be less (you can transmit while you encode and encode
> while
> > you get video) but it is VEEEEEEERY expensive. You have to buy heavy 3rd
> > party video codecs.
> > What is your problem? Maybe we can help you
> > Albert
> >
> >
> > On 7/30/08, Jon Povey <[EMAIL PROTECTED]> wrote:
> >>> From: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED]
> >>> ] On Behalf Of Kumar Bala
> >>> Sent: 30 July 2008 11:12
> >>> To: [email protected]
> >>> Subject: Measuring MPEG4 system latency on DM355
> >>>
> >>> Hi,
> >>> I have an MPEG4 streaming system which capture live video at
> >>> 1280x720p using a HD camera module. Then it streams it over
> >>> to a PC running the client app such as VLC or mplayer.
> >>>
> >>> I believe I get a few hundred millisecond latency (about
> >>> 200-300 ms). We want to achieve a near analogue latency.
> >> Let's see, I'm not an expert but:
> >>
> >> 40ms to read in a frame (assuming 25fps)
> >> 30ms to encode
> >> Some amount of time to transmit the frame to receiver and have it
> >> decoded, then
> >> 40ms display time
> >>
> >> So I recon that's around 120ms minimum assuming instant transmit and
> >> decode, and no waiting for extra VSYNC on the receiver or anything..
> >>
> >> --
> >> Jon Povey, Design Engineer
> >> [EMAIL PROTECTED] | +44(0)1280 825983
> >>
> >>
> >> Racelogic is a limited company registered in England. Registered number
> >> 2743719 .
> >> Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham,
> >> Bucks, MK18 1TB .
> >> The information contained in this electronic mail transmission is
> intended
> >> by Racelogic Ltd for the use of the named individual or entity to which
> it
> >> is directed and may contain information that is confidential or
> privileged.
> >> If you have received this electronic mail transmission in error, please
> >> delete it from your system without copying or forwarding it, and notify
> the
> >> sender of the error by reply email so that the sender's address records
> can
> >> be corrected. The views expressed by the sender of this communication do
> not
> >> necessarily represent those of Racelogic Ltd. Please note that Racelogic
> >> reserves the right to monitor e-mail communications passing through its
> >> network
> >> _______________________________________________
> >> Davinci-linux-open-source mailing list
> >> [email protected]
> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >>
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > [email protected]
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Best Regards
Tonald DL
WebSite: http://dhcodec.quikstream.com.au/
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
