[Live-devel] Live555 MPEG2 Transport Stream packet loss

ilya77 at gmail.com ilya77 at gmail.com
Mon Apr 30 13:33:40 PDT 2007


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/20070430/3613e2ce/attachment.html 


More information about the live-devel mailing list