No, that happens only if the call to “isSSM()” returned True - i.e., only
if the stream is ‘source-specific multicast’ - which is definitely not the
case here (you’re streaming via unicast). So that’s a ‘red herring’.
isSSM() is definitely returning true.
Then something is badly fucked
No, that happens only if the call to “isSSM()” returned True - i.e., only
if the stream is ‘source-specific multicast’ - which is definitely not the
case here (you’re streaming via unicast). So that’s a ‘red herring’.
isSSM() is definitely returning true. Any thoughts on what I could be
On Fri, May 8, 2015 at 1:23 AM, Ross Finlayson finlay...@live555.com
wrote:
Having ruled out firewall and UDP transmission issues, what else could
cause RTP-over-UDP to fail when RTP-over-TCP works fine?
Nothing comes to mind, unfortunately. Assuming that you haven’t modified
the supplied
Okay, I think I have made some progress. I found two issues:
1. In-line with your firewall hypothesis, the server was announcing a
169.254.X.Y address, but I was playing from rtsp://127.0.0.1:5640/.
When I pointed my rtsp URL to 169.254.X.Y instead of 127.0.0.1, the UDP
packets
On Wed, May 6, 2015 at 5:23 PM, Ross Finlayson finlay...@live555.com
wrote:
Thanks for the quick response. I have upgraded both the client and server
to the May 3rd 2015 edition and the result appears to be the same. On
the receiving side I am still getting packets which appear to contain
On Wed, May 6, 2015 at 2:57 PM, Ross Finlayson finlay...@live555.com
wrote:
I have a live555 on-demand RTSP server running locally (this is an older
version from about 2013)
Sorry, but old versions of our code are not supported - at all.
http://live555.com/liveMedia/faq.html#latest-version
could cause my
stream to completely not work on UDP while working fine on TCP, given that
Wireshark tells me I'm getting the packets?
Thanks,
Dave McMordie
Viion Systems
Opening connection to 127.0.0.1, port 5640...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1:5640
” to tackle this would be much appreciated.
Best regards,
Dave McMordie
*[image: Description: cid:image001.jpg@01C94FAF.E4535F30]*
*David McMordie*
*CTO*
1751 Richardson, Suite 8.123
Montreal, QC H3K 1G6
mcmor...@viionsystems.com
www.viionsystems.com
*Confidentiality Message *
This message
at this, it looks to me like a challenge may be that
inheriting from both MediaSink and FramedSource could result in some
clashes.
Any guidance would be appreciated.
Best,
Dave McMordie
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555
1. Would having a fully implemented Tee-sink / Frame Duplicator class
offer significant advantages over ad-hoc methods of replicating a stream
(eg. inside filters)?
It depends on what you want to do with each 'replica'. If you just need
two 'replicas' - one going to a LIVE555 MediaSink
10 matches
Mail list logo
