HI Ross, Thank you so much for your time, yes, I test the example testH264VideoStreaming single routine, it is work fine on my arm platform, they can parse the right URL according to my host ip, and the client can receive stream from the server,
the problem only came out when I mix compiled with C code, same rtspserver initialization setup step is called from my main C code, I did not change anything with RTSPServer::createNew(), and using the default 8554 as the port, I printed out protNumHostOrder right wasy after it assigned from "ntohs()" in rtspURLPrefix() function, "printf( "***** %hu****\n", portNumHostOrder,)" and it return 8554, that is mean the port is parsed correctly. next I printed the "urlBuffer" after assigning by "sprintf(urlBuffer, "rtsp://%s:%hu/", AddressString(ourAddress).val(), portNumHostOrder)" , it return "rtsp://******:20552". that's mean this error only happened when "sprintf", 20552 is octonary format of 8554, so same problem with AddressString, my host ip is 10.0.4.1, it was return 12.0.4.1, "AddressString()" function also using sprintf to return the network order ip so I have no idea on this, the compile environment seems all the same, I am still trying to figure out if anything is wrong in my way mixing compiled the routine. XINGJUN On Sat, Mar 28, 2015 at 1:39 PM, Ross Finlayson <finlay...@live555.com> wrote: > I cross compiled the dynamic library of live555 for ARM linux first, and > then mixed compiled the modified example “testH264VideoStreaming.cpp” > > > You should first verify that the *unmodified* “testH264VideoStreamer” > (sic) application code works OK for you. Then, and only then, should you > modify the supplied code. > > > The only problem is that the URL is wrong, so I tracked back to the > live555 library, and in the RTSPServer.cpp, in the function > rtspURLPrefix(), the address in urlBuffer is wrong when using sprintf, the > portNumHostOrder is defined as unsigned short, then %hu is right, but when > urlBuffer is printed out, 8554 is printed out as 20552, it seems the output > is in its octonary format, do have one have this problem similar with. > Thank you. > > > The library code is correct. Note that port numbers are stored (in the > “Port” class; see “groupsock/include/NetAddress.hh”) in network byte > order. That’s why the implementation of "RTSPServer::rtspURLPrefix()” > calls “ntohs()” on the port number before putting it into a “rtsp://“ URL. > > Therefore - assuming that the “ntohs()” (etc.) functions are working > correctly on your system - the problem must be in the way that you are > giving your RTSP server its port number. Note that the code for > “testH264VideoStreamer” (and other applications that create RTSP servers) > call “RTSPServer::createNew()”, passing the port number parameter as an > integer in host order (e.g., 554 or 8554). You should do the same in your > application. > > You’ll note, however, that “RTSPServer::createNew()” actually takes a > “Port” object as parameter. If you instead give it an integer as parameter > (as all of the application examples do), then this integer will be > automatically converted to a “Port” object. This is done using the > “Port()” constructor that’s defined in “groupsock/include/NetAddress.hh”, > line 96 (and implemented (in “groupsock/NetAddress.cpp”) by calling > “htons()” on the integer parameter, before storing it (in network byte > order). > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- Xingjun Chen
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
