Hi Ross
Following is the log
./openRTSP -V -Q "rtsp://172.24.141.104:554/Video/edit.mpg"
Sending request: OPTIONS rtsp://172.24.141.104:554/Video/edit.mpg
RTSP/1.0
CSeq: 1
User-Agent: ./openRTSP (LIVE555 Streaming Media v2007.05.22)
Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Public: DE
Some people definitely needed the current code for unicast streaming
(to/from a specific IP address); that's why the code is there. If I
were to make your suggested change, I'm sure I'd get complaints from
other people.
However, I think the following change will satisfy everyone. In
"Groupso
In any case, the current code ("bind()"ing to "ReceivingInterfaceAddr") is
necessary for unicast streams to work properly (if
"ReceivingInterfaceAddr" was set to something other than INADDR_ANY).
Re: So when you make this change, you are not able to receive unicast
data? My Fedora Core 5 syste
Re: But my change does not disable the ability to change the
interface from the default. The address parameter on the "bind"
call specifies what destination addresses the socket will accept in
the arriving packets. If you use INADDR_ANY, you can accept data
which specifies any address as the
We *do* allow "ReceivingInterfaceAddr" to be something besides INADDR_ANY.
That's the whole point of the existing code.
Re: But my change does not disable the ability to change the interface
from the default. The address parameter on the "bind" call specifies what
destination addresses the s
Why would you not allow ReceivingInterfaceAddr to be something
besides INADDR_ANY?
We *do* allow "ReceivingInterfaceAddr" to be something besides
INADDR_ANY. That's the whole point of the existing code.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Sorry, but I can't make this change. The existing code is the whole
reason why we allow "ReceivingInterfaceAddr" to be something other
than INADDR_ANY.
Re: Do you have a different suggestion of what to try? Why would you not
allow ReceivingInterfaceAddr to be something besides INADDR_ANY? I
Sorry, but I can't make this change. The existing code is the whole
reason why we allow "ReceivingInterfaceAddr" to be something other
than INADDR_ANY.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-dev
Forgive my extra post, but maybe it would be easier to understand if you
change the line to this:
MAKE_SOCKADDR_IN(name, INADDR_ANY, port.num());
Xochitl___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/
Thanks for your response, but I don't think this fixes the problem. Why
bother setting the Sending- and ReceivingInterfaceAddr at all if you are
going to get the address using multicast loopback first? When I try this
in my system with multicast enabled on eth1 and eth0, the multicast
loopback
>Hi Ross
>Our company policy doesn't allow external excess to our network sorry
>for it :-), but would like to know what can be the problem behind this
>incomplete file streaming, as bit band player is streaming File till end
>while our openRTSP is not streaming till end.
>With our openRTSP test ap
Hi Ross
Our company policy doesn't allow external excess to our network sorry
for it :-), but would like to know what can be the problem behind this
incomplete file streaming, as bit band player is streaming File till end
while our openRTSP is not streaming till end.
With our openRTSP test applicat
12 matches
Mail list logo
