>
> 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 b
> 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 fuc
>
>
> 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
> We were getting the datagrams, but code inside GroupSock.cpp line 314 was
> checking that the address matched the advertised address, and returning with
> bytesRead still equal to zero, despite a successful read.
No, that happens only if the call to “isSSM()” returned True - i.e., only if
th
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 start
> I spent some time going through older posts on this mailing list and noticed
> the requirement that we not send multiple NALs to the
> H264VideoStreamDiscreteFramer. I put in a test looking for multiple NALs by
> matching the 0x0001 start code and found that most encoded frame buffers
>
On Fri, May 8, 2015 at 1:23 AM, Ross Finlayson
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 code, I can’t th
> 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 code, I can’t think of any reason (other than firewalls) why
RTP-over-TCP wo
On Wed, May 6, 2015 at 5:23 PM, Ross Finlayson
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 data
> (or random gar
> 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 data (or
> random garbage), and the head == tail, so the frame size is zer
On Wed, May 6, 2015 at 2:57 PM, Ross Finlayson
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
>
Thanks for th
> 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
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
12 matches
Mail list logo
