[OLSR-users] Mpeg4 RTP problem with olsrd and IP cam

[Bernd Petrovitsch]

On Wed, 2006-08-23 at 09:30 +0200, Bruno SELVA wrote:
[...]
> In a static configuration with 4 nodes everithing is working well ping
> ftp ... except the video when it use MPEG4 (RTP diffusion). It works
> sometimes after a long initialisation time.
> 
> In a mobile configuration the video is impossible.
> 
> If anybody have an explanation or/and a solution for my 
> problem i would be very happy.

You need an RTP/streaming specialist for more in depth explanation than
mine, but to put it simply:

The hard part on "streaming" (voice, video, etc.) is, that is must flow
"continously" as seen on the application level - otherwise - if packets
are lost (or too late - in all RT applications "wrong" includes "too
late" and "at the wrong time") - you get "freezes" in the movie or you
are hearing spits *immediately* (and don't underestimate the necessary
errors - delays (and jitter) that are much smaller than 1 seconds are
audible).
A necessary precondition is that the connection (read: bandwidth) as
such between stream source and stream destination is at least wide
enough to the the stream through.

The difference in the delays of the various packets (remember: RTP is
UDP based - you really do not want automatic retransmits as in a TCP
layer in "real time"[0] stuff) is the jitter.
What can you do against such the jitter?
You buffer in the application (or the RTP stack - it doesn't matter that
much) so you can survive a small jitter.
How much (in "seconds" - the needed RAM depends than on the codec and
other stuff) do you buffer?
That is now the key question:
- on the one side as short as possible because the player can start if
  the buffer is full. Ideally this is 0 seconds. Even on CD/DVD players
  you have these buffer fill up time (and it is > 0 seconds) since they
  have to live with the jitter from the CD/DVD drive.
- on the other side as long as necessary to survive delays/jitter - and
  that should be "enough". "Enough" depends primarily on the underlying
  network/stream transportation (e.g. if your network can guarantee
  real-time - e.g. USB or IEEE1349 - this is very probably very small).
  What guarantees do yo have on IP-over-Ethernet-Cable? What guarantees
  do you have over IP-over-Wireless?).
Now a good player application cannot depend on an average user telling
"good values" so it will try to estimate based on the experiences of the
first few seconds (and the initial default buffer will be quite sure a
few seconds) and improves the initial guess.
If you have a very large jitter, you will become a very large buffer and
- thus - a very large pause before the stream is presented to the user.

Of course there a are lots of tricks implemented and possible to improve
the situation (like developing even better codecs, possible using
forward error correction in certain circumstances, and throwing hardware
and/or bandwidth on problems also helps a - at most - little), but the
above described problem is a conceptual one.

	Bernd

[0]: "real time" as defined by techies and academics, not as defined by
     sales and marketing.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services