[Live-devel] Breakup with mips port

[Anthony Desmarais]

Thanks for the feedback Ross,

Sorry it it came across that I may be blaming the server for packet loss, this was not my intention, rather I was thinking that somewhere in the cross compilation there is packet corruption rather than packet loss.

In my original request I said that I redirected the output from the network to the disk, this was on the server side and was done in OutputSocket::write function so that the exact data that was being sent to the network was being spooled to the disk, in the resulting file I still get video breakup however after reviewing this I suspect that the write function’s receive pointer will include rtp headers which means the resulting file is not a ts  file, I would need to perform this test higher up the chain I suspect.

With regard to VLC, I now am receiving the rtp stream via VLC – I was using my development PC which has multiple network interfaces on it and I think VLC was listening on the incorrect IF. I got a dedicated PC with a single network IF and this is receiving the files but with the same video loss.

Also with regard to our embedded systems network subsystem, we have DLNA deployed so the network is functional but I may have issues with multicast, I guess my next test is to try a unicast transmission.

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/e0ba0949/attachment.html>