[Live-devel] Breakup with mips port

Anthony Desmarais Anthony.Desmarais at altech-multimedia.com
Mon Dec 1 04:37:16 PST 2014


Ross,

On our system I ran the testOnDemandRTSPServer and then pointed VLC to rtsp://10.0.0.5:8554/mpeg2TransportStreamTest – this worked flawlessly even with the high bitrate video file.

In your experience does this point to the Live555 framework working 100%? From what I see this pretty much follows the exact same software flow as multicast would with the expection being that the address is not a multicast address. DO you agree with this statement? If so then I think I need to look at my kernel perhaps something here is not correct.

Thanks

Anthony


From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: 01 December 2014 01:58 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Breakup with mips port

Using the test transport stream from the live555 website “bipbop-gear1-all.ts” I ran the program testMPEG2TransportStreamer
Using a windows VLC client I could not play the file back

I presume you mean "could not play the *stream* back".

That's odd.  Are you using a recent version of VLC?  Do you have IP multicast connectivity between the server and the client (VLC) computer?  Could your Windows firewall be blocking the multicast packets??



I get the same picture breakup so I am now confident that the losses are somewhere in the live555 framework

No.  See <http://www.live555.com/liveMedia/faq.html#packet-loss>, and note, in particular, the last paragraph.

Packet loss is usually seen in LIVE555-based *receivers* (and, as noted in the FAQ entry, is usually caused by insufficient buffering in the receiver's OS).  It's unusual to see systematic packet loss (independent of the receiver(s)) occurring with LIVE555-based *servers*, unless the output stream is exceeding the capacity of your network.  But because "bipbop-gear1-all.ts" is such a low-bitrate stream, it's unlikely that network capacity is the problem here.  I suspect either:
            1/ A systematic problem with your server (OS)'s network interface and/or multicast implementation that is causing this packet loss, or
            2/ If you have a router sitting between your server and client(s), a systematic problem with how it implements multicast forwarding, or
            3/ Some weird MIPS-related problem in how your server is running our code.

I would try the following:
- Run the same server application ("testMPEG2TransportStreamer") using the same file(s), but running on some other architecture (e.g., Linux/Intel, or Mac OS).
- Run the "LIVE555 Media Server" or "testOnDemandRTSPServer" demo application, which streams via unicast, rather than multicast.

Both of these should help you narrow down the problem.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20141201/adb83509/attachment-0001.html>


More information about the live-devel mailing list