[Live-devel] Live555 MPEG2 Transport Stream packet loss

[ilya77 at gmail.com]

We've uploaded some ethereal output files from various points in our network
demonstrating the problem.
We would appreciate if anyone could take a look and maybe tell us something
which we might be missing...

The files can be downloaded from this link:
http://www.yousendit.com/download/UW16TGs2eFh5UkUwTVE9PQ

Many thanks,
Ilya


On 4/30/07, ilya77 at gmail.com <ilya77 at gmail.com> wrote:
>
>
>
> On 4/30/07, Ross Finlayson <finlayson at live555.com> wrote:
> >
> > >We are wondering if either TS or RTP provide some means of forward
> > error
> > >correction
> >
> > No, not at present.  However, there is ongoing work in the IETF (the
> > "FECFRAME" working group) towards standardizing FEC on media streams.
> > (This FEC would occur just above the UDP level, so could be applied
> > to raw-UDP Transport Streams, as well as RTP streams (of any payload
> > type).)
> >
> > >Re: Are you watching the video in real time or just recording it?  you
> > >could use openRTSP to record the video stream and see if it helps at
> > all to
> > >do this.  in openRTSP you can adjust the amount of time to wait for a
> > late
> > >packet.
> >
> > Not really.  If incoming packets are not being reordered on the
> > network, then the RTP reception code (regardless of the application)
> > will wait indefinitely for RTP packets to arrive; there is no concept
> > of a 'late' packet.
> >
> > If packets *are* being reordered on the network (a rare occurrence),
> > then the code will wait up to a certain time (default: 100ms) for a
> > 'late' packet to arrive.  You can change this time, but note, once
> > again, that it is relevant only if packets are arriving out of order
> > - which rarely happens.
> > --
>
>
> We are currently using VLC to view the media stream, and our goal is to
> set up a server which is capable of streaming to any RTSP / MPEG-2 TS
> capable player, so in essence - we are using live555 media *server*
> capabilities, but not client capabilities (unless VLC uses portions of the
> live555 project).
>
> We are trying to stream a pre-recorded transport stream file, and from
> what we see on the sniffer dump, packet reordering does *not* occur on the
> network.
>
> Regarding error correction - as far as I can tell, the transport stream
> does provide a container for error correction information, but it is
> somewhat opaque and transport-dependant, which led me to hoping that RTP
> might provide some method of forward error correction...
>
> Am I correct that apart from trying to resolve network infrastructure
> problems (which might be impossible since there are too many instances
> involved in the process) we have no means to achieve reliable media
> delivery?
>
> Many thanks,
> Ilya
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070517/d86e428d/attachment-0001.html