[Live-devel] Live555 MPEG2 Transport Stream packet loss

[ilya77 at gmail.com]

Hi all,

We've eliminated the NAT/ATM from the equation, and tried streaming the
MPEG-2 TS over UDP (connecting the viewing PC directly to an ADSL line), and
it did improve the sittuation dramatically, however, we sill have around 0.3-
0.7% packet loss over the WAN which results in video smearing here and
there, and audio glitches (which are worse than video smearing because they
are easily identified by ear and are more disturbing).

We are wondering if either TS or RTP provide some means of forward error
correction, since this rate of lost packets is normal over the public
Internet, and from what we can tell the player (VLC) can not deal with those
errors (and conceal them from the viewer).

We are trying to find some information regarding embedding FEC information
into the transport stream (as far as we understand it provides at least a
container for error correction data), yet with no success.

Any ideas?

Many thanks,
Ilya


On 4/26/07, Morgan Tørvolt <morgan.torvolt at gmail.com> wrote:
>
> > 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-
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070429/e0998e46/attachment.html