Dear Sir: I have conquered this problem today. It was my carelessness since I didn't apply genWindowsMakefiles to build live555 but instead open a new porject in VC6 and import the sources to compile.
By default, only WIN32 is defined. But NetCommon.h requres __WIN32__, _WIN32, _WINNT or WINNT to be defined on Windows XP. This causes winsock2.hand ws2tcpip.h not to be included such that inappropriate macros used to call setsocketopt() leads to failure of joining a multicast group. Besides, in a practical multicast client application, it may be a problem if the RTSP server doesn't specify the media port in its SDP, for example, m=video 0 0 RTP/AVP 96. This will cause MediaSubession::fClientPortNum to be assigned 0. and then RTSPClient::setupMediaSubsession() will return False because the following condition holds: rtpNumber = subsession <http://www.live555.com/liveMedia/public/doxygen/html/AVIFileSink_8cpp.html#25e0e015bb23ec5ef03f7e9b9be9b7f4>.clientPortNum <http://www.live555.com/liveMedia/public/doxygen/html/classMediaSubsession.html#626cf63889f4f00a8eb28355c73abbb0>(); if (rtpNumber == 0) { envir().setResultMsg("Client port number unknown\n"); break; } How about assigning a randomly generated port number here when initializing a MediaSession with SDP since it is not relevant for this application? Actually RFC2326 seems not to force the server to explicitly specify a media port number: C.1.2 Media streams The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is unicast, the port number serves as a recommendation from the server to the client; the client still has to include it in its SETUP request and may ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero. Example: m=audio 0 RTP/AVP 31 BR. Brain Lai 2007/11/12, Brain Lai <[EMAIL PROTECTED]>: > > Dear Sir: > > Multicast applications on Windows platform seem to have a problem. After > doing some experiments with your test program, I found the openRTSP agent > compiled with VC6 fails to receive video stream multicast by > testMPEG4VideoStreamer on Linux(that is, getNextFrame() never get a frame > after RTSP PLAY response). However, the cross-compiled(mingw32) version of > openRTSP succeeds! Since VLC for win32 is also cross-compiled, it also has > no problem. > > Using wireshark(previous ethreal) to capture the network packets, I found > that the cross-compiled version sent IGMP V3 membership message to join the > multicast group but the VC6 compiled version doesn't. > > I am not familiar with Windows socket programming but there seems > something missing or wrong. Do you ever get into this trouble and solve it? > > BTW, all the tests link to the latest live555. > > BR. > Brain Lai >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
