[Live-devel] Live555 MPEG2 Transport Stream packet loss

[Morgan Tørvolt]

> Also, your email says you are using ATM (Asynchronous Transfer Mode?).  I
> check this on wikipedia, and notice that the data must be divided into very
> small cells for delivery.  It seems like ATM is a protocol for
> time-sensitive data, like VoIP.  RTP also is designed to meet special
> timing needs of the data. Could there be a problem combining these two
> time-sensitive protocols?  "If a circuit is exceeding its traffic contract,
> the network can either drop the cells or mark the Cell Loss Priority (CLP)
> bit (to identify a cell as discardable further down the line)."  The RTP
> delivery can be somewhat bursty, so maybe you need to check your ATM
> contract and make sure you have the correct one (VBR maybe?) one?

ATM is just a transport layer, as Ethernet, SDH and others. ATM is
usually used in for example ADSL connections. That the packet size is
155 (or something like that) is not obvious, or even visible, to the
end hardware. It sees only an ordinary Ethernet link.
ATM is not very suited to do anything really. It is like a duck, it
can swim, fly and make sound, but does neither extremely well. For
extremely time sensitive data one uses SDH, which even keeps the
original input clock through the links. For time insensitive data one
uses Ethernet. ATM is very good at prioritizing traffic though, and it
could sound like the Ethernet packets are given a low priority,
possibly due to the fact that it is UDP. I have experienced this
before, and the configuration of a Ethernet card in one of the nodes
was to blame. It did not keep it's config due to hardware failure. In
your case this should be configurable in the ATM nodes, or management
software.

As a "most likely" option, I would have to opt for bandwidth problem.
I have spent too many hours saying that it is not so on ATM networks
before. Check that your VCs and VPs are set up correctly, and try
transmitting TCP and UDP data from other sources than live. VLC stream
output would be a good place to start I believe.

I agree with Ross here. You say it works well without the ATM, but not
with it. The reason for the problems is then too obvious. As there are
literally thousands of users of this software, I do believe that the
way it handles the Ethernet part works according to standard (unless
your OS or some configurations therein is to blame). One should not
make custom fixes to allow for broken hardware or configuration. In
this case "your network" seems like a good term, as most of the other
networks seems to work just fine.

-Morgan-