Re: [Live-devel] RTP over RTSP strange problem
> However on other PCs connected to the same server, on the same network, after > about 1-3 minutes, for each ~3-5 frames (groups of about 4-6 packets), the > RTP packets are confused to be RTSP - as if the '$' is not identified. > Recent versions of the "LIVE555 Streaming Media" software fixed some bugs with RTP-over-RTSP streaming (for both clients and servers) that could cause problems like this. Therefore, you should make sure that both your clients *and* servers (even if they are not under your control :-) are using the latest version of the software. A reminder, also, that RTP-over-RTSP streaming should be used *only* when you have a firewall (between the server and client) that prevents regular RTP/UDP streaming from working. It should not be used solely to try to prevent 'data loss'. 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
Re: [Live-devel] shared library
Am Freitag, den 21.12.2012, 15:55 +1000 schrieb Ross Finlayson: > > 1) We need symbolic links on Linux for shared libraries. For > > example, > > libfoo.so.1.2.3 would required these symlinks: > > > > libfoo.so.1 -> libfoo.so.1.2.3 > > libfoo.so -> libfoo.so.1.2.3 > > > > libfoo.so.1.2.3 and libfoo.so.1 will be shipped in the library > > package > > and libfoo.so will be shipped in the development package. > > > > I have created an install target (patch attached). PREFIX and LIBDIR > > needs to be defined in the other config.* files. The ln commands > > create > > the symbolic link described above, but they should be not run for > > other > > system (for example, config.linux). > > > Thanks. FYI, I figured out a mechanism that causes the symbolic links > to be created only when shared libraries are being built. I've now > installed a new version of the code (2012.12.21) that includes your > suggestion for adding an "install:" target. > > > Please check that this version works OK for you now (after running > "genMakefiles linux-with-shared-libraries") Thanks. The install target for the base Makefile is missing (install-target.patch attached). Your mechanism that causes the symbolic links to be created only when shared libraries are being built works. It would be a good idea to add a pkg-config file for the shared libraries. Is one pkg-config file that links against all four libraries enough or should there be one pkg-config file for each library. The latter is useful if the four libraries are used separately. > > 2) The *_VERSION_CURRENT, *_VERSION_REVISION, *_VERSION_AGE > > variables > > should be put into a separate file, because they are not Linux > > specific. > > They should be used on other systems (e.g. BSD) too. > > > Yes - I'll arrange for those variables to be set the same way in each > "config." file (for shared libraries) that ends up getting > distributed with the code. Thanks. > > 3) Some symbols used by the shared libraries are not found in none > > of > > the libraries (build.log attached). > > > Are you sure about these? When static libraries are built (and > applications linked against them), I don't see complaints about any > undefined symbols. It seems unlikely, then that there would be a > problem with undefined symbols just when shared libraries are used. > (Or perhaps there's a problem with the order in which the shared > libraries are linked against the applications??) These warning are generated by dpkg-shlibdeps. I was able to build VLC against the shared library version. Therefore I am not sure if these dpkg-shlibdeps warning are a problem. It's better to diagnose the cause instead of ignoring a warning. -- Benjamin Drung Debian & Ubuntu Developer Description: Add an install target to the build system. Author: Benjamin Drung --- a/Makefile.tail +++ b/Makefile.tail @@ -28,3 +28,12 @@ cd $(TESTPROGS_DIR) ; $(MAKE) clean cd $(MEDIA_SERVER_DIR) ; $(MAKE) clean cd $(PROXY_SERVER_DIR) ; $(MAKE) clean + +install: + cd $(LIVEMEDIA_DIR) ; $(MAKE) install + cd $(GROUPSOCK_DIR) ; $(MAKE) install + cd $(USAGE_ENVIRONMENT_DIR) ; $(MAKE) install + cd $(BASIC_USAGE_ENVIRONMENT_DIR) ; $(MAKE) install + cd $(TESTPROGS_DIR) ; $(MAKE) install + cd $(MEDIA_SERVER_DIR) ; $(MAKE) install + cd $(PROXY_SERVER_DIR) ; $(MAKE) install ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Patches in the Debian package
Hi,
we carry three patches (attached) in the Debian package that predate my
involvement in the Debian packaging. Are these patches acceptable?
--
Benjamin Drung
Debian & Ubuntu Developer
---
liveMedia/H263plusVideoRTPSink.cpp |2 +-
liveMedia/MPEG1or2Demux.cpp|4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- liblivemedia.orig/liveMedia/MPEG1or2Demux.cpp
+++ liblivemedia/liveMedia/MPEG1or2Demux.cpp
@@ -161,7 +161,7 @@ void MPEG1or2Demux::registerReadInterest
// Make sure this stream is not already being read:
if (out.isCurrentlyAwaitingData) {
envir() << "MPEG1or2Demux::registerReadInterest(): attempt to read stream id "
- << (void*)streamIdTag << " more than once!\n";
+ << streamIdTag << " more than once!\n";
envir().internalError();
}
@@ -460,7 +460,7 @@ void MPEGProgramStreamParser::parsePackH
skipBytes(pack_stuffing_length);
} else { // unknown
fUsingDemux->envir() << "StreamParser::parsePack() saw strange byte "
- << (void*)nextByte
+ << nextByte
<< " following pack_start_code\n";
}
--- liblivemedia.orig/liveMedia/H263plusVideoRTPSink.cpp
+++ liblivemedia/liveMedia/H263plusVideoRTPSink.cpp
@@ -64,7 +64,7 @@ void H263plusVideoRTPSink
}
if (frameStart[0] != 0 || frameStart[1] != 0) {
envir() << "H263plusVideoRTPSink::doSpecialFrameHandling(): unexpected non-zero first two bytes: "
- << (void*)(frameStart[0]) << "," << (void*)(frameStart[1]) << "\n";
+ << (frameStart[0]) << "," << (frameStart[1]) << "\n";
}
frameStart[0] = specialHeader>>8;
frameStart[1] = (unsigned char)specialHeader;
---
groupsock/GroupsockHelper.cpp |2 ++
1 file changed, 2 insertions(+)
--- liblivemedia.orig/groupsock/GroupsockHelper.cpp
+++ liblivemedia/groupsock/GroupsockHelper.cpp
@@ -444,12 +444,14 @@ Boolean socketLeaveGroup(UsageEnvironmen
// commands, and a special structure (ip_mreq_source). If the include files
// didn't define these, we do so here:
#if !defined(IP_ADD_SOURCE_MEMBERSHIP)
+#ifndef __GLIBC__
struct ip_mreq_source {
struct in_addr imr_multiaddr; /* IP multicast address of group */
struct in_addr imr_sourceaddr; /* IP address of source */
struct in_addr imr_interface; /* local IP address of interface */
};
#endif
+#endif
#ifndef IP_ADD_SOURCE_MEMBERSHIP
Description: Re-enable synchronous interface in RTSPClient to avoid API breakage.
Author: Alessio Treglia
Forwarded: not-needed
---
liveMedia/RTSPClient.cpp|3 ---
liveMedia/include/RTSPClient.hh |2 --
2 files changed, 5 deletions(-)
--- liblivemedia.orig/liveMedia/RTSPClient.cpp
+++ liblivemedia/liveMedia/RTSPClient.cpp
@@ -1756,7 +1756,6 @@ RTSPClient::RequestRecord* RTSPClient::R
}
-#ifdef RTSPCLIENT_SYNCHRONOUS_INTERFACE
// Implementation of the old (synchronous) "RTSPClient" interface, using the new (asynchronous) interface:
RTSPClient* RTSPClient::createNew(UsageEnvironment& env,
int verbosityLevel,
@@ -2076,5 +2075,3 @@ void RTSPClient::timeoutHandlerForSyncIn
// Signal a break from the event loop (thereby returning from the blocking command):
fWatchVariableForSyncInterface = ~0;
}
-
-#endif
--- liblivemedia.orig/liveMedia/include/RTSPClient.hh
+++ liblivemedia/liveMedia/include/RTSPClient.hh
@@ -306,7 +306,6 @@ private:
unsigned fSessionCookieCounter;
Boolean fHTTPTunnelingConnectionIsPending;
-#ifdef RTSPCLIENT_SYNCHRONOUS_INTERFACE
// Old "RTSPClient" interface, which performs synchronous (blocking) operations.
// This will eventually go away, so new applications should not use it.
public:
@@ -365,7 +364,6 @@ private: // used to implement the old in
char fWatchVariableForSyncInterface;
char* fResultString;
int fResultCode;
-#endif
};
#endif
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] distclean target
Hi, please add a distclean target which removes all files that are not part of the source tarball. distclean would depend on clean and additional remove all Makefiles. A patch that does this is attached. -- Benjamin Drung Debian & Ubuntu Developer diff --git a/Makefile.tail b/Makefile.tail index 2d567e9..15f788d 100644 --- a/Makefile.tail +++ b/Makefile.tail @@ -28,3 +28,9 @@ clean: cd $(TESTPROGS_DIR) ; $(MAKE) clean cd $(MEDIA_SERVER_DIR) ; $(MAKE) clean cd $(PROXY_SERVER_DIR) ; $(MAKE) clean + +distclean: clean + -rm -f $(LIVEMEDIA_DIR)/Makefile $(GROUPSOCK_DIR)/Makefile \ + $(USAGE_ENVIRONMENT_DIR)/Makefile $(BASIC_USAGE_ENVIRONMENT_DIR)/Makefile \ + $(TESTPROGS_DIR)/Makefile $(MEDIA_SERVER_DIR)/Makefile \ + $(PROXY_SERVER_DIR)/Makefile Makefile ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] shared library
> Thanks. The install target for the base Makefile is missing Oops - my mistake. I've just installed a new version of the code that fixes this (and also adds your proposed "distclean:" target). > It would be a good idea to add a pkg-config file for the shared libraries. I don't know what a "pkg-config" file is... >>> 3) Some symbols used by the shared libraries are not found in none >>> of >>> the libraries (build.log attached). >> >> >> Are you sure about these? When static libraries are built (and >> applications linked against them), I don't see complaints about any >> undefined symbols. It seems unlikely, then that there would be a >> problem with undefined symbols just when shared libraries are used. >> (Or perhaps there's a problem with the order in which the shared >> libraries are linked against the applications??) > > These warning are generated by dpkg-shlibdeps. I was able to build VLC > against the shared library version. Therefore I am not sure if these > dpkg-shlibdeps warning are a problem. It's better to diagnose the cause > instead of ignoring a warning. I'll leave it to someone who understands those warnings to do that :-) 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
Re: [Live-devel] distclean target
> please add a distclean target which removes all files that are not part > of the source tarball. distclean would depend on clean and additional > remove all Makefiles. A patch that does this is attached. Thanks. This is included in the latest release (2012.12.22). 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
Re: [Live-devel] Patches in the Debian package
> we carry three patches (attached) in the Debian package that predate my > involvement in the Debian packaging. Thanks for the update. I wish the people who decided (apparently unilaterally) that those patches were necessary had had the courtesy to check with this mailing list first. By doing this, they would have (1) avoided applying possibly incorrect, incomplete and/or harmful patches that they might not fully understand, and (2) allowed any patches that *were* truly useful to be made available to other users of this software. (I have the same problem with a few of the VLC developers; they seem to think that the world revolves around them.) But anyway: 1/ The first 'patch' was apparently intended to remove some compiler warnings. It's harmless, but I recommend not applying it, because the code that generates these compiler warnings might end up changing sometime (which will break the patch). 2/ The second 'patch' seems wrong to me. I don't understand why any system would define "struct ip_mreq_source", but not also define "IP_ADD_SOURCE_MEMBERSHIP" (a constant that makes that structure useful). I recommend removing the patch. If anyone feels that it is, in fact, necessary, then they can post a message to this mailing list (as they should have done in the first place!) explaining why they think it's needed. 3/ The third 'patch' is definitely wrong, and should be removed. The whole point of deprecating the old, synchronous "RTSPClient" interface is that any code that happens to depend upon the old interface needs to explicitly be updated - by "#define"ing RTSPCLIENT_SYNCHRONOUS_INTERFACE - so that it can continue using it. But anyway, no code that depends upon the old interface is present anywhere in the LIVE555 distribution, or (I presume) anywhere else in the Debian distribution either. 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
[Live-devel] about MultiFramedRTPSink::fOurMaxPacketSize
Hi I use live555 to stream files(1080p/60 frames).I found that the default value of MultiFramedRTPSink::fOurMaxPacketSize is 1448.When streaming the file(1080p/60 frames) using this value,there are many mosaic at the client.I modified this value to 2896(setPacketSizes(1000, 2896)) and the picture at the client is well(no mosaic). The network is the same one(LAN /100M) and the MTU is 1500.But why the it is ok with the value of 2896? Thank you. 2012-12-22 kingaceck ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] about MultiFramedRTPSink::fOurMaxPacketSize
> I use live555 to stream files(1080p/60 frames).I found that the default > value of MultiFramedRTPSink::fOurMaxPacketSize is 1448.When streaming the > file(1080p/60 frames) using this value,there are many mosaic at the client.I > modified this value to 2896(setPacketSizes(1000, 2896)) and the picture at > the client is well(no mosaic). > The network is the same one(LAN /100M) and the MTU is 1500.But why the it is > ok with the value of 2896? I don't know, because you haven't said anything about what video codec you use (and I don't particularly care, because you use an unprofessional email address). But if your LAN's MTU really is 1500, then I don't see how your system could perform better with 2896-byte RTP packets (because packets that large will be subject to IP-level fragmentation, which is generally a bad idea). 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
