From fantasyvideo at 126.com Sun Dec 2 00:23:55 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Sun, 2 Dec 2012 16:23:55 +0800 Subject: [Live-devel] regarding live555 support rtmp Message-ID: <003c01cdd066$5ea69730$1bf3c590$@126.com> HI, Does live555 have plan to support rtmp? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Dec 2 01:03:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 Dec 2012 01:03:24 -0800 Subject: [Live-devel] regarding live555 support rtmp In-Reply-To: <003c01cdd066$5ea69730$1bf3c590$@126.com> References: <003c01cdd066$5ea69730$1bf3c590$@126.com> Message-ID: <8104ACB4-48C1-400A-A894-4E0D8E06A0BF@live555.com> > Does live555 have plan to support rtmp? No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Sun Dec 2 02:07:30 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Sun, 2 Dec 2012 18:07:30 +0800 Subject: [Live-devel] Regarding the live555 performance Message-ID: <001601cdd074$d74c2d90$85e488b0$@126.com> HI, Since I don?t have enough pc to test live555?s performance ? So could anybody help me? My environment is : CPU: Intel 4 cores. Mem: 4G System:Ubuntu 12.04. In such case, if the video is encoded h264(720*480), audio is g711. Then how many connections does live555 support? 100? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.thornton at zeiss.com Sun Dec 2 22:55:37 2012 From: keith.thornton at zeiss.com (Keith Thornton) Date: Mon, 3 Dec 2012 07:55:37 +0100 Subject: [Live-devel] Antwort: Re: Antwort: Re: WG: problem with rtp streaming after upgrading from VLC 2.0.3 to VLC 2.0.4 In-Reply-To: <48ABD26D-D6E3-4761-A488-8C3479B5F9A2@live555.com> References: <48ABD26D-D6E3-4761-A488-8C3479B5F9A2@live555.com> Message-ID: Thank you for your tips. My server doesn't currently support RTSP but I will look into the possibility of running an RTSP server. Gr?sse Keith Thornton _________________ Carl Zeiss Meditec AG Standort/Location M?nchen phone: +49 (0)89 909000-135 fax: +49 (0)89 909000-222 mailto:keith.thornton at zeiss.com http://www.meditec.zeiss.com Carl Zeiss Meditec AG, Standort/Location M?nchen, Kistlerhofstr. 75, 81379 M?nchen Vorsitzender des Aufsichtsrates: Dr. Michael Kaschke Vorstand: Dr. Ludwin Monz (Vorsitzender), Dr. Christian M?ller, Thomas Simmerer Sitz der Gesellschaft: 07745 Jena, Deutschland Amtsgericht Jena HRB 205623, USt-IdNr: DE 811 922 737 ---------------------------------------- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaman.lab.x11 at gmail.com Sun Dec 2 23:55:56 2012 From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=) Date: Mon, 3 Dec 2012 11:55:56 +0400 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: <078A8D67-C134-4FDC-B0F1-AF6051D30385@live555.com> Message-ID: I was wrong, problem is sometimes appears. After 2012.11.28 update, first start/stop playing stream in media player goes well, but second stop causes this error in proxy. 2012/11/27 ?????? ????????? > Sorry, that I did not answer at once, the problem disappeared after > cameras set up, I decrease MTU in settings, thanks for the response. > > > 2012/11/5 Ross Finlayson > >> I wrote dll library by proxy example. It works well, but sometimes there >> is a mistake "RTCPInstance error: Hit limit when reading incoming packet >> over TCP. Increase "maxRTCPPacketSize" >> >> >> Are you using the latest version of the software? Recent upgrades to the >> software should have made this error message much less likely. >> >> Ross Finlayson >> Live Networks, Inc. >> http://www.live555.com/ >> >> >> _______________________________________________ >> live-devel mailing list >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 3 00:06:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Dec 2012 00:06:38 -0800 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: <078A8D67-C134-4FDC-B0F1-AF6051D30385@live555.com> Message-ID: <0FE7DAB7-4704-4A4D-9F4C-DEAF37E13D0A@live555.com> > I was wrong, problem is sometimes appears. After 2012.11.28 update, first start/stop playing stream in media player goes well, but second stop causes this error in proxy. If your 'back end' server is using our software, then *it* will need to be upgraded as well. Upgrading just the proxy won't be enough. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaman.lab.x11 at gmail.com Mon Dec 3 00:30:43 2012 From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=) Date: Mon, 3 Dec 2012 12:30:43 +0400 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: <0FE7DAB7-4704-4A4D-9F4C-DEAF37E13D0A@live555.com> References: <078A8D67-C134-4FDC-B0F1-AF6051D30385@live555.com> <0FE7DAB7-4704-4A4D-9F4C-DEAF37E13D0A@live555.com> Message-ID: Of course I always do update the source code, I mean, that exactly after this update the behavior of the proxy has changed. 2012/12/3 Ross Finlayson > If your 'back end' server is using our software, then *it* will need to be > upgraded as well. Upgrading just the proxy won't be enough -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalcaraz at eye-cam.com Tue Dec 4 06:10:23 2012 From: dalcaraz at eye-cam.com (David Alcaraz Moreno) Date: Tue, 04 Dec 2012 15:10:23 +0100 Subject: [Live-devel] I can not stream live video with my own framedSource Message-ID: <50BE044F.30109@eye-cam.com> Hello, I have been 4 weeks trying to stream live video with live555 but I cannot found the documentation to stream video mpeg4 without a video file, the problem is that i don't have a file, i have a bytes array and i have seen the testprogs of live555 but I don't found the appropiate sample. I have trying to create my own framedsource subclass,although it seems works in debug mode, does not send data. this is my code: *For init the process in c#:* service = new RTPService(Convert.ToInt64(streamInfo.Destination.IP.Address), Convert.ToInt16(streamInfo.D estination.uPort), (PlayLoadTypes)1, 7); while(dontStop){ data = GetData(); service.SetFrames(data); } *THE CODE:* char * ConvertUnsignedToConstChar(unsigned item) { ostringstream convert; // stream used for the conversion convert << item; // insert the textual representation of 'Number' in the characters in the stream string resultString = convert.str(); return &resultString[0]; } void afterPlayingFunction(void *clientdata); OnDemandServerMediaSubsessionMarina::OnDemandServerMediaSubsessionMarina( UsageEnvironment & env,Boolean reuseFirstSource,portNumBits initialPortNum,PlayLoadTypes playloadType,unsigned clientSessionId,struct in_addr destAddr,Port rtpDestPort) : OnDemandServerMediaSubsession(env,reuseFirstSource,6970) { this->playloadType = playloadType; this->videoSource = this->createNewStreamSource(clientSessionId,ESTBITRATE); u_int8_t variable = 255; this->rtpGroupsock = new Groupsock (env,destAddr, rtpDestPort,variable); Port rtpcDestPort(5003); this->m_pRtcpGroupsock = new Groupsock(env, destAddr, rtpcDestPort, 255); unsigned char rtpPayloadTypeIfDynamic = 96; this->videoSink = this->createNewRTPSink (rtpGroupsock, rtpPayloadTypeIfDynamic, this->videoSource); } void OnDemandServerMediaSubsessionMarina::setPlayloadType(PlayLoadTypes playloadType) { this->playloadType = playloadType; } void OnDemandServerMediaSubsessionMarina::SetDestination(Destinations *dest, unsigned clientSessionId) { fDestinationsHashTable->Add(ConvertUnsignedToConstChar(clientSessionId), dest); } FramedSource * OnDemandServerMediaSubsessionMarina::createNewStreamSource (unsigned clientSessionId, unsigned &estBitrate) { //Do not need the params DeviceParameters params; return FramedSourceMarina::createNew(this->envir(),params); } RTPSink * OnDemandServerMediaSubsessionMarina::createNewRTPSink (Groupsock *rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource *inputSource) { switch(this->playloadType) { case MPEG4: return MPEG4ESVideoRTPSink::createNew( this->envir(), rtpGroupsock, rtpPayloadTypeIfDynamic,90000); break; case H264: return H264VideoRTPSink::createNew( this->envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); break; default: throw; } return NULL; }; RTPService::RTPService(__int64 destAdd, short port,PlayLoadTypes playloadType,int clientSessionId) { struct in_addr destAddr; destAddr.s_addr = (ULONG)destAdd; Port rtpDestPort(port); Port rtpcDestPort(port+1); this->dest = new Destinations(destAddr,rtpDestPort,rtpcDestPort); this->start = false; catcher = gcnew CatchEvent(); catcher->SetCatcher(this); this->scheduler = BasicTaskScheduler::createNew(); envv = BasicUsageEnvironment::createNew(*scheduler); portNumBits initialPortNumAux = 55000; //this->dest = new Destinations(); this->onDemandServerMediaSub = new OnDemandServerMediaSubsessionMarina(*envv,false,initialPortNumAux,playloadType,clientSessionId,destAddr,rtpDestPort); unsigned char CNAME[101]; gethostname((char*)CNAME, 100); CNAME[100] = '\0'; this->rtcp = RTCPInstance::createNew(*envv, this->onDemandServerMediaSub->rtpGroupsock,1512, CNAME,this->videoSink, NULL /* we're a server */,True /* we're a SSM source */); this->videoSource = this->onDemandServerMediaSub->videoSource; this->videoSink = this->onDemandServerMediaSub->videoSink; this->onDemandServerMediaSub->SetDestination(this->dest,clientSessionId); Groupsock *rtpGroupsock = this->onDemandServerMediaSub->rtpGroupsock; char const* streamName = "testStream"; this->sms = ServerMediaSession::createNew(*envv, streamName, streamName,streamName, True); this->sms->addSubsession((ServerMediaSubsession*)this->onDemandServerMediaSub); this->sms->addSubsession(PassiveServerMediaSubsession::createNew(*this->videoSink,this->rtcp )); } void RTPService::StartStreaming() { this->rtspServer = RTSPServer::createNew(*envv, 8554); rtspServer->addServerMediaSession(sms); this->start = true; MPEG4VideoStreamFramer *videoSource1 = MPEG4VideoStreamFramer::createNew(*envv, this->videoSource); char* url = this->rtspServer->rtspURL(this->sms); this->videoSink->startPlaying(*videoSource1, afterPlayingFunction, this->videoSink); this->envv->taskScheduler().doEventLoop(); } void RTPService::StopStreaming() { this->start = false; videoSink->stopPlaying(); } void RTPService:: SetFrames(FrameData ^ data) { FramedSourceMarina * source = (FramedSourceMarina*)this->videoSource; source->setFrames(new NativeFrameData(data->data, data->dataLength)); TaskScheduler* ourScheduler = this->scheduler; //%%% TO BE WRITTEN %%% FramedSourceMarina* ourDevice = (FramedSourceMarina*)this->videoSource; //%%% TO BE WRITTEN %%% if (ourScheduler != NULL) { // sanity check ourScheduler->triggerEvent(FramedSourceMarina::eventTriggerId, ourDevice); } } void RTPService::SetIntermediator(Intermediator ^provider) { this->provider = provider; } /********************************************************/ FramedSourceMarina* FramedSourceMarina::createNew(UsageEnvironment& env, DeviceParameters params) { return new FramedSourceMarina(env, params); } EventTriggerId FramedSourceMarina::eventTriggerId = 0; unsigned FramedSourceMarina::referenceCount = 0; void FramedSourceMarina::setFrames(NativeFrameData * frame) { semaphore->enter(); frames.push(frame); semaphore->leave(); } FramedSourceMarina::FramedSourceMarina(UsageEnvironment& env, DeviceParameters params) : FramedSource(env), fParams(params) { semaphore = new CSeccionCritica() ; if (referenceCount == 0) { //Nothing todo } ++referenceCount; if (eventTriggerId == 0) { eventTriggerId = envir().taskScheduler().createEventTrigger(deliverFrame0); } } FramedSourceMarina::~FramedSourceMarina() { // Any instance-specific 'destruction' (i.e., resetting) of the device would be done here: //%%% TO BE WRITTEN %%% --referenceCount; if (referenceCount == 0) { // Any global 'destruction' (i.e., resetting) of the device would be done here: //%%% TO BE WRITTEN %%% // Reclaim our 'event trigger' envir().taskScheduler().deleteEventTrigger(eventTriggerId); eventTriggerId = 0; } } void FramedSourceMarina::doGetNextFrame() { if (!frames.empty() ) { deliverFrame(); }else { handleClosure(this); return; } } void FramedSourceMarina::deliverFrame0(void* clientData) { ((FramedSourceMarina*)clientData)->deliverFrame(); } void FramedSourceMarina::deliverFrame() { semaphore->enter(); NativeFrameData *frameData = (NativeFrameData *)frames.front(); frames.pop(); semaphore->leave(); if (frameData != NULL){ *//the frameData->data is a char * data ** ** u_int8_t* newFrameDataStart = (u_int8_t*)frameData->data;* unsigned newFrameSize = (unsigned)frameData->dataLength; // Deliver the data here: if (newFrameSize > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = newFrameSize - fMaxSize; } else { fFrameSize = newFrameSize; } gettimeofday(&fPresentationTime, NULL); unsigned char *ftoAux = new unsigned char[frameData->dataLength]; for(int i = 0;idataLength;i++) { ftoAux[i] = frameData->data[i]; } this->fTo = ftoAux; //The memmove throws an exception //memmove(this->fTo, frameData->data, fFrameSize); FramedSource::afterGetting(this); } } void afterPlayingFunction(void *clientdata) { RTPSink *videoSink = (RTPSink*)clientdata; videoSink->stopPlaying(); }; -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 4 07:09:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Dec 2012 07:09:15 -0800 Subject: [Live-devel] I can not stream live video with my own framedSource In-Reply-To: <50BE044F.30109@eye-cam.com> References: <50BE044F.30109@eye-cam.com> Message-ID: <55973892-8B6F-4535-AB28-D8C0D47E2359@live555.com> There is so much wrong here that I barely know where to begin. But the big mistake in your code is that you are trying to create 'source' and 'sink' objects and start streaming from them yourself, in your own code. This is completely wrong. Our RTSP server implementation (specifically, our "OnDemandServerMediaSubsession" class, which you are subclassing) does all of this for you (when clients ask to play a stream). All you need to do is define and implement your own subclass of "OnDemandServerMediaSubsession" (by implementing the "createNewStreamSource()" and "createNewRTPSink()" virtual functions. For illustration, I suggest that you look at the code in "liveMedia/AMRAudioFileServerMediaSubsession.cpp". Your "OnDemandServerMediaSubsessionMarina" class should be just about as simple as this. In particular: 1/ The body of your "OnDemandServerMediaSubsessionMarina" constructor should probably be completely empty. In particular, you should *not* be creating any source or sink (or groupsock) objects here. (Also, because you will be streaming from a live input source, the "reuseFirstSource" parameter that you pass to the base class ("OnDemandServerMediaSubsession") constructor should be True. 2/ Your "createNewStreamSource()" implementation should create a new "FramedSourceMarina" object, as you do now, but it should then feed it into a new "MPEG4VideoStreamDiscreteFramer" object (note, *not* a "MPEG4VideoStreamFramer"), and you should return that object as the result of the function. (If, instead, you want to stream H.264, then you would create a "H264VideoStreamDiscreteFramer" instead.) You should also set the "estBitrate" result parameter (the stream's estimated bit rate in kbps). 3/ Most of your code in "RTPService::RTPService()" and "RTPService::StartStreaming()" is wrong. In particular, you should not be creating *any* source, sink, or groupsock objects here. And you should not be calling "startPlaying()" (or "stopPlaying()) *anywhere* in your code. (Again, our RTSP server implementation does this for you.) The only things that you should be doing here are (in order): - create a "TaskScheduler" and "UsageEnvironment". - create a "RTSPServer". - create a "ServerMediaSession" object. - create a "OnDemandServerMediaSubsessionMarina" object, and add this to the "ServerMediaSession" object. - add the "ServerMediaSession" object to the "RTSPServer". (Note: *Do not* create or use a "PassiveServerMediaSubsession" object at all; that's used only for multicast streaming, which you're not doing here.) - call "doEventLoop()", to enter the LIVE555 event loop. For illustration, I suggest that you look at the code for the "testOnDemandRTSPServer" demo application (see "testProgs/testOnDemandRTSPServer.cpp"), and understand how that works. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhara.250190 at gmail.com Wed Dec 5 01:11:00 2012 From: dhara.250190 at gmail.com (dhara bagadia) Date: Wed, 5 Dec 2012 09:11:00 +0000 Subject: [Live-devel] AAC Strean using live source(Device Source) Message-ID: Hi, I Want to stream AAC using my live source.But i didn't find any framer for aac.Do i need to implement my own AAC framer? Is there any way to stream aac data frame by frame instead of .aac file? Regards, Dhara -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 5 08:49:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Dec 2012 08:49:00 -0800 Subject: [Live-devel] AAC Strean using live source(Device Source) In-Reply-To: References: Message-ID: <5612E96D-1C3F-4AE7-BE29-24A6D4E92132@live555.com> > I Want to stream AAC using my live source.But i didn't find any framer for aac.Do i need to implement my own AAC framer? If your input source object delivers discrete AAC audio frames (i.e., one frame at a time), then you don't need a separate 'framer' object. (Just make sure that your input source object sets "fPresentationTime" properly (aligned with 'wall clock time'; i.e., the time that you'd get by calling "gettimeofday()"), and also sets "fDurationInMicroseconds" properly.) The "RTPSink" subclass that you would use for streaming AAC audio is a "MPEG4GenericRTPSink". (See "liveMedia/ADTSAudioFileServerMediaSubsession.cpp" for an illustration of how to use it to stream AAC.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From swbms at suhdol.co.kr Wed Dec 5 21:50:55 2012 From: swbms at suhdol.co.kr (swbms at suhdol.co.kr) Date: Thu, 6 Dec 2012 14:50:55 +0900 Subject: [Live-devel] How about liveMedia make? Message-ID: <702C914879B94F27B2D2186BE2669B0F@BMS> Hello!! **** How about liveMedia make? - source package : live.2012.11.30 - my system : sun unix [suhdol] /home/home/mds/live> uname -a SunOS suhdol 5.10 Generic_147441-01 i86pc i386 i86pc [SUHDOL] /export/home/mds/live> isainfo -kv 64-bit sparcv9 kernel modules - try to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> - change config.solaris-64bit COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = cc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = c++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated OBJ = o LINK = c++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - rechange config.solaris-64bit COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated OBJ = o LINK = g++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - rechange config.solaris-64bit COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = g++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' ***how about make? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Wed Dec 5 23:15:41 2012 From: kingaceck at 163.com (kingaceck) Date: Thu, 6 Dec 2012 15:15:41 +0800 Subject: [Live-devel] proxy server crash Message-ID: <201212061515405886120@163.com> Hi I use live555ProxyServer(versin 2012.11.30 ) to relay rtp packet from Darwin streaming server.I do the following steps and the live555ProxyServer break down.The steps like this: 1)starting up the live555ProxyServer 2)connect to the server using vlc(rtsp://129.1.5.156/proxyStream) 3)close the vlc (or click the stop button) to stop playing 4)stop the Darwion streaming server After step 4 the live555ProxyServer break down. If I didn't excute the third step the server is ok. Here is the log from catchsegv Segmentation fault *** Segmentation fault Register dump: EAX: 73550a0d EBX: 0917bd48 ECX: 00000000 EDX: 36203a71 ESI: bfbf3e6c EDI: 09179a04 EBP: bfbf3de8 ESP: bfbf3d9c EIP: 0807942e EFLAGS: 00010206 CS: 0073 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Trap: 0000000d Error: 00000000 OldMask: 00000000 ESP/signal: bfbf3d9c CR2: 00000000 FPUCW: ffff037f FPUSW: ffff0120 TAG: ffffffff IPOFF: 0805e77d CSSEL: 0073 DATAOFF: bfbf3d20 DATASEL: 007b ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000 ST(2) 0000 8000000000000000 ST(3) 0000 8000000000000000 ST(4) 0000 8000000000000000 ST(5) 0000 a469be0000000000 ST(6) 0000 0000000000000000 ST(7) 0000 ecdd48b8d4000000 Backtrace: /lib/libSegFault.so(+0x206f)[0x6df06f] ??:0(??)[0x96e400] ??:0(_ZN12RTCPInstance22incomingReportHandler1Ev)[0x805f464] ??:0(_ZN18BasicTaskScheduler10SingleStepEj)[0x808667e] ??:0(_ZN19BasicTaskScheduler011doEventLoopEPc)[0x8088100] ??:0(main)[0x8049b32] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x737bd6] ??:0(_start)[0x8049531] Memory map: 00110000-00134000 r-xp 00000000 08:01 1839438 /lib/tls/i686/cmov/libm-2.11.1.so 00134000-00135000 r--p 00023000 08:01 1839438 /lib/tls/i686/cmov/libm-2.11.1.so 00135000-00136000 rw-p 00024000 08:01 1839438 /lib/tls/i686/cmov/libm-2.11.1.so 006dd000-006e0000 r-xp 00000000 08:01 1835038 /lib/libSegFault.so 006e0000-006e1000 r--p 00002000 08:01 1835038 /lib/libSegFault.so 006e1000-006e2000 rw-p 00003000 08:01 1835038 /lib/libSegFault.so 00721000-00874000 r-xp 00000000 08:01 1839430 /lib/tls/i686/cmov/libc-2.11.1.so 00874000-00875000 ---p 00153000 08:01 1839430 /lib/tls/i686/cmov/libc-2.11.1.so 00875000-00877000 r--p 00153000 08:01 1839430 /lib/tls/i686/cmov/libc-2.11.1.so 00877000-00878000 rw-p 00155000 08:01 1839430 /lib/tls/i686/cmov/libc-2.11.1.so 00878000-0087b000 rw-p 00000000 00:00 0 0096e000-0096f000 r-xp 00000000 00:00 0 [vdso] 00a7c000-00a97000 r-xp 00000000 08:01 1835034 /lib/ld-2.11.1.so 00a97000-00a98000 r--p 0001a000 08:01 1835034 /lib/ld-2.11.1.so 00a98000-00a99000 rw-p 0001b000 08:01 1835034 /lib/ld-2.11.1.so 00c8e000-00d77000 r-xp 00000000 08:01 2359440 /usr/lib/libstdc++.so.6.0.13 00d77000-00d7b000 r--p 000e9000 08:01 2359440 /usr/lib/libstdc++.so.6.0.13 00d7b000-00d7c000 rw-p 000ed000 08:01 2359440 /usr/lib/libstdc++.so.6.0.13 00d7c000-00d83000 rw-p 00000000 00:00 0 00f2a000-00f47000 r-xp 00000000 08:01 1839137 /lib/libgcc_s.so.1 00f47000-00f48000 r--p 0001c000 08:01 1839137 /lib/libgcc_s.so.1 00f48000-00f49000 rw-p 0001d000 08:01 1839137 /lib/libgcc_s.so.1 08048000-080a6000 r-xp 00000000 00:14 22977 /diske/live/proxyServer/live555ProxyServer 080a6000-080a7000 r--p 0005d000 00:14 22977 /diske/live/proxyServer/live555ProxyServer 080a7000-080ac000 rw-p 0005e000 00:14 22977 /diske/live/proxyServer/live555ProxyServer 080ac000-080ad000 rw-p 00000000 00:00 0 0916a000-091aa000 rw-p 00000000 00:00 0 [heap] b77f5000-b77f7000 rw-p 00000000 00:00 0 b7805000-b7807000 rw-p 00000000 00:00 0 bfbe1000-bfbf6000 rw-p 00000000 00:00 0 [stack] 2012-12-06 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 6 01:59:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2012 01:59:59 -0800 Subject: [Live-devel] proxy server crash In-Reply-To: <201212061515405886120@163.com> References: <201212061515405886120@163.com> Message-ID: <6FC11742-09DA-4A8F-812B-722A134DC557@live555.com> Sorry, but I can't reproduce this, so you're going to have to track it down yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhara.250190 at gmail.com Thu Dec 6 02:04:38 2012 From: dhara.250190 at gmail.com (dhara bagadia) Date: Thu, 6 Dec 2012 15:34:38 +0530 Subject: [Live-devel] AAC Strean using live source(Device Source) In-Reply-To: <5612E96D-1C3F-4AE7-BE29-24A6D4E92132@live555.com> References: <5612E96D-1C3F-4AE7-BE29-24A6D4E92132@live555.com> Message-ID: That's true but what modifications are required in CreateStreamsource Virtual function as it is returning ADTSFileSource Instance. ADTSFileSource takes name of file as an argument where in my case an aac audio frame is provided by my device source(LiveSource). On Wed, Dec 5, 2012 at 10:19 PM, Ross Finlayson wrote: > I Want to stream AAC using my live source.But i didn't find any framer for > aac.Do i need to implement my own AAC framer? > > > If your input source object delivers discrete AAC audio frames (i.e., one > frame at a time), then you don't need a separate 'framer' object. (Just > make sure that your input source object sets "fPresentationTime" properly > (aligned with 'wall clock time'; i.e., the time that you'd get by calling > "gettimeofday()"), and also sets "fDurationInMicroseconds" properly.) > > The "RTPSink" subclass that you would use for streaming AAC audio is a > "MPEG4GenericRTPSink". (See > "liveMedia/ADTSAudioFileServerMediaSubsession.cpp" for an illustration of > how to use it to stream AAC.) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhara.250190 at gmail.com Thu Dec 6 02:15:12 2012 From: dhara.250190 at gmail.com (dhara bagadia) Date: Thu, 6 Dec 2012 15:45:12 +0530 Subject: [Live-devel] How about liveMedia make? In-Reply-To: <702C914879B94F27B2D2186BE2669B0F@BMS> References: <702C914879B94F27B2D2186BE2669B0F@BMS> Message-ID: Hi, I think you are using wrong config file.You should generate your makefile using ./genMakefiles sunos Thanks & Regards Dhara On Thu, Dec 6, 2012 at 11:20 AM, wrote: > *Hello!!* > ***** How about liveMedia make?* > *- source package : live.2012.11.30* > *- my system : sun unix* > [suhdol] /home/home/mds/live> uname -a > SunOS suhdol 5.10 Generic_147441-01 i86pc i386 i86pc > [SUHDOL] /export/home/mds/live> isainfo -kv > 64-bit sparcv9 kernel modules > *- try to make* > [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit > [SUHDOL] /export/home/mds/live> make > cd liveMedia ; make > make: Fatal error: Don't know how to make target `Media.o' > Current working directory /export/home/mds/live/liveMedia > *** Error code 1 > make: Fatal error: Command failed for target `all' > [SUHDOL] /export/home/mds/live> > *- change config.solaris-64bit* > COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O > -DSOLARIS -DSOCKLEN_T=socklen_t > #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t > C = c > C_COMPILER = cc > C_FLAGS = $(COMPILE_OPTS) > CPP = cpp > CPLUSPLUS_COMPILER = c++ > #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall > CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated > OBJ = o > LINK = c++ -m64 -o > LINK_OPTS = -L. > CONSOLE_LINK_OPTS = $(LINK_OPTS) > LIBRARY_LINK = ld -o > LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn > LIB_SUFFIX = a > LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl > LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) > EXE = > *-retry to make* > [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit > [SUHDOL] /export/home/mds/live> make > cd liveMedia ; make > make: Fatal error: Don't know how to make target `Media.o' > Current working directory /export/home/mds/live/liveMedia > *** Error code 1 > make: Fatal error: Command failed for target `all' > *- rechange config.solaris-64bit* > ** > COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O > -DSOLARIS -DSOCKLEN_T=socklen_t > #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t > C = c > C_COMPILER = gcc > C_FLAGS = $(COMPILE_OPTS) > CPP = cpp > CPLUSPLUS_COMPILER = g++ > #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall > CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated > OBJ = o > LINK = g++ -m64 -o > LINK_OPTS = -L. > CONSOLE_LINK_OPTS = $(LINK_OPTS) > LIBRARY_LINK = ld -o > LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn > LIB_SUFFIX = a > LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl > LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) > EXE = > ** > *-retry to make* > ** > [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit > [SUHDOL] /export/home/mds/live> make > cd liveMedia ; make > make: Fatal error: Don't know how to make target `Media.o' > Current working directory /export/home/mds/live/liveMedia > *** Error code 1 > make: Fatal error: Command failed for target `all' > *- rechange config.solaris-64bit* > ** > COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t > #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t > C = c > C_COMPILER = gcc > C_FLAGS = $(COMPILE_OPTS) > CPP = cpp > CPLUSPLUS_COMPILER = g++ > #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall > CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall > OBJ = o > LINK = g++ -m64 -o > LINK_OPTS = -L. > CONSOLE_LINK_OPTS = $(LINK_OPTS) > LIBRARY_LINK = ld -o > LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn > LIB_SUFFIX = a > LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl > LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) > EXE = > *-retry to make* > ** > [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit > [SUHDOL] /export/home/mds/live> make > cd liveMedia ; make > make: Fatal error: Don't know how to make target `Media.o' > Current working directory /export/home/mds/live/liveMedia > *** Error code 1 > make: Fatal error: Command failed for target `all' > > ****how about make?* > > ** > ** > *Thank you* > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 6 07:02:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2012 07:02:23 -0800 Subject: [Live-devel] AAC Strean using live source(Device Source) In-Reply-To: References: <5612E96D-1C3F-4AE7-BE29-24A6D4E92132@live555.com> Message-ID: <7CC6A476-08C0-4408-929A-B6629E57DD71@live555.com> > That's true but what modifications are required in CreateStreamsource Virtual function as it is returning ADTSFileSource Instance. ADTSFileSource takes name of file as an argument where in my case an aac audio frame is provided by my device source(LiveSource). Your "createNewStreamSource()" implementation simply returns a new instance of your new 'device source' class. (It should also set "estBitrate" - the stream's estimated bit rate in kbps.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Thu Dec 6 09:22:31 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 6 Dec 2012 09:22:31 -0800 Subject: [Live-devel] RTP header in an MPEG2-TS In-Reply-To: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> References: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> Message-ID: Hello Ross, Can you please tell me where exactly in testMPEG2TransportReceiver, the RTP headers are extracted? Or where the RTP packets are transmitted to the user without RTP headers? Thanks, -Zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, November 05, 2012 7:54 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP header in an MPEG2-TS I have an encapsulated MPEG2-TS input stream with RTP header. By this I assume you mean that your input stream consists of RTP packets containing MPEG-2 TS data. Is LiveMedia able to parse such stream? Can it extract those RTP headers and return the stream without them? Yes. Note, for example, the code for the "testMPEG2TransportReceiver" demo application, which does this - it receives a stream of RTP packets that contain MPEG-2 Transport Stream data, and writes the Transport Stream data to a file. See "testProgs/testMPEG2TransportReceiver.cpp". Of course, to use it on your stream, you'll probably need to change "sessionAddressStr" and "rtpPortNum". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Guy.Bonneau at miranda.com Thu Dec 6 11:26:18 2012 From: Guy.Bonneau at miranda.com (Guy.Bonneau at miranda.com) Date: Thu, 6 Dec 2012 14:26:18 -0500 Subject: [Live-devel] Incomplete decoded image data In-Reply-To: <4AC300EE-AAA6-470D-89F0-A902A5C23233@live555.com> References: <4AC300EE-AAA6-470D-89F0-A902A5C23233@live555.com> Message-ID: This is a guessing but by digging in the encoded parameters you'll probably be able to confirm this hypothesis. If the "display" picture is really 800x600 as provided by the attached png file then the stream parameter might specify a 800x600 video display. Yet the camera might encode only the 592 lines since 600 is not a multiple of 16 lines. The last 8 lines from the FFMPEG (VLC) decoder seems shifted and might be an artefact of the internal buffer decoding. However the Cuda decoder might "realize" that the encoded video is only 592 lines and might replace the last missing 8 lines with black data. Note that this doesn't explain why the last valid macroblock of Cuda seems to be corrupted. Use Elecard StreamEye Analyzer ! it will probably help by giving you more hints. GB From: Ross Finlayson To: LIVE555 Streaming Media - development & use , Date: 2012-11-30 15:32 Subject: Re: [Live-devel] Incomplete decoded image data Sent by: > the conclusion I draw is that ther is an error in my live555 borrowed > code. If the only difference between your two systems is the decoder that you use, then that's a rather strange conclusion to draw. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From finlayson at live555.com Thu Dec 6 12:36:32 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2012 12:36:32 -0800 Subject: [Live-devel] RTP header in an MPEG2-TS In-Reply-To: References: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> Message-ID: > Can you please tell me where exactly in testMPEG2TransportReceiver, the RTP headers are extracted? Or where the RTP packets are transmitted to the user without RTP headers? This is done by the "SimpleRTPSource" class, and, in particular by its parent classes "MultiFramedRTPSource" and "RTPSource". But you shouldn't have to care about this. (If you wanted to receive raw-UDP data instead - i.e., packets sent without RTP headers - then you would have used a "BasicUDPSource" instead.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Thu Dec 6 13:12:00 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 6 Dec 2012 13:12:00 -0800 Subject: [Live-devel] RTP header in an MPEG2-TS In-Reply-To: References: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> Message-ID: Don't I if I want to call the "testMPEG2TransportReceiver" functions from my own server? From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, December 06, 2012 3:37 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP header in an MPEG2-TS Can you please tell me where exactly in testMPEG2TransportReceiver, the RTP headers are extracted? Or where the RTP packets are transmitted to the user without RTP headers? This is done by the "SimpleRTPSource" class, and, in particular by its parent classes "MultiFramedRTPSource" and "RTPSource". But you shouldn't have to care about this. (If you wanted to receive raw-UDP data instead - i.e., packets sent without RTP headers - then you would have used a "BasicUDPSource" instead.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 6 13:24:28 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2012 13:24:28 -0800 Subject: [Live-devel] RTP header in an MPEG2-TS In-Reply-To: References: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> Message-ID: <800D714A-8D16-44B8-86BA-F1CFD079BD59@live555.com> > Don?t I if I want to call the ?testMPEG2TransportReceiver? functions from my own server? Your question makes no sense. Please explain clearly and specifically what you want to do. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Thu Dec 6 13:40:21 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 6 Dec 2012 13:40:21 -0800 Subject: [Live-devel] RTP header in an MPEG2-TS In-Reply-To: <800D714A-8D16-44B8-86BA-F1CFD079BD59@live555.com> References: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> <800D714A-8D16-44B8-86BA-F1CFD079BD59@live555.com> Message-ID: :) Sorry. Right now the way that I am using testMPEG2TransportReceiver is by first running testMPEG2TransportStreamer on a server side and run testMPEG2TransportReceiver on the client side. It spits out on the stdout the stream in test.ts with no RTP headers. That works fine! In my environment, the WIFI Display server generates a stream that contains RTP headers and TS data. The WIFI Display client is expecting a stream with no RTP headers. So I am thinking of using the testMPEG2TransportReceiver code to extract/stream out the RTP headers before the WIFI Display client consumes the stream. Is that possible? Am I on the right track? Thanks, -Zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, December 06, 2012 4:24 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP header in an MPEG2-TS Don't I if I want to call the "testMPEG2TransportReceiver" functions from my own server? Your question makes no sense. Please explain clearly and specifically what you want to do. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 6 13:51:52 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2012 13:51:52 -0800 Subject: [Live-devel] RTP header in an MPEG2-TS In-Reply-To: References: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com> <800D714A-8D16-44B8-86BA-F1CFD079BD59@live555.com> Message-ID: <159DEF89-6762-4DDC-BD53-80161FD5F24F@live555.com> > Right now the way that I am using testMPEG2TransportReceiver is by first running testMPEG2TransportStreamer on a server side and run testMPEG2TransportReceiver on the client side. It spits out on the stdout the stream in test.ts with no RTP headers. That works fine! > In my environment, the WIFI Display server generates a stream that contains RTP headers and TS data. The WIFI Display client is expecting a stream with no RTP headers. So I am thinking of using the testMPEG2TransportReceiver code to extract/stream out the RTP headers before the WIFI Display client consumes the stream. Is that possible? Yes of course. You can just change the "testMPEG2TransportReceiver" code to use a different multicast address/port, or (perhaps) to receive via unicast instead of multicast. See Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhara.250190 at gmail.com Thu Dec 6 08:40:51 2012 From: dhara.250190 at gmail.com (dhara bagadia) Date: Thu, 6 Dec 2012 22:10:51 +0530 Subject: [Live-devel] AAC Strean using live source(Device Source) In-Reply-To: <7CC6A476-08C0-4408-929A-B6629E57DD71@live555.com> References: <5612E96D-1C3F-4AE7-BE29-24A6D4E92132@live555.com> <7CC6A476-08C0-4408-929A-B6629E57DD71@live555.com> Message-ID: ok so do i need to specify sampling frequency,channel configuration and config string in my new device source instance?if yes then how? Can you please provide me sample code for that? On Thu, Dec 6, 2012 at 8:32 PM, Ross Finlayson wrote: > That's true but what modifications are required in CreateStreamsource > Virtual function as it is returning ADTSFileSource Instance. ADTSFileSource > takes name of file as an argument where in my case an aac audio frame is > provided by my device source(LiveSource). > > > Your "createNewStreamSource()" implementation simply returns a new > instance of your new 'device source' class. (It should also set > "estBitrate" - the stream's estimated bit rate in kbps.) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swbms at suhdol.co.kr Fri Dec 7 00:29:01 2012 From: swbms at suhdol.co.kr (swbms at suhdol.co.kr) Date: Fri, 7 Dec 2012 17:29:01 +0900 Subject: [Live-devel] How about liveMedia make? In-Reply-To: References: <702C914879B94F27B2D2186BE2669B0F@BMS> Message-ID: Thank you for the sincere answer But Even if the result is the same as sunos Please check below. - make [SUHDOL] /export/home/mds/live> ./genMakefiles sunos [SUHDOL] /export/home/mds/live> make cd liveMedia ; make c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. -DBSD=1 -O -Wall Media.cc c++: Media.cc: ?? ???? ????? ?? c++: no input files *** Error code 1 make: Fatal error: Command failed for target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - change config.sunos COMPILE_OPTS = $(INCLUDES) -I. -DBSD=1 -O C = c C_COMPILER = cc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = c++ CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = c++ -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -r -Bstatic LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = - make [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> - change config.sunos COMPILE_OPTS = $(INCLUDES) -I. -DBSD=1 -O C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = g++ -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -r -Bstatic LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = -make [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> How to build please let me know. Thank you. From: dhara bagadia Sent: Thursday, December 06, 2012 7:15 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] How about liveMedia make? Hi, I think you are using wrong config file.You should generate your makefile using ./genMakefiles sunos Thanks & Regards Dhara On Thu, Dec 6, 2012 at 11:20 AM, wrote: Hello!! **** How about liveMedia make? - source package : live.2012.11.30 - my system : sun unix [suhdol] /home/home/mds/live> uname -a SunOS suhdol 5.10 Generic_147441-01 i86pc i386 i86pc [SUHDOL] /export/home/mds/live> isainfo -kv 64-bit sparcv9 kernel modules - try to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> - change config.solaris-64bit COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = cc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = c++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated OBJ = o LINK = c++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - rechange config.solaris-64bit COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated OBJ = o LINK = g++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - rechange config.solaris-64bit COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = g++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' ***how about make? Thank you _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------------------------------------------------------------------------- _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Dec 7 11:14:51 2012 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 7 Dec 2012 20:14:51 +0100 Subject: [Live-devel] IGMP V3 SSM ? Message-ID: <5601_1354907899_50C240FB_5601_7396_1_1BE8971B6CFF3A4F97AF4011882AA25501560721C1B1@THSONEA01CMS01P.one.grp> Hi Ross, I try to understand if there is some differences using IGMP v3 that have source code impact. I saw some code sample dealing with SSM that seems to use setsockopt MCAST_JOIN_SOURCE_GROUP instead of IP_ADD_MEMBERSHIP(35), other use IP_ADD_SOURCE_MEMBERSHIP. In live555 code it seems that SSM is supported (for one source) through IP_ADD_SOURCE_MEMBERSHIP. Could you help me to understand better what kind of IGMP is supported by live555 ? Thanks & Regards, Michel. [@@THALES GROUP RESTRICTED@@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 7 12:19:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Dec 2012 12:19:59 -0800 Subject: [Live-devel] IGMP V3 SSM ? In-Reply-To: <5601_1354907899_50C240FB_5601_7396_1_1BE8971B6CFF3A4F97AF4011882AA25501560721C1B1@THSONEA01CMS01P.one.grp> References: <5601_1354907899_50C240FB_5601_7396_1_1BE8971B6CFF3A4F97AF4011882AA25501560721C1B1@THSONEA01CMS01P.one.grp> Message-ID: <174F042A-61BB-4048-9DC5-EE3D7A4DAC58@live555.com> First, IGMP (like ICMP) is a data-link-level protocol that's implemented by the operating system. It is something that application developers (who live above the operating system) should never concern themselves with. You are apparently referring to "source-specific multicast", which is a type of IP multicast - using a special range of the IP multicast address space - that also specifies a single IP *source* address (for one-to-many multicast). This is more easily implemented - especially over wide-area networks - than traditional many-to-many IP multicast, in which there is no specific multicast source. Operating systems implement both kinds of IP multicast using the IGMP protocol, but once again, application developers (like you) don't need to concern yourself with the workings of the operating system. But yes, we (the "LIVE555 Streaming Media" software) implements both kinds of IP multicast: traditional 'any source' multicast (ASM), and 'source-specific multicast (SSM). You can see several examples of this in the "testProgs" demo applications (grep for "SSM" if you care). Now, you were apparently referring to the difference between the following two sets of socket options (i.e., for "setsockopt()" calls): IP_ADD_MEMBERSHIP, IP_ADD_SOURCE_MEMBERSHIP (etc.), and MCAST_JOIN_GROUP, MCAST_JOIN_SOURCE_GROUP (etc.) These are used for two different APIs (to the *same* IGMP functionality). The first set of socket options - that we use - are used with an API that uses IP4 IP addresses only (see RFC 3478, section 4). The second set of socket options are used with an alternative API that uses IP addresses that might be either IPv4 or IPv6 (see RFC 3478, section 5). (If only IPv4 addresses are being used, then the two APIs are equivalent, but some older systems might not support the second API; that's why we don't use it.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From swbrowne at gmail.com Thu Dec 6 19:13:07 2012 From: swbrowne at gmail.com (Steve Browne) Date: Thu, 6 Dec 2012 22:13:07 -0500 Subject: [Live-devel] Dynamic buffer resizing (fNumTruncatedBytes) Message-ID: It doesn't seem like there's a way to dynamically resize buffers without losing data because in the afterGettingFunc if fNumTruncatedBytes > 0 you've already lost the data. The only post I've really seen talk about this is here: http://lists.live555.com/pipermail/live-devel/2009-January/010083.html It sounded like they came to the same conclusion. So with that in mind I created a patch that I'm hoping may get incorporated in a future release. Or at least some incarnation of it. See the attached file for details. The downside to doing it this way is that you're potentially allocating multiple times per frame, but I would imagine the code to reallocate should be allocating larger than what was requested anyway and its better than nothing. I made the new parameters for getNextFrame have default values of NULL, but perhaps the better approach for compatibility would be to add a getNextFrame2 that has these extra parameters. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DynamicBuffer.patch Type: application/octet-stream Size: 4806 bytes Desc: not available URL: From tbatra18 at gmail.com Fri Dec 7 07:09:01 2012 From: tbatra18 at gmail.com (Tarun Batra) Date: Fri, 7 Dec 2012 20:39:01 +0530 Subject: [Live-devel] How to find the frame size and no of packets sent? Message-ID: Hello All Sir i need to find out :- 1) the size of frame size/packet sent out for streaming 2)the no of packets sent out for streaming in a definite interval,interval will be set by user. Can i find the no of packets sent out for streaming in a definite interval using " unsigned packetCount()" function defined in RTPSink.hh ? Can you tell how can i find the packet size? I have written my own DeviceSource file and defined the play function as follows:- void play() { // Open the input file as a 'byte-stream file source': fi_params.nFICardFrameSize = TRANSPORT_PACKETS_PER_NETWORK_PACKET * TRANSPORT_PACKET_SIZE; fi_params.pfnGetRTPPayload = GetRTPPayload; fi_params.socketNum = videoSink->groupsockBeingUsed().socketNum(); DeviceParameters temp; fileSource = DeviceSourceFICard::createNew(*env, fi_params, temp); if (fileSource == NULL) { *env << "Unable to open Foresight card as a byte-stream file source\n"; exit(1); } FramedSource* videoES = fileSource; // Create a framer for the Video Elementary Stream: videoSource = MPEG1or2VideoStreamDiscreteFramer::createNew(*env, videoES); videoSink->startPlaying(*videoSource, afterPlaying, videoSink); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 7 22:22:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Dec 2012 22:22:03 -0800 Subject: [Live-devel] Dynamic buffer resizing (fNumTruncatedBytes) In-Reply-To: References: Message-ID: <78422157-134C-4CB3-8316-19928C7C170B@live555.com> > It doesn't seem like there's a way to dynamically resize buffers without losing data because in the afterGettingFunc if fNumTruncatedBytes > 0 you've already lost the data. That's correct. > So with that in mind I created a patch that I'm hoping may get incorporated in a future release. No, because the choice of how to handle the 'truncated data' situation is best left up to the receiver. As you noted, the data has been lost, but the receiver *may* then choose to allocate a larger-sized to use in subsequent calls to "getNextFrame()" (e.g., VLC does this), or it might not. In any case, we're not going to change the signature to "getNextFrame()", because it's used throughout the code - not just in the couple of places you noted. (It's possible that we'll completely change the way we handle buffers in some future revision of the software, but if that ever happens, it'll be a major, non-backwards-compatible revision.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Sat Dec 8 03:41:05 2012 From: bdrung at debian.org (Benjamin Drung) Date: Sat, 08 Dec 2012 12:41:05 +0100 Subject: [Live-devel] shared library Message-ID: <1354966865.19778.9.camel@deep-thought> Hi, we like to have a shared library of liblivemedia in Debian and Ubuntu [1]. This requires two things: First adjust the build system to create a shared library and second take care of proper SONAME, ABI/API changes management. I would be willing to help changing the build system to create a shared library. Would it make sense to change the build system from custom Makefiles to CMake or autotools? Taking care of a proper SONAME should be done upstream by the people developing the code, because they know when they add features or break the API or ABI. Are you interested supporting a shared library by taking care of a proper SONAME version? [1] http://bugs.debian.org/662774 -- Benjamin Drung Debian & Ubuntu Developer From finlayson at live555.com Sat Dec 8 06:26:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Dec 2012 06:26:51 -0800 Subject: [Live-devel] shared library In-Reply-To: <1354966865.19778.9.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> Message-ID: <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> I'm not planning any changes to the 'build system' itself. I would hope, however, that things like shared libraries could be accommodated by using a different "config.*" file - e.g., perhaps named something like "config.linux-with-shared-libraries" or "config.debian-with-shared-libraries" - and then using the exiting "genMakefiles" tool. So that's the approach that I would pursue first. (And as for the suggestion of switching to using 'CMake', see ) Personally, though, I don't particularly like shared libraries; in this day and age (with disk space and memory being so abundant) they're just more trouble than they're worth. (The only 'dynamic link' that I hope you put in Debian distributions is a 'link' to the URL "http://www.live555.com/liveMedia/", so that people can download the latest version of the code; the only version that we support :-) But of course, you're welcome to try building shared libraries if you wish. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Sat Dec 8 11:41:58 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Sat, 08 Dec 2012 11:41:58 -0800 Subject: [Live-devel] shared library In-Reply-To: <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> Message-ID: <50C39806.2040604@schuckmannacres.com> There is one really good reason to support shared libraries and that is to make it easier to full fill the obligations of the LGPL. The way it is now if you have a closed source application using this library and someone else wants to build thier own version of liveMedia to use with your application the developer must provide all the object files for their closed source code so that the new static version of livemedia can be linked in. Supporting this requirement is much simpler with a shared library and that's why most open source libraries support shared libraries. With regards to your build system I'd for one would very much appreciate a more traditional system I've thought of doing it myself a few times, the one you've got is one of the strangest, least flexible, and prone to errors that I've every seen. For instance your makefiles for windows can't produce running executable for dev studio 2008 and above (they don't add the manifests to the executable) and I don't think it is possible to fix this with your current make structure. Honestly Ross I like livemedia, it does the job very well and you do a pretty good job supporting the community of users but for an open source project you've got some pretty strange idea's regarding project management. Regards Matt S. On 12/8/2012 6:26 AM, Ross Finlayson wrote: > I'm not planning any changes to the 'build system' itself. I would > hope, however, that things like shared libraries could be accommodated > by using a different "config.*" file - e.g., perhaps named something > like "config.linux-with-shared-libraries" or > "config.debian-with-shared-libraries" - and then using the exiting > "genMakefiles" tool. So that's the approach that I would pursue first. > > (And as for the suggestion of switching to using 'CMake', see > ) > > Personally, though, I don't particularly like shared libraries; in > this day and age (with disk space and memory being so abundant) > they're just more trouble than they're worth. (The only 'dynamic > link' that I hope you put in Debian distributions is a 'link' to the > URL "http://www.live555.com/liveMedia/", so that people can download > the latest version of the code; the only version that we support :-) > But of course, you're welcome to try building shared libraries if you > wish. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Sat Dec 8 11:11:40 2012 From: bdrung at debian.org (Benjamin Drung) Date: Sat, 08 Dec 2012 20:11:40 +0100 Subject: [Live-devel] shared library In-Reply-To: <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> Message-ID: <1354993900.21788.18.camel@deep-thought> Am Samstag, den 08.12.2012, 06:26 -0800 schrieb Ross Finlayson: > I'm not planning any changes to the 'build system' itself. I would > hope, however, that things like shared libraries could be accommodated > by using a different "config.*" file - e.g., perhaps named something > like "config.linux-with-shared-libraries" or > "config.debian-with-shared-libraries" - and then using the exiting > "genMakefiles" tool. So that's the approach that I would pursue > first. Adding shared library support requires adding an additional make target that builds the additional .so files, because we want to keep the static library. This cannot be done by just adding some variables to config.linux-with-shared-libraries. > (And as for the suggestion of switching to using 'CMake', see > ) Thanks for the pointer. Can you point me to the latest proposed revision of cmake config files? The current 'build system' is suboptimal from a packager point of view. It cannot be adjusted by setting CFLAGS or LDFLAGS [1]. It has no install target to install the library and it's headers. Converting to cmake and add shared library support could maybe take less work than converting the current build system to support shared libraries. > Personally, though, I don't particularly like shared libraries; in > this day and age (with disk space and memory being so abundant) > they're just more trouble than they're worth. Shared libraries have a benefit: You don't have to rebuild the applications using the libraries when fixing a bug in the library. Building and uploading the library is enough to get it used by all application. If the ABI breaks and all applications needs a rebuild, this is catches by having a different binary package name. If the library provides only a static version, new uploads of the library will be unnoticed and the applications won't get rebuild. > (The only 'dynamic link' that I hope you put in Debian distributions > is a 'link' to the URL "http://www.live555.com/liveMedia/", so that > people can download the latest version of the code; the only version > that we support :-) The homepage field of the liblivemedia package points to http://www.live555.com. Should I change it to point to the URL mentioned above? > But of course, you're welcome to try building shared libraries if you > wish. I cannot do it properly without your help. Are you willing to maintain one variable with the SONAME version. The rules for changing this version are following: #------------------------------------------------------------------------------------ # The following is the libtool / shared library version. This doesn't have to # do anything with the release version. It MUST conform to the following rules: # # 1. Start with version information of `0:0:0' for each libtool library. # 2. Update the version information only immediately before a public release of # your software. More frequent updates are unnecessary, and only guarantee # that the current interface number gets larger faster. # 3. If the library source code has changed at all since the last update, then # increment revision (`c:r:a' becomes `c:r+1:a'). # 4. If any interfaces have been added, removed, or changed since the last update, # increment current, and set revision to 0. # 5. If any interfaces have been added since the last public release, then increment # age. # 6. If any interfaces have been removed since the last public release, then set age # to 0. SHARED_VERSION_INFO="0:0:0" [1] See 010_propagate_cflags.diff and 301_hardening.patch on http://patch-tracker.debian.org/package/liblivemedia/2012.11.30-1 -- Benjamin Drung Debian & Ubuntu Developer From finlayson at live555.com Sat Dec 8 19:31:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Dec 2012 19:31:17 -0800 Subject: [Live-devel] shared library In-Reply-To: <1354993900.21788.18.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> Message-ID: >> I'm not planning any changes to the 'build system' itself. I would >> hope, however, that things like shared libraries could be accommodated >> by using a different "config.*" file - e.g., perhaps named something >> like "config.linux-with-shared-libraries" or >> "config.debian-with-shared-libraries" - and then using the exiting >> "genMakefiles" tool. So that's the approach that I would pursue >> first. > > Adding shared library support requires adding an additional make target > that builds the additional .so files, because we want to keep the static > library. This cannot be done by just adding some variables to > config.linux-with-shared-libraries. OK, fair enough. So here's what I'll do. If you send me a "config.linux-with-shared-libraries" file that uses the existing build system to build *just* shared libraries - even though that's not what you want - then I'll add it to the distribution. But I'll also use it to see if I can upgrade the build system (e.g., upgrade the "genMakefiles" tool and/or the "Makefile.head"/"Makefile.tail" files) to support a new "config.linux-with-static-and-shared-libraries" file that will build both static and shared libraries. >> (And as for the suggestion of switching to using 'CMake', see >> ) > > Thanks for the pointer. Can you point me to the latest proposed revision > of cmake config files? I don't think any such things exist, because - as far as I know - nobody is actually using CMake to build our code. Anyway, as I noted in my July email message, CMake is a non-starter, unless/until it can work with FreeBSD and also Windows with MS Visual Studio v5.0. >> (The only 'dynamic link' that I hope you put in Debian distributions >> is a 'link' to the URL "http://www.live555.com/liveMedia/", so that >> people can download the latest version of the code; the only version >> that we support :-) > > The homepage field of the liblivemedia package points to > http://www.live555.com. Should I change it to point to the URL mentioned > above? Yes, please. >> But of course, you're welcome to try building shared libraries if you >> wish. > > I cannot do it properly without your help. Are you willing to maintain > one variable with the SONAME version. OK, I could do this. What would this variable look like (i.e., defined in a C/C++ source file)? Or do you mean that the variable would be defined in the Makefiles (rather than as a symbol in the library)? > # 3. If the library source code has changed at all since the last update, then > # increment revision (`c:r:a' becomes `c:r+1:a'). > # 4. If any interfaces have been added, removed, or changed since the last update, > # increment current, and set revision to 0. > # 5. If any interfaces have been added since the last public release, then increment > # age. > # 6. If any interfaces have been removed since the last public release, then set age > # to 0. These 'rules' seem very confusing, because the conditions that they describe can overlap. Example. If the current string is "c:r:a", and a new interface is added (but with no other changes), then does the new string become: - "c:r+1:a" (rule 3), or - "c+1:0:a" (rule 4), or - "c:r:a+1" (rule 5), or - "c+1:0:a+1" (rules 4 and 5) ??? It seems to me that the rules would be less confusing if, instead, they explained what happens in the following (non-overlapping!) situations: 1/ The code changes, but without any change to the API (i.e., interfaces). 2/ At least one interface changes, or is removed (i.e., so that existing code that uses the library would likely be incompatible with the new version). 3/ One or more interfaces were added, but no existing interfaces were changed or removed (i.e., so that existing code that uses the library might still remain compatible with the new version). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Sun Dec 9 06:09:51 2012 From: hackeron at gmail.com (Roman Gaufman) Date: Sun, 9 Dec 2012 14:09:51 +0000 Subject: [Live-devel] Ability to specify port number Message-ID: Here is a simple patch to allow specifying a port number, e.g. ./proxyServer/live555ProxyServer -p 10001 ... I often need to run multiple proxy servers on different ports, this allows to pass a port number as an argument to live555ProxyServer and I think would make a great addition if it were included in the upstream version: --- a/proxyServer/live555ProxyServer.cpp +++ b/proxyServer/live555ProxyServer.cpp @@ -27,6 +27,7 @@ UsageEnvironment* env; int verbosityLevel = 0; Boolean streamRTPOverTCP = False; portNumBits tunnelOverHTTPPortNum = 0; +portNumBits rtspServerPortNum = 554; char* username = NULL; char* password = NULL; @@ -34,6 +35,7 @@ void usage() { *env << "Usage: " << progName << " [-v|-V]" << " [-t|-T ]" + << " [-p ]" << " [-u ]" << " ... \n"; exit(1); @@ -89,6 +91,21 @@ int main(int argc, char** argv) { usage(); break; } + + case 'p': { + // set port + if (argc > 3 && argv[2][0] != '-') { + // The next argument is the RTSP server port number: + if (sscanf(argv[2], "%hu", &rtspServerPortNum) == 1 + && rtspServerPortNum > 0) { + ++argv; --argc; + break; + } + } + // If we get here, the option was specified incorrectly: + usage(); + break; + } case 'u': { // specify a username and password (to be used if the 'back end' (i.e., proxied) stream requires authentication) if (argc < 4) usage(); // there's no argv[3] (for the "password") @@ -131,12 +148,11 @@ int main(int argc, char** argv) { // access to the server. #endif - // Create the RTSP server. Try first with the default port number (554), + // Create the RTSP server. Try first with the default port number (554) or the one set by the caller, // and then with the alternative port number (8554): RTSPServer* rtspServer; - portNumBits rtspServerPortNum = 554; rtspServer = RTSPServer::createNew(*env, rtspServerPortNum, authDB); - if (rtspServer == NULL) { + if (rtspServer == NULL && rtspServerPortNum != 554) { rtspServerPortNum = 8554; rtspServer = RTSPServer::createNew(*env, rtspServerPortNum, authDB); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Dec 9 17:53:36 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Dec 2012 17:53:36 -0800 Subject: [Live-devel] Ability to specify port number In-Reply-To: References: Message-ID: <4760991E-D92C-4138-9430-6E3E7CF250C9@live555.com> > I often need to run multiple proxy servers on different ports Why? You realize, I hope, that the existing "LIVE555 Proxy Server" application can handle multiple back-end servers (by specifying multiple back-end "rtsp://" URLs on the command line). You can do this with a single server; you don't need to run more than one. > , this allows to pass a port number as an argument to live555ProxyServer and I think would make a great addition if it were included in the upstream version No, I probably won't be including this released code, because ideally people should be using one of the IANA-defined port numbers for RTSP: 554 and 8554. Of course, you are welcome to make any changes to this application code - or develop your own application code - if you wish. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Sun Dec 9 18:25:35 2012 From: hackeron at gmail.com (Roman Gaufman) Date: Mon, 10 Dec 2012 02:25:35 +0000 Subject: [Live-devel] Ability to specify port number In-Reply-To: <4760991E-D92C-4138-9430-6E3E7CF250C9@live555.com> References: <4760991E-D92C-4138-9430-6E3E7CF250C9@live555.com> Message-ID: <89F9E9EE-55B7-4113-81B5-CDBBA9589678@gmail.com> I tried specifying 3 x 1080p sources and 8 x D1 sources and the result was horrible, frames were jumping back and forth and some sources would freeze after a while - since adding the patch and running a separate server per port all quality and stability issues went away. Sent from my iPad On 10 Dec 2012, at 01:53, Ross Finlayson wrote: >> I often need to run multiple proxy servers on different ports > > Why? You realize, I hope, that the existing "LIVE555 Proxy Server" application can handle multiple back-end servers (by specifying multiple back-end "rtsp://" URLs on the command line). You can do this with a single server; you don't need to run more than one. > > >> , this allows to pass a port number as an argument to live555ProxyServer and I think would make a great addition if it were included in the upstream version > > No, I probably won't be including this released code, because ideally people should be using one of the IANA-defined port numbers for RTSP: 554 and 8554. Of course, you are welcome to make any changes to this application code - or develop your own application code - if you wish. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From swbms at suhdol.co.kr Mon Dec 10 23:21:04 2012 From: swbms at suhdol.co.kr (=?UTF-8?B?67Cw66y47IiY?=) Date: Tue, 11 Dec 2012 16:21:04 +0900 Subject: [Live-devel] Tell us how to make? In-Reply-To: References: <702C914879B94F27B2D2186BE2669B0F@BMS> Message-ID: <637D898F0E284F919D6F28BFD990B2AD@bmsPC> HI No answer and sends it back. make an error and resolved to ask me. thank you. From: swbms at suhdol.co.kr Sent: Friday, December 07, 2012 5:29 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] How about liveMedia make? Thank you for the sincere answer But Even if the result is the same as sunos Please check below. - make [SUHDOL] /export/home/mds/live> ./genMakefiles sunos [SUHDOL] /export/home/mds/live> make cd liveMedia ; make c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. -DBSD=1 -O -Wall Media.cc c++: Media.cc: ?? ???? ????? ?? c++: no input files *** Error code 1 make: Fatal error: Command failed for target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - change config.sunos COMPILE_OPTS = $(INCLUDES) -I. -DBSD=1 -O C = c C_COMPILER = cc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = c++ CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = c++ -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -r -Bstatic LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = - make [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> - change config.sunos COMPILE_OPTS = $(INCLUDES) -I. -DBSD=1 -O C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = g++ -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -r -Bstatic LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = -make [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> How to build please let me know. Thank you. From: dhara bagadia Sent: Thursday, December 06, 2012 7:15 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] How about liveMedia make? Hi, I think you are using wrong config file.You should generate your makefile using ./genMakefiles sunos Thanks & Regards Dhara On Thu, Dec 6, 2012 at 11:20 AM, wrote: Hello!! **** How about liveMedia make? - source package : live.2012.11.30 - my system : sun unix [suhdol] /home/home/mds/live> uname -a SunOS suhdol 5.10 Generic_147441-01 i86pc i386 i86pc [SUHDOL] /export/home/mds/live> isainfo -kv 64-bit sparcv9 kernel modules - try to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' [SUHDOL] /export/home/mds/live> - change config.solaris-64bit COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = cc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = c++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated OBJ = o LINK = c++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - rechange config.solaris-64bit COMPILE_OPTS = -I/export/home/mds/live/liveMedia $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -Wno-deprecated OBJ = o LINK = g++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' - rechange config.solaris-64bit COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t #COMPILE_OPTS = $(INCLUDES) -m64 -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t C = c C_COMPILER = gcc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = g++ #CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = g++ -m64 -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = ld -o LIBRARY_LINK_OPTS = $(LINK_OPTS) -64 -r -dn LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = -lsocket -lnsl LIBS_FOR_GUI_APPLICATION = $(LIBS_FOR_CONSOLE_APPLICATION) EXE = -retry to make [SUHDOL] /export/home/mds/live> ./genMakefiles solaris-64bit [SUHDOL] /export/home/mds/live> make cd liveMedia ; make make: Fatal error: Don't know how to make target `Media.o' Current working directory /export/home/mds/live/liveMedia *** Error code 1 make: Fatal error: Command failed for target `all' ***how about make? Thank you _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------------------------------------------------------------------------- _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------------------------------------------------------------------------- _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 11 00:31:06 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Dec 2012 21:31:06 +1300 Subject: [Live-devel] Tell us how to make? In-Reply-To: <637D898F0E284F919D6F28BFD990B2AD@bmsPC> References: <702C914879B94F27B2D2186BE2669B0F@BMS> <637D898F0E284F919D6F28BFD990B2AD@bmsPC> Message-ID: <33D308EA-49E7-458D-984F-9B6F15F17C1D@live555.com> > No answer and sends it back. DO NOT send the same question to the mailing list more than once! This is basic 'netiquette', and is also explained clearly in the FAQ (that everyone is asked to read before posting to the mailing list). Because of this, all future postings from you will be moderated. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Tue Dec 11 10:06:29 2012 From: bdrung at debian.org (Benjamin Drung) Date: Tue, 11 Dec 2012 19:06:29 +0100 Subject: [Live-devel] shared library In-Reply-To: References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> Message-ID: <1355249189.15977.53.camel@deep-thought> Am Samstag, den 08.12.2012, 19:31 -0800 schrieb Ross Finlayson: > > > I'm not planning any changes to the 'build system' itself. I > > > would > > > hope, however, that things like shared libraries could be > > > accommodated > > > by using a different "config.*" file - e.g., perhaps named > > > something > > > like "config.linux-with-shared-libraries" or > > > "config.debian-with-shared-libraries" - and then using the exiting > > > "genMakefiles" tool. So that's the approach that I would pursue > > > first. > > > > Adding shared library support requires adding an additional make > > target > > that builds the additional .so files, because we want to keep the > > static > > library. This cannot be done by just adding some variables to > > config.linux-with-shared-libraries. > > > OK, fair enough. So here's what I'll do. If you send me a > "config.linux-with-shared-libraries" file that uses the existing build > system to build *just* shared libraries - even though that's not what > you want - then I'll add it to the distribution. But I'll also use it > to see if I can upgrade the build system (e.g., upgrade the > "genMakefiles" tool and/or the "Makefile.head"/"Makefile.tail" files) > to support a new "config.linux-with-static-and-shared-libraries" file > that will build both static and shared libraries. Okay. Attached is my first try. It builds the libraries fine, but fails then to build the testProgs. The name of the library needs to be available for the link option (see patch for the Makefile.tail files). The *_VERSION_* should be put to their corresponding libraries and maintained as discussed below. > > > (And as for the suggestion of switching to using 'CMake', see > > > ) > > > > Thanks for the pointer. Can you point me to the latest proposed > > revision > > of cmake config files? > > > I don't think any such things exist, because - as far as I know - > nobody is actually using CMake to build our code. Anyway, as I noted > in my July email message, CMake is a non-starter, unless/until it can > work with FreeBSD and also Windows with MS Visual Studio v5.0. I found a two year old cmake file [1]. Supporting FreeBSD with CMake should be no big issue. CMake can generate project files for Visual Studio 6 and later [2]. So there will probably no support for Visual Studio 5. [1] http://lists.live555.com/pipermail/live-devel/2010-June/012311.html [2] http://www.cmake.org/cmake/help/v2.8.10/cmake.html#section_Generators > > > (The only 'dynamic link' that I hope you put in Debian > > > distributions > > > is a 'link' to the URL "http://www.live555.com/liveMedia/", so > > > that > > > people can download the latest version of the code; the only > > > version > > > that we support :-) > > > > The homepage field of the liblivemedia package points to > > http://www.live555.com. Should I change it to point to the URL > > mentioned > > above? > > > Yes, please. Done in our git repository: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/liblivemedia.git;a=commitdiff;h=7d6cb366 > > > But of course, you're welcome to try building shared libraries if > > > you > > > wish. > > > > I cannot do it properly without your help. Are you willing to > > maintain > > one variable with the SONAME version. > > > OK, I could do this. What would this variable look like (i.e., > defined in a C/C++ source file)? Or do you mean that the variable > would be defined in the Makefiles (rather than as a symbol in the > library)? The SONAME version will be one variable (or three if you split it into current, revision, and age) for each library in the Makefiles. > > # 3. If the library source code has changed at all since the last > > update, then > > # increment revision (`c:r:a' becomes `c:r+1:a'). > > # 4. If any interfaces have been added, removed, or changed since > > the last update, > > # increment current, and set revision to 0. > > # 5. If any interfaces have been added since the last public > > release, then increment > > # age. > > # 6. If any interfaces have been removed since the last public > > release, then set age > > # to 0. > > > These 'rules' seem very confusing, because the conditions that they > describe can overlap. Example. If the current string is "c:r:a", and > a new interface is added (but with no other changes), then does the > new string become: > - "c:r+1:a" (rule 3), or > - "c+1:0:a" (rule 4), or > - "c:r:a+1" (rule 5), or > - "c+1:0:a+1" (rules 4 and 5) ??? They are meant to be processed step by step. > It seems to me that the rules would be less confusing if, instead, > they explained what happens in the following (non-overlapping!) > situations: > 1/ The code changes, but without any change to the API (i.e., > interfaces). Just increment the revision: c:r+1:a > 2/ At least one interface changes, or is removed (i.e., so that > existing code that uses the library would likely be incompatible with > the new version). Increment current, reset others: c+1:0:0 > 3/ One or more interfaces were added, but no existing interfaces were > changed or removed (i.e., so that existing code that uses the library > might still remain compatible with the new version). Increment current and age: c+1:0:a+1 This versioning schema is from libtool. I found a few more detailed explanation blogposts/articles/documentation: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html https://blog.flameeyes.eu/2009/04/shared-object-version http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://www.freesoftwaremagazine.com/articles/building_shared_libraries_once_using_autotools -- Benjamin Drung Debian & Ubuntu Developer -------------- next part -------------- libliveMedia_VERSION_CURRENT=0 libliveMedia_VERSION_REVISION=0 libliveMedia_VERSION_AGE=0 libBasicUsageEnvironment_VERSION_CURRENT=0 libBasicUsageEnvironment_VERSION_REVISION=0 libBasicUsageEnvironment_VERSION_AGE=0 libUsageEnvironment_VERSION_CURRENT=0 libUsageEnvironment_VERSION_REVISION=0 libUsageEnvironment_VERSION_AGE=0 libgroupsock_VERSION_CURRENT=0 libgroupsock_VERSION_REVISION=0 libgroupsock_VERSION_AGE=0 COMPILE_OPTS = $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC C = c C_COMPILER = cc C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = c++ CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -DBSD=1 OBJ = o LINK = c++ -o LINK_OPTS = -L. CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = gcc -o LIBRARY_LINK_OPTS = -shared -Wl,-soname,$(NAME).so.$(shell expr $($(NAME)_VERSION_CURRENT) - $($(NAME)_VERSION_AGE)) LIB_SUFFIX = so.$(shell expr $($(NAME)_VERSION_CURRENT) - $($(NAME)_VERSION_AGE)).$($(NAME)_VERSION_AGE).$($(NAME)_VERSION_REVISION) LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile-mods.patch Type: text/x-patch Size: 1471 bytes Desc: not available URL: From tbatra18 at gmail.com Wed Dec 12 02:16:20 2012 From: tbatra18 at gmail.com (Tarun Batra) Date: Wed, 12 Dec 2012 15:46:20 +0530 Subject: [Live-devel] Frame rate control or encoding possible in live media Message-ID: Hello Sir, I made an streaming application using live media library in which i am giving input to live media through camera and streaming the live video that is captured by camera. Now is there anyway to control the frame rate of streaming through live media library.? Can you five me some name of the open source encode so that give the input to encoder and then stream the video.? There is no way to control the frame rate through camera.... Please tell... Thanks Tarun -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.shivnani at gmail.com Wed Dec 12 12:18:07 2012 From: amit.shivnani at gmail.com (amit shivnani) Date: Wed, 12 Dec 2012 12:18:07 -0800 Subject: [Live-devel] Possibility of an RTSP server initiating the session In-Reply-To: References: Message-ID: Hello , First of all keep up the good work! The Live 555 project is a wonderful tool and a life saver for independent programmers . Here is my scenario . I am trying to use Live 555 media server from a device which sits behind the firewall , the client could be a browser based application which is sitting in a different network . I am able to get the communication going by starting the server and from the client using HTTP Tunnelling - "openRTSP -T rtsp://:/" . The problem is in real world there is no way the client will have the real IP address of the server which is sitting behind routers and firewall . However, in my case the server could still get the real IP address of the client . I wanted to explore the possibility of the server initiating the HTTP requests so that it could set initial level of GET and POST channels between the client and server to leverage the tunnelling feature(Internally RTSP request flow would be same) .As I said the Server know the IP address of the client in my case so technically the initial request can go from Server to client . I started exploring this option by modifying the code inside openRTSP and Live Media server but the tasks looks very cumbersome , considering the logic is very tightly coupled . Also wanted to explore if there is any other straightforward way of achieving this or if I am missing some package which can do something close to this, something like Server pushing data to the client that is what happens in cases of HTTP Push model . Please advise , Warm Regards Amit Shivnani -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.shivnani at gmail.com Thu Dec 13 22:08:22 2012 From: amit.shivnani at gmail.com (amit shivnani) Date: Thu, 13 Dec 2012 22:08:22 -0800 Subject: [Live-devel] Frame rate control or encoding possible in live media In-Reply-To: References: Message-ID: Have you tried ffmpeg , it is a good software encoder with supports for many codecs - http://ffmpeg.org/ffmpeg.html#Video-Encoders Thanks Amit On Wed, Dec 12, 2012 at 2:16 AM, Tarun Batra wrote: > Hello Sir, > > I made an streaming application using live media library in which i am > giving input to live media through camera and streaming the live video that > is captured by camera. > Now is there anyway to control the frame rate of streaming through live > media library.? > Can you five me some name of the open source encode so that give the input > to encoder and then stream the video.? > There is no way to control the frame rate through camera.... > Please tell... > > Thanks > Tarun > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 14 23:37:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 15 Dec 2012 17:37:00 +1000 Subject: [Live-devel] shared library In-Reply-To: <1355249189.15977.53.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> Message-ID: Benjamin, I've now installed a new release - 2012.12.15 - that adds a new configuration file "config.linux-with-shared-libraries". Please verify that this works properly for you (i.e., after first running "genMakefiles linux-with-shared-libraries"). (Unfortunately I'm traveling for the rest of the month, and don't have access to a Linux system for testing). If there are problems with this, then please let me know ASAP. (As I noted earlier, once I'm sure that this is working OK, I'll then work on supporting generating both static and shared libraries.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranshalit at gmail.com Fri Dec 14 10:12:23 2012 From: ranshalit at gmail.com (Ran Shalit) Date: Fri, 14 Dec 2012 20:12:23 +0200 Subject: [Live-devel] stream type Message-ID: Hello, I would like to ask what is the stream format (Byte Stream / Packet Stream), which live555 streamer expects to receive from encoder ? Is it right to assume that since live555 streamer is by default using RTP, than it will required that the encoded stream be packet stream type ? If we modify the live555 streamer to use MPEG-2 or MPEG-4 instead H264, what should be the implications in term of stream type ? Best Regards, Ran -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at timshackleton.com Sun Dec 16 11:58:48 2012 From: live555 at timshackleton.com (Tim J Shackleton) Date: Mon, 17 Dec 2012 08:58:48 +1300 Subject: [Live-devel] testOnDemandRTSPServer multicast question Message-ID: <50CE27F8.500@timshackleton.com> Hi Ross, I have been experimenting with a multicast to unicast RTSP relay, as demonstrated in testOnDemandRTSPServer. A behaviour I have noticed, is that the first client connects and receives the stream correctly, and all subsequent connections do too - they can SETUP, PLAY and TEARDOWN to their hearts content... However, if /*all*/ clients leave, the multicast source seems to become closed (though not reported as such in debug), and any clients that try to connect from this point onwards are accepted, but do not receive a video stream. Is this an expected behaviour? And if it is, can this behaviour be altered so that the source remains connected in absence of RTSP clients? Thanks and regards, -Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Dec 16 15:18:53 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2012 09:18:53 +1000 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <50CE27F8.500@timshackleton.com> References: <50CE27F8.500@timshackleton.com> Message-ID: <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> > I have been experimenting with a multicast to unicast RTSP relay, as demonstrated in testOnDemandRTSPServer. Since the "testOnDemandRTSPServer" demonstrates how to stream from *files* to (unicast) clients, it does not 'demonstrate' multicast to unicast RTSP relaying at all. Therefore, you must have modified the supplied application's code in some (unspecified) way. So I don't really see how I can help you. However (because you are apparently a professional developer, and not some @gmail.com nobody) I'll give it a try... > However, if all clients leave, the multicast source seems to become closed Once again, you haven't said how you have modified the supplied code, but it sounds like you added a new "OnDemandServerMediaSubsession" subclass that (1) correctly sets "reuseFirstSource" to True, and (2) redefines the "createNewStreamSource()" virtual function to create a new input source object (of some unspecified type...). If you do this, then, yes, the input source object will get closed (and its destructor called) whenever the last RTSP client leaves. This is the proper behavior, because we want the input source to be closed when noone is requesting its data. (Similarly, when another client arrives later, "createNewStreamSource()" will get called again, and a new input source object will get created.) So, you need to figure out how to get your (unspecified) input source object to behave the way you want when (1) an object of this type is constructed, and (2) an object of this type is destroyed. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at timshackleton.com Sun Dec 16 16:24:43 2012 From: live555 at timshackleton.com (Tim J Shackleton) Date: Mon, 17 Dec 2012 13:24:43 +1300 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> Message-ID: <50CE664B.6090406@timshackleton.com> On 17/12/12 12:18, Ross Finlayson wrote: > Since the "testOnDemandRTSPServer" demonstrates how to stream from > *files* to (unicast) clients, it does not 'demonstrate' multicast to > unicast RTSP relaying at all. Therefore, you must have modified the > supplied application's code in some (unspecified) way. So I don't > really see how I can help you. > I have copied testOnDemandRTSPServer.cpp to another file and modified it - the modification is simply the removal of all available streams with the exception of the following block: // A MPEG-2 Transport Stream, coming from a live UDP (raw-UDP or RTP/UDP) source: { char const* streamName = "mpeg2TransportStreamFromUDPSourceTest"; char const* inputAddressStr = "239.255.42.42"; // This causes the server to take its input from the stream sent by the "testMPEG2TransportStreamer" demo application. // (Note: If the input UDP source is unicast rather than multicast, then change this to NULL.) portNumBits const inputPortNum = 1234; // This causes the server to take its input from the stream sent by the "testMPEG2TransportStreamer" demo application. Boolean const inputStreamIsRawUDP = False; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(MPEG2TransportUDPServerMediaSubsession ::createNew(*env, inputAddressStr, inputPortNum, inputStreamIsRawUDP)); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); *env << "\n\"" << streamName << "\" stream, from a UDP Transport Stream input source \n\t("; if (inputAddressStr != NULL) { *env << "IP multicast address " << inputAddressStr << ","; } else { *env << "unicast;"; } *env << " port " << inputPortNum << ")\n"; *env << "Play this stream using the URL \"" << url << "\"\n"; delete[] url; } > > Once again, you haven't said how you have modified the supplied code, > but it sounds like you added a new "OnDemandServerMediaSubsession" > subclass that (1) correctly sets "reuseFirstSource" to True, and (2) > redefines the "createNewStreamSource()" virtual function to create a > new input source object (of some unspecified type...). > Correct, I have specified reuseFirstSource as true. As above, I have used the code block from the supplied test program, with the multicast group and port modified to suit local conditions. > If you do this, then, yes, the input source object will get closed > (and its destructor called) whenever the last RTSP client leaves. > This is the proper behavior, because we want the input source to be > closed when noone is requesting its data. (Similarly, when another > client arrives later, "createNewStreamSource()" will get called again, > and a new input source object will get created.) > Now, if that was the behaviour I am observing, then I would be quite happy with that! However, when another client arrives later, the multicast stream source does not appear to become active again. I can confirm however that createNewStreamSource from MPEG2TransportUDPServerMediaSubsession.cpp is being called as you say it should be when the client arrives. I am confident the source is still present on the network, as the source is directly connected to an ethernet port on the testing machine. I can see no reason why the library shouldn't be able to resubscribe to this source, either. Thanks and regards, -Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at timshackleton.com Sun Dec 16 16:41:30 2012 From: live555 at timshackleton.com (Tim J Shackleton) Date: Mon, 17 Dec 2012 13:41:30 +1300 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> Message-ID: <50CE6A3A.9050003@timshackleton.com> On 17/12/12 12:18, Ross Finlayson wrote: > If you do this, then, yes, the input source object will get closed > (and its destructor called) whenever the last RTSP client leaves. > This is the proper behavior, because we want the input source to be > closed when noone is requesting its data. (Similarly, when another > client arrives later, "createNewStreamSource()" will get called again, > and a new input source object will get created.) > Hi Ross, I have just noticed something - when the first client connects, there is an IGMP membership report issued to join the group I have specified for any sources. However, when that first (and only) client tears down the session, there is no IGMP membership report for the 'Leave'. That said, a 'Leave' is issued when the program is subsequently terminated. I suspect that the lack of an IGMP leave in the source destructor may be the cause of this unexpected behaviour. Would you suggest I write my own subclassed source and destructor, or do you think this behavour should be contained within the standard live555 source? Thanks and regards, -Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Dec 16 16:53:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2012 10:53:20 +1000 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <50CE6A3A.9050003@timshackleton.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> <50CE6A3A.9050003@timshackleton.com> Message-ID: <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> > I have just noticed something - when the first client connects, there is an IGMP membership report issued to join the group I have specified for any sources. > > However, when that first (and only) client tears down the session, there is no IGMP membership report for the 'Leave'. That's correct, because the "groupsock" object (the member variable "fInputGroupsock" in "MPEG2TransportUDPServerMediaSubsession") is not destroyed at this time. Instead, it stays around to be reused the next time that "createNewStreamSource" is called. That's why I'm confused as to the behavior that your're seeing. I'll have to investigate... > I suspect that the lack of an IGMP leave in the source destructor may be the cause of this unexpected behaviour. No, because if - as in this case - the "groupsock" object is not destroyed, then it should be OK to reuse it for new "BasicUDPSource" (or "SimpleRTPSource") objects. > Would you suggest I write my own subclassed source and destructor, or do you think this behavour should be contained within the standard live555 source? First, I'll try to look into exactly what's happening. If there's a bug in the supplied LIVE555 code, then I'll try to fix it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at timshackleton.com Mon Dec 17 12:28:45 2012 From: live555 at timshackleton.com (Tim J Shackleton) Date: Tue, 18 Dec 2012 09:28:45 +1300 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> <50CE6A3A.9050003@timshackleton.com> <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> Message-ID: <50CF807D.7040708@timshackleton.com> On 17/12/12 13:53, Ross Finlayson wrote: > First, I'll try to look into exactly what's happening. If there's a > bug in the supplied LIVE555 code, then I'll try to fix it. > Thanks Ross, I appreciate this greatly. I have done a little further investigation myself and thought I'd share it with you in case it helps. I voided my warranty, so to speak, by adding a printf("."); to BasicUDPSource::incomingPacketHandler1() in order to see when the source is processing packets. As expected, no packets are processed until the first client connects to the RTSP server, at which time packets are processed at an expected rate. When that client leaves, packets are no longer processed. When the next client connects, packets seem to be processed, but remarkably slower than when the first client was connected. Here's the debug output to illustrate this: > "test" stream, from a UDP Transport Stream input source > (IP multicast address 239.200.1.102, port 5500) > Play this stream using the URL "rtsp://10.2.1.182:8554/test" > accept()ed connection from 10.201.17.53 > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 121 new > bytes:OPTIONS rtsp://10.2.1.182:8554/test RTSP/1.0 > CSeq: 2 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > > > parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", > urlPreSuffix "", urlSuffix "test", CSeq "2", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 2 > Date: Mon, Dec 17 2012 20:11:07 GMT > Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, > GET_PARAMETER, SET_PARAMETER > > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 147 new > bytes:DESCRIBE rtsp://10.2.1.182:8554/test RTSP/1.0 > CSeq: 3 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Accept: application/sdp > > > parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", > urlPreSuffix "", urlSuffix "test", CSeq "3", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 3 > Date: Mon, Dec 17 2012 20:11:07 GMT > Content-Base: rtsp://10.2.1.182:8554/test/ > Content-Type: application/sdp > Content-Length: 320 > > v=0 > o=- 1355775062508879 1 IN IP4 10.2.1.182 > s=Session streamed by VPS-UAT > i=test > t=0 0 > a=tool:LIVE555 Streaming Media v2012.11.30 > a=type:broadcast > a=control:* > a=range:npt=0- > a=x-qt-text-nam:Session streamed by VPS-UAT > a=x-qt-text-inf:test > m=video 0 RTP/AVP 33 > c=IN IP4 0.0.0.0 > b=AS:5000 > a=control:track1 > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 176 new > bytes:SETUP rtsp://10.2.1.182:8554/test/track1 RTSP/1.0 > CSeq: 4 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Transport: RTP/AVP;unicast;client_port=1612-1613 > > > parseRTSPRequestString() succeeded, returning cmdName "SETUP", > urlPreSuffix "test", urlSuffix "track1", CSeq "4", Content-Length 0, > with 0 bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 4 > Date: Mon, Dec 17 2012 20:11:07 GMT > Transport: > RTP/AVP;unicast;destination=10.201.17.53;source=10.2.1.182;client_port=1612-1613;server_port=6970-6971 > Session: 2283FFFD > > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 157 new > bytes:PLAY rtsp://10.2.1.182:8554/test/ RTSP/1.0 > CSeq: 5 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Session: 2283FFFD > Range: npt=0.000- > > > parseRTSPRequestString() succeeded, returning cmdName "PLAY", > urlPreSuffix "test", urlSuffix "", CSeq "5", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 5 > Date: Mon, Dec 17 2012 20:11:07 GMT > Range: npt=0.000- > Session: 2283FFFD > RTP-Info: > url=rtsp://10.2.1.182:8554/test/track1;seq=12753;rtptime=3031997768 > > ...RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 147 new > bytes:GET_PARAMETER rtsp://10.2.1.182:8554/test/ RTSP/1.0 > CSeq: 6 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Session: 2283FFFD > > > parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", > urlPreSuffix "test", urlSuffix "", CSeq "6", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 6 > Date: Mon, Dec 17 2012 20:11:07 GMT > Session: 2283FFFD > > ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................RTSP > client session (id "2283FFFD", stream name "test"): Liveness indication > ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................RTSP > client session (id "2283FFFD", stream name "test"): Liveness indication > .................................................................................................................................................................................................................................................................................................................................................................................................................................................RTSP > client session (id "2283FFFD", stream name "test"): Liveness indication > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 142 new > bytes:TEARDOWN rtsp://10.2.1.182:8554/test/ RTSP/1.0 > CSeq: 7 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Session: 2283FFFD > > > parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", > urlPreSuffix "test", urlSuffix "", CSeq "7", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 7 > Date: Mon, Dec 17 2012 20:11:15 GMT > > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read -1 new > bytes (of 10000); terminating connection! Now, I reconnect that client: > accept()ed connection from 10.201.17.53 > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 121 new > bytes:OPTIONS rtsp://10.2.1.182:8554/test RTSP/1.0 > CSeq: 2 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > > > parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", > urlPreSuffix "", urlSuffix "test", CSeq "2", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 2 > Date: Mon, Dec 17 2012 20:12:40 GMT > Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, > GET_PARAMETER, SET_PARAMETER > > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 147 new > bytes:DESCRIBE rtsp://10.2.1.182:8554/test RTSP/1.0 > CSeq: 3 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Accept: application/sdp > > > parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", > urlPreSuffix "", urlSuffix "test", CSeq "3", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 3 > Date: Mon, Dec 17 2012 20:12:40 GMT > Content-Base: rtsp://10.2.1.182:8554/test/ > Content-Type: application/sdp > Content-Length: 320 > > v=0 > o=- 1355775062508879 1 IN IP4 10.2.1.182 > s=Session streamed by VPS-UAT > i=test > t=0 0 > a=tool:LIVE555 Streaming Media v2012.11.30 > a=type:broadcast > a=control:* > a=range:npt=0- > a=x-qt-text-nam:Session streamed by VPS-UAT > a=x-qt-text-inf:test > m=video 0 RTP/AVP 33 > c=IN IP4 0.0.0.0 > b=AS:5000 > a=control:track1 > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 176 new > bytes:SETUP rtsp://10.2.1.182:8554/test/track1 RTSP/1.0 > CSeq: 4 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Transport: RTP/AVP;unicast;client_port=1666-1667 > > > parseRTSPRequestString() succeeded, returning cmdName "SETUP", > urlPreSuffix "test", urlSuffix "track1", CSeq "4", Content-Length 0, > with 0 bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 4 > Date: Mon, Dec 17 2012 20:12:40 GMT > Transport: > RTP/AVP;unicast;destination=10.201.17.53;source=10.2.1.182;client_port=1666-1667;server_port=6970-6971 > Session: 69932E25 > > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 157 new > bytes:PLAY rtsp://10.2.1.182:8554/test/ RTSP/1.0 > CSeq: 5 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Session: 69932E25 > Range: npt=0.000- > > > parseRTSPRequestString() succeeded, returning cmdName "PLAY", > urlPreSuffix "test", urlSuffix "", CSeq "5", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 5 > Date: Mon, Dec 17 2012 20:12:40 GMT > Range: npt=0.000- > Session: 69932E25 > RTP-Info: > url=rtsp://10.2.1.182:8554/test/track1;seq=39224;rtptime=2724475800 > > ..............RTSPClientConnection[0x1ecbed0]::handleRequestBytes() > read 147 new bytes:GET_PARAMETER rtsp://10.2.1.182:8554/test/ RTSP/1.0 > CSeq: 6 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Session: 69932E25 > > > parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", > urlPreSuffix "test", urlSuffix "", CSeq "6", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 6 > Date: Mon, Dec 17 2012 20:12:40 GMT > Session: 69932E25 > > ..........................................................RTSP client > session (id "69932E25", stream name "test"): Liveness indication > .RTSP client session (id "69932E25", stream name "test"): Liveness > indication > .RTSP client session (id "69932E25", stream name "test"): Liveness > indication > ..RTSP client session (id "69932E25", stream name "test"): Liveness > indication > .RTSP client session (id "69932E25", stream name "test"): Liveness > indication > .RTSP client session (id "69932E25", stream name "test"): Liveness > indication > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 142 new > bytes:TEARDOWN rtsp://10.2.1.182:8554/test/ RTSP/1.0 > CSeq: 7 > User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) > Session: 69932E25 > > > parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", > urlPreSuffix "test", urlSuffix "", CSeq "7", Content-Length 0, with 0 > bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 7 > Date: Mon, Dec 17 2012 20:13:11 GMT > > RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read -1 new > bytes (of 10000); terminating connection! As you can see, the frequency that incomingPacketHandler1() is called is much, much less. What I just noticed in addition to this, is that the frequency of it's calling is proportional to the time between clients. That is, if the client is reconnected quickly, more packets are processed. However, the longer you wait between clients, the slower they are processed. To illuminate this further, in the example directly above, between clients I was formatting this email, probably 60+ seconds between clients. This next segment I will paste, there will be only a few seconds between clients: > Session: CC070355 > > .................................................................RTSP > client session (id "CC070355", stream name "test"): Liveness indication > ....................................................................................................RTSP > client session (id "CC070355", stream name "test"): Liveness indication > ....................................................................................RTSP > client session (id "CC070355", stream name "test"): Liveness indication > ...........................................................................RTSPClientConnection[0xe23f20]::handleRequestBytes() > read 142 new bytes:TEARDOWN rtsp://10.2.1.182:8554/test/ RTSP/1.0 As you can see - much more data is received, but significantly less than required! So, it would seem to me that there's perhaps a timing delta being used somewhere that becomes wildly incorrect between client connections (supposing the client count becomes 0). Hope this helps some! Thanks and regards, -Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 17 14:20:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Dec 2012 08:20:33 +1000 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> <50CE6A3A.9050003@timshackleton.com> <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> Message-ID: <8503C0B4-6FB7-4B98-97A7-8878738B03F4@live555.com> Unfortunately I wasn't able to reproduce your problem at all. I ran "testMPEG2TransportStreamer" to continuously stream a Transport Stream file via multicast, and also ran "testOnDemandRTSPServer" to receive this multicast stream, and use it as input for a unicast RTSP server. I then kept running openRTSP -d 5 -n to repeatedly open and receive the stream for 5 seconds, then close it. Each time, "openRTSP" received data. So unfortunately you're going to have to track down yourself what is going wrong. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis at defiboat-technology.com Mon Dec 17 06:57:57 2012 From: alexis at defiboat-technology.com (aveline) Date: Mon, 17 Dec 2012 15:57:57 +0100 Subject: [Live-devel] multi rtsp stream Message-ID: <004601cddc66$e7966320$b6c32960$@defiboat-technology.com> Hi I have an easy question to you I think : I have 3 IP camera (rtsp camera); I want to developp a software which the goal is to see the 3 IP cameras and select one to stream it over Ustream / liveStream / justin / Do you know if it is possible ?? ------------------------------------------------------------------------ Alexis Aveline - Defiboat Technology - Conception de moyens de production audiovisuelle embarqu?e mob : 06 29 93 38 56 standard : 02 97 55 08 54 NEW direct : 02 97 55 46 48 alexis at defiboat-technology.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 17 16:18:04 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Dec 2012 10:18:04 +1000 Subject: [Live-devel] multi rtsp stream In-Reply-To: <004601cddc66$e7966320$b6c32960$@defiboat-technology.com> References: <004601cddc66$e7966320$b6c32960$@defiboat-technology.com> Message-ID: > I have 3 IP camera (rtsp camera); I want to developp a software which the goal is to see the 3 IP cameras and select one to stream it over Ustream / liveStream / justin / ? > > Do you know if it is possible ?? It depends on whether or not those systems can access RTSP/RTP streams. You would need to ask them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at timshackleton.com Mon Dec 17 16:47:19 2012 From: live555 at timshackleton.com (Tim J Shackleton) Date: Tue, 18 Dec 2012 13:47:19 +1300 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <8503C0B4-6FB7-4B98-97A7-8878738B03F4@live555.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> <50CE6A3A.9050003@timshackleton.com> <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> <8503C0B4-6FB7-4B98-97A7-8878738B03F4@live555.com> Message-ID: <50CFBD17.9090506@timshackleton.com> On 18/12/12 11:20, Ross Finlayson wrote: > Unfortunately I wasn't able to reproduce your problem at all. I ran > "testMPEG2TransportStreamer" to continuously stream a Transport Stream > file via multicast, and also ran "testOnDemandRTSPServer" to receive > this multicast stream, and use it as input for a unicast RTSP server. > I then kept running > openRTSP -d 5 -n > to repeatedly open and receive the stream for 5 seconds, then close > it. Each time, "openRTSP" received data. > > So unfortunately you're going to have to track down yourself what is > going wrong. Hi Ross, Yes, I shall look into it more deeply. In case it makes any difference, I'll describe the setup here for you. Linux 64 bit, multicast source is RAW, not RTP, from an external machine (In this case a Cisco Digital Content Manager), SPTS at 3.7MBit/sec. The only mechanical modifications to the testOnDemandRTSPServer that have been made are reuseFirstSource=True, inputStreamIsRawUDP=True, and the inputAddressStr and inputPortNum values. When I run the testOnDemandRTSPServer, I, like you, am able to connect to it with openRTSP and it says it receives data. /That is not in dispute/. I thought at first data was completely lacking but as I described in my previous email, that is not actually the case. However, if I subsequently try and play from the RTSP server with VLC, it connects but cannot play because /insufficient data/ appears to be sent. Are you able to play the transport stream via RTSP successfully with VLC after a few launches of openRTSP? I have a hunch at this point that the TransportStreamFramer is not being reinitialized when a new client arrives (after all clients have left) and the packet playout rate is no longer correct - but like I said, it's only a hunch. In order to make sure I'm on absolutely the right page, I rebuilt the latest source. I have trimmed testOnDemandRTSPServer from your example (to cut out all other example instances other than the multicast source) and made only the modifications I mentioned above. The same results are exhibited. The source of the test program is as follows: #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" UsageEnvironment* env; Boolean reuseFirstSource = True; Boolean iFramesOnly = False; static void announceStream(RTSPServer* rtspServer, ServerMediaSession* sms, char const* streamName, char const* inputFileName); // fwd int main(int argc, char** argv) { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); env = BasicUsageEnvironment::createNew(*scheduler); UserAuthenticationDatabase* authDB = NULL; RTSPServer* rtspServer = RTSPServer::createNew(*env, 8554, authDB); if (rtspServer == NULL) { *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n"; exit(1); } char const* descriptionString = "Session streamed by \"testOnDemandRTSPServer\""; // A MPEG-2 Transport Stream, coming from a live UDP (raw-UDP or RTP/UDP) source: { char const* streamName = "mpeg2TransportStreamFromUDPSourceTest"; char const* inputAddressStr = "239.200.1.102"; portNumBits const inputPortNum = 5500; Boolean const inputStreamIsRawUDP = True; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(MPEG2TransportUDPServerMediaSubsession ::createNew(*env, inputAddressStr, inputPortNum, inputStreamIsRawUDP)); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); *env << "\n\"" << streamName << "\" stream, from a UDP Transport Stream input source \n\t("; if (inputAddressStr != NULL) { *env << "IP multicast address " << inputAddressStr << ","; } else { *env << "unicast;"; } *env << " port " << inputPortNum << ")\n"; *env << "Play this stream using the URL \"" << url << "\"\n"; delete[] url; } env->taskScheduler().doEventLoop(); // does not return return 0; // only to prevent compiler warning } -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 17 16:52:52 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Dec 2012 10:52:52 +1000 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <50CFBD17.9090506@timshackleton.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> <50CE6A3A.9050003@timshackleton.com> <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> <8503C0B4-6FB7-4B98-97A7-8878738B03F4@live555.com> <50CFBD17.9090506@timshackleton.com> Message-ID: <536C2DE1-0745-4B25-A801-EA090FC42824@live555.com> > I have a hunch at this point that the TransportStreamFramer is not being reinitialized when a new client arrives No. As you can see from the "MPEG2TransportUDPServerMediaSubsession" implementation, a new "MPEG2TransportStreamFramer" is created (and used as the data source) each time "createNewStreamSource()" is called - i.e., each time we start reading from the input stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at timshackleton.com Mon Dec 17 17:32:21 2012 From: live555 at timshackleton.com (Tim J Shackleton) Date: Tue, 18 Dec 2012 14:32:21 +1300 Subject: [Live-devel] testOnDemandRTSPServer multicast question In-Reply-To: <536C2DE1-0745-4B25-A801-EA090FC42824@live555.com> References: <50CE27F8.500@timshackleton.com> <9CC85C20-5082-4DCF-8FAA-F8C801904218@live555.com> <50CE6A3A.9050003@timshackleton.com> <5694694F-CA84-4856-9A5F-EA81302D1E5D@live555.com> <8503C0B4-6FB7-4B98-97A7-8878738B03F4@live555.com> <50CFBD17.9090506@timshackleton.com> <536C2DE1-0745-4B25-A801-EA090FC42824@live555.com> Message-ID: <50CFC7A5.3000908@timshackleton.com> On 18/12/12 13:52, Ross Finlayson wrote: > No. As you can see from the "MPEG2TransportUDPServerMediaSubsession" > implementation, a new "MPEG2TransportStreamFramer" is created (and > used as the data source) each time "createNewStreamSource()" is called > - i.e., each time we start reading from the input stream. > Quite right - I flipped on DEBUG_PCR and clearly a FIRST PCR is present on every fresh client connect (from zero clients). That would clear up that hunch fairly comprehensively. The only thing left then, I suppose, is the socket receiving the data. From the PCR debug it's obvious though, that something is going very wrong, and I cannot see how it can be my multicast source, or the live555 example program supplied. It appears to be a sudden lack of data on ingress, but I can prove that the data is still there, on the wire. It's a professional source. And the group is not 'left' by the socket, as previously discussed. Quite baffled. I'll continue investigating. I won't rule out kernel level issues either at this stage! Thanks, -Tim parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "test", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 5 Date: Tue, Dec 18 2012 01:20:49 GMT Range: npt=0.000- Session: 50345F36 RTP-Info: url=rtsp://10.2.1.182:8554/test/track1;seq=59716;rtptime=226380619 *PID 0x21, FIRST PCR 0x004e81a6+1:121 == 114.333311 @ 1355793649.575549, pkt #7* PID 0x21, PCR 0x004e8583+0:046 == 114.355269 @ 1355793649.575600 (*diffs 0.021959* @ 0.000051), pkt #61, discon 0 => this duration 0.000407, new estimate 0.000407, mean PCR period=30.500000 RTSPClientConnection[0x107ff70]::handleRequestBytes() read 147 new bytes:GET_PARAMETER rtsp://10.2.1.182:8554/test/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) Session: 50345F36 parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "test", urlSuffix "", CSeq "6", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 6 Date: Tue, Dec 18 2012 01:20:49 GMT Session: 50345F36 PID 0x21, PCR 0x00511ba9+1:073 == 118.122171 @ 1355793649.629560 (*diffs 3.788860* @ 0.054011), pkt #190, discon 0 => this duration 0.029201, new estimate 0.018505, mean PCR period=63.333333 PID 0x21, PCR 0x0051f33c+0:0a3 == 119.348539 @ 1355793650.536256 (*diffs 5.015229* @ 0.960707), pkt #243, discon 0 => this duration 0.023139, new estimate 0.026027, mean PCR period=60.750000 RTSP client session (id "50345F36", stream name "test"): Liveness indication PID 0x21, PCR 0x00532b7b+1:0de == 121.124886 @ 1355793653.086902 (*diffs 6.791575* @ 3.511353), pkt #340, discon 0 => this duration 0.018313, new estimate 0.027713, mean PCR period=68.000000 PID 0x21, PCR 0x0053832a+0:028 == 121.623690 @ 1355793654.444790 (*diffs 7.290380* @ 4.869241), pkt #391, discon 0 => this duration 0.009780, new estimate 0.023433, mean PCR period=65.166667 PID 0x21, PCR 0x0053c5d3+1:068 == 122.002926 @ 1355793656.085100 (*diffs 7.669615* @ 6.509551), pkt #458, discon 0 => this duration 0.005660, new estimate 0.018183, mean PCR period=57.250000 PID 0x21, PCR 0x006e777b+1:051 == 160.878836 @ 1355793656.848786 (*diffs 46.545526* @ 7.273237), pkt #498, discon 0 => this duration 0.971898, new estimate 0.618801, mean PCR period=55.333333 RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSPClientConnection[0x107ff70]::handleRequestBytes() read 142 new bytes:TEARDOWN rtsp://10.2.1.182:8554/test/ RTSP/1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lxhjjz at gmail.com Mon Dec 17 17:30:32 2012 From: lxhjjz at gmail.com (jianzhao jin) Date: Tue, 18 Dec 2012 09:30:32 +0800 Subject: [Live-devel] Fwd: problem with live555ProxyServer while proxying MJPEG stream In-Reply-To: References: Message-ID: Hi I have a MJPEG stream,the VLC can play it correctly.When I used live555ProxyServer to proxy it ,the testRTSPClient runs normally,but the VLC stoped playing soon after started,VLC logs and proxyServer debug logs are listed below: VLC logs: main debug: processing request item rtsp://192.168.0.50:8554/proxyStreamnode ???? skip 0 main debug: resyncing on rtsp://192.168.0.50:8554/proxyStream main debug: rtsp://192.168.0.50:8554/proxyStream is at 2 main debug: starting new item main debug: creating new input thread main debug: Creating an input for 'rtsp://192.168.0.50:8554/proxyStream' main debug: thread (input) created at priority 10 (input/input.c:220) main debug: TIMER input launching for 'rtsp://192.168.0.50:8554/proxyStream' : 300.465 ms - Total 300.465 ms / 1 intvls (Avg 300.465 ms) main debug: thread started main debug: using timeshift granularity of 50 MiB main debug: using timeshift path '/tmp' main debug: `rtsp://192.168.0.50:8554/proxyStream' gives access `rtsp' demux `' path `192.168.0.50:8554/proxyStream' main debug: creating demux: access='rtsp' demux='' path=' 192.168.0.50:8554/proxyStream' main debug: looking for access_demux module: 1 candidate live555 debug: RTP subsession 'video/JPEG' main debug: selecting program id=0 live555 debug: setup start: 0.000000 stop:0.000000 live555 debug: We have a timeout of 60 seconds live555 debug: spawned timeout thread live555 debug: play start: 0.000000 stop:0.000000 main debug: using access_demux module "live555" main debug: TIMER module_need() : 2.418 ms - Total 2.418 ms / 1 intvls (Avg 2.418 ms) main debug: looking for decoder module: 30 candidates avcodec debug: libavcodec already initialized avcodec debug: trying to use direct rendering avcodec debug: ffmpeg codec (Motion JPEG Video) started main debug: using decoder module "avcodec" main debug: TIMER module_need() : 1.164 ms - Total 1.164 ms / 1 intvls (Avg 1.164 ms) main debug: thread (decoder) created at priority 0 (input/decoder.c:301) main debug: thread started main debug: looking for meta reader module: 2 candidates lua debug: Trying Lua scripts in /home/zj/.local/share/vlc/lua/meta/reader lua debug: Trying Lua scripts in /usr/lib/vlc/lua/meta/reader lua debug: Trying Lua playlist script /usr/lib/vlc/lua/meta/reader/filename.luac qt4 debug: IM: Setting an input lua debug: Trying Lua scripts in /usr/share/vlc/lua/meta/reader main debug: no meta reader module matching "any" could be loaded main debug: TIMER module_need() : 2.127 ms - Total 2.127 ms / 1 intvls (Avg 2.127 ms) main debug: `rtsp://192.168.0.50:8554/proxyStream' successfully opened live555 warning: no data received in 10s. Switching to TCP avcodec debug: ffmpeg codec (Motion JPEG Video) stopped main debug: removing module "avcodec" main debug: killing decoder fourcc `MJPG', 0 PES in FIFO main debug: Program doesn't contain anymore ES live555 debug: RTP subsession 'video/JPEG' main debug: looking for decoder module: 30 candidates avcodec debug: libavcodec already initialized avcodec debug: trying to use direct rendering avcodec debug: ffmpeg codec (Motion JPEG Video) started main debug: using decoder module "avcodec" main debug: TIMER module_need() : 1.016 ms - Total 1.016 ms / 1 intvls (Avg 1.016 ms) main debug: thread (decoder) created at priority 0 (input/decoder.c:301) main debug: thread started live555 debug: setup start: 0.000000 stop:0.000000 live555 debug: play start: 0.000000 stop:0.000000 live555 error: no data received in 10s, aborting main debug: EOF reached avcodec debug: ffmpeg codec (Motion JPEG Video) stopped main debug: removing module "avcodec" main debug: killing decoder fourcc `MJPG', 0 PES in FIFO main debug: removing module "live555" main debug: Program doesn't contain anymore ES main debug: thread ended main debug: dead input main debug: changing item without a request (current 2/3) main debug: nothing to play qt4 debug: IM: Deleting the input ProxyServer logs: LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.11.16) Opening connection to 192.168.0.250, port 8555... RTSP stream, proxying the stream "rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG" Play this stream using the URL: rtsp://192.168.0.50:8554/proxyStream (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.11.16) Accept: application/sdp Received 561 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Jan 01 2000 03:01:38 GMT Content-Base: rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/ Content-Type: application/sdp Content-Length: 355 v=0 o=- 946684809993274 1 IN IP4 192.168.0.169 s=RTSP/RTP stream from IPNC i=0?videoCodecType=MJPEG t=0 0 a=tool:LIVE555 Streaming Media v2011.05.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from IPNC a=x-qt-text-inf:0?videoCodecType=MJPEG m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 b=AS:12000 a=control:track1 ProxyServerMediaSession["rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/"] added new "ProxyServerMediaSubsession" for RTP/video/JPEG track accept()ed connection from 192.168.0.50 RTSPClientConnection[0x9571b80]::handleRequestBytes() read 133 new bytes:OPTIONS rtsp://192.168.0.50:8554/proxyStream RTSP/1.0 CSeq: 244 User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "proxyStream", CSeq "244", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 244 Date: Mon, Dec 17 2012 08:32:05 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[0x9571b80]::handleRequestBytes() read 159 new bytes:DESCRIBE rtsp://192.168.0.50:8554/proxyStream RTSP/1.0 CSeq: 245 Accept: application/sdp User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "245", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 0) RTCPInstance[0x95773b8]::RTCPInstance() schedule(1.911126->1355733127.436233) Initiated: ProxyServerMediaSubsession["JPEG"] ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() ProxyServerMediaSubsession["JPEG"]::closeStreamSource() sending response: RTSP/1.0 200 OK CSeq: 245 Date: Mon, Dec 17 2012 08:32:05 GMT Content-Base: rtsp://192.168.0.50:8554/proxyStream/ Content-Type: application/sdp Content-Length: 425 v=0 o=- 1355733117432388 1 IN IP4 192.168.0.50 s=LIVE555 Streaming Media v2012.11.16 i=LIVE555 Streaming Media v2012.11.16 t=0 0 a=tool:LIVE555 Streaming Media v2012.11.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.11.16 a=x-qt-text-inf:LIVE555 Streaming Media v2012.11.16 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:12000 a=rtpmap:96 JPEG/90000 a=control:track1 RTSPClientConnection[0x9571b80]::handleRequestBytes() read 190 new bytes:SETUP rtsp://192.168.0.50:8554/proxyStream/track1 RTSP/1.0 CSeq: 246 Transport: RTP/AVP;unicast;client_port=36610-36611 User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "246", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 2948657255) Sending request: SETUP rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/track1RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.11.16) Transport: RTP/AVP;unicast;client_port=47600-47601 ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() sending response: RTSP/1.0 200 OK CSeq: 246 Date: Mon, Dec 17 2012 08:32:05 GMT Transport: RTP/AVP;unicast;destination=192.168.0.50;source=192.168.0.50;client_port=36610-36611;server_port=6970-6971 Session: AFC0F067 RTSPClientConnection[0x9571b80]::handleRequestBytes() read 169 new bytes:PLAY rtsp://192.168.0.50:8554/proxyStream/ RTSP/1.0 CSeq: 247 Session: AFC0F067 Range: npt=0.000- User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "247", Content-Length 0, with 0 bytes following the message. RTCPInstance[0x9578638]::RTCPInstance() schedule(1.880975->1355733127.408043) sending response: RTSP/1.0 200 OK CSeq: 247 Date: Mon, Dec 17 2012 08:32:05 GMT Range: npt=0.000- Session: AFC0F067 RTP-Info: url=rtsp:// 192.168.0.50:8554/proxyStream/track1;seq=21020;rtptime=1008160270 Received 204 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Sat, Jan 01 2000 03:01:46 GMT Transport: RTP/AVP;unicast;destination=192.168.0.50;source=192.168.0.250;client_port=47600-47601;server_port=6970-6971 Session: 728AAA5A ProxyRTSPClient["rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/"]::continueAfterSETUP(): head codec: JPEG; numSubsessions 1 queue: JPEG Sending request: PLAY rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/ RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.11.16) Session: 728AAA5A RTSPClientConnection[0x9571b80]::handleRequestBytes() read 159 new bytes:GET_PARAMETER rtsp://192.168.0.50:8554/proxyStream/ RTSP/1.0 CSeq: 248 Session: AFC0F067 User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "proxyStream", urlSuffix "", CSeq "248", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 248 Date: Mon, Dec 17 2012 08:32:05 GMT Session: AFC0F067 Received 207 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Sat, Jan 01 2000 03:01:46 GMT Session: 728AAA5A RTP-Info: url=rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/track1;seq=56377;rtptime=662084511 schedule(0.888945->1355733128.297077) sending REPORT sending RTCP packet 81c90007 9a9f5e3c dc48f48d 00ffffff 0001dd93 00000329 00000000 00000000 81ca0005 9a9f5e3c 010a7a6a 2d646573 6b746f70 00000000 schedule(2.496051->1355733129.932904) [0x9578638]saw incoming RTCP packet (from address 192.168.0.50, port 36611) 81c90007 193f8ee8 22dd946a 00000000 00005428 000002b6 00000000 00000000 81ca0005 193f8ee8 010a7a6a 2d646573 6b746f70 00000000 RR RTSP client session (id "AFC0F067", stream name "proxyStream"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x193f8ee8 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x193f8ee8 validated entire RTCP packet [0x95773b8]saw incoming RTCP packet (from address 192.168.0.250, port 6971) 80c80006 dc48f48d bc17ec9d 9033721d 277a32b5 000001d7 0009cb74 81ca0005 dc48f48d 010d3139 322e3136 382e302e 31363900 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xdc48f48d UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xdc48f48d validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 22dd946a d4795708 4c199fe4 3c1b19e2 00000245 000b5c34 81ca0005 22dd946a 010a7a6a 2d646573 6b746f70 00000000 schedule(2.537685->1355733130.835402) schedule(1.717591->1355733131.650602) [0x95773b8]saw incoming RTCP packet (from address 192.168.0.250, port 6971) 80c80006 dc48f48d bc17ec9f e2173b86 277d624a 00000385 0012b748 81ca0005 dc48f48d 010d3139 322e3136 382e302e 31363900 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xdc48f48d UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xdc48f48d validated entire RTCP packet schedule(3.509940->1355733134.345440) [0x9578638]saw incoming RTCP packet (from address 192.168.0.50, port 36611) 81c90007 193f8ee8 22dd946a 00000000 000056ba 00000327 57084c19 0002e386 81ca0005 193f8ee8 010a7a6a 2d646573 6b746f70 00000000 RR RTSP client session (id "AFC0F067", stream name "proxyStream"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x193f8ee8 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x193f8ee8 validated entire RTCP packet schedule(1.384960->1355733133.035702) sending REPORT sending RTCP packet 81c90007 9a9f5e3c dc48f48d 00ffffff 0001e19c 000002bb ec9fe217 00029c92 81ca0005 9a9f5e3c 010a7a6a 2d646573 6b746f70 00000000 schedule(3.735707->1355733136.772070) sending REPORT sending RTCP packet 80c80006 22dd946a d479570e 587fed20 3c236849 00000738 00242b15 81ca0005 22dd946a 010a7a6a 2d646573 6b746f70 00000000 schedule(4.140238->1355733138.486416) [0x9578638]saw incoming RTCP packet (from address 192.168.0.50, port 36611) 81c90007 193f8ee8 22dd946a 00000000 000059a0 000002ea 570e587f 00005ca7 81ca0005 193f8ee8 010a7a6a 2d646573 6b746f70 00000000 RR RTSP client session (id "AFC0F067", stream name "proxyStream"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x193f8ee8 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x193f8ee8 validated entire RTCP packet RTSPClientConnection[0x9571b80]::handleRequestBytes() read 154 new bytes:TEARDOWN rtsp://192.168.0.50:8554/proxyStream/ RTSP/1.0 CSeq: 249 Session: AFC0F067 User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "proxyStream", urlSuffix "", CSeq "249", Content-Length 0, with 0 bytes following the message. RTCPInstance[0x9578638]::~RTCPInstance() sending BYE sending RTCP packet 80c80006 22dd946a d4795710 08eb356e 3c25ba20 0000089d 002b266f 81cb0001 22dd946a ProxyServerMediaSubsession["JPEG"]::closeStreamSource() Sending request: PAUSE rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.11.16) Session: 728AAA5A sending response: RTSP/1.0 200 OK CSeq: 249 Date: Mon, Dec 17 2012 08:32:16 GMT accept()ed connection from 192.168.0.50 RTSPClientConnection[0x9578620]::handleRequestBytes() read 133 new bytes:OPTIONS rtsp://192.168.0.50:8554/proxyStream RTSP/1.0 CSeq: 250 User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "proxyStream", CSeq "250", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 250 Date: Mon, Dec 17 2012 08:32:16 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[0x9571b80]::handleRequestBytes() read -1 new bytes (of 10000); terminating connection! RTSPClientConnection[0x9578620]::handleRequestBytes() read 159 new bytes:DESCRIBE rtsp://192.168.0.50:8554/proxyStream RTSP/1.0 CSeq: 251 Accept: application/sdp User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "251", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 251 Date: Mon, Dec 17 2012 08:32:16 GMT Content-Base: rtsp://192.168.0.50:8554/proxyStream/ Content-Type: application/sdp Content-Length: 425 v=0 o=- 1355733117432388 1 IN IP4 192.168.0.50 s=LIVE555 Streaming Media v2012.11.16 i=LIVE555 Streaming Media v2012.11.16 t=0 0 a=tool:LIVE555 Streaming Media v2012.11.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.11.16 a=x-qt-text-inf:LIVE555 Streaming Media v2012.11.16 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:12000 a=rtpmap:96 JPEG/90000 a=control:track1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 186 new bytes:SETUP rtsp://192.168.0.50:8554/proxyStream/track1 RTSP/1.0 CSeq: 252 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "252", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 2701466371) Sending request: PLAY rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.11.16) Session: 728AAA5A ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() sending response: RTSP/1.0 200 OK CSeq: 252 Date: Mon, Dec 17 2012 08:32:16 GMT Transport: RTP/AVP/TCP;unicast;destination=192.168.0.50;source=192.168.0.50;interleaved=0-1 Session: A1051B03 Received 84 new bytes of response data. Received a complete PAUSE response: RTSP/1.0 200 OK CSeq: 5 Date: Sat, Jan 01 2000 03:01:57 GMT Session: 728AAA5A RTSPClientConnection[0x9578620]::handleRequestBytes() read 169 new bytes:PLAY rtsp://192.168.0.50:8554/proxyStream/ RTSP/1.0 CSeq: 253 Session: A1051B03 Range: npt=0.000- User-Agent: LibVLC/1.1.13 (LIVE555 Streaming Media v2010.02.10) parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "253", Content-Length 0, with 0 bytes following the message. RTCPInstance[0x957d4a0]::RTCPInstance() schedule(1.767632->1355733137.807304) sending response: RTSP/1.0 200 OK CSeq: 253 Date: Mon, Dec 17 2012 08:32:16 GMT Range: npt=0.000- Session: A1051B03 RTP-Info: url=rtsp:// 192.168.0.50:8554/proxyStream/track1;seq=420;rtptime=3838684052 Received 207 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Sat, Jan 01 2000 03:01:57 GMT Session: 728AAA5A RTP-Info: url=rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/track1;seq=58301;rtptime=663034382 [0x95773b8]saw incoming RTCP packet (from address 192.168.0.250, port 6971) 80c80006 dc48f48d bc17eca5 9d1244a6 27854dee 00000796 00288201 81ca0005 dc48f48d 010d3139 322e3136 382e302e 31363900 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xdc48f48d UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xdc48f48d validated entire RTCP packet schedule(0.164332->1355733136.936504) schedule(0.335704->1355733137.272356) schedule(0.284224->1355733137.556719) sending REPORT sending RTCP packet 81c90007 9a9f5e3c dc48f48d 00ffffff 0001e4d5 0000032c eca59d12 000166ed 81ca0005 9a9f5e3c 010a7a6a 2d646573 6b746f70 00000000 schedule(3.270177->1355733140.827560) schedule(0.487370->1355733138.294761) [0x957d4a0]saw incoming RTCP packet 81c90007 d5d12619 3ba47940 00000000 00000347 000002e6 00000000 00000000 81ca0005 d5d12619 010a7a6a 2d646573 6b746f70 00000000 RR RTSP client session (id "A1051B03", stream name "proxyStream"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0xd5d12619 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xd5d12619 validated entire RTCP packet schedule(0.811631->1355733139.106542) sending REPORT sending RTCP packet 80c80006 3ba47940 d4795713 1b5286b6 e4d1cce7 00000284 000c9eb3 81ca0005 3ba47940 010a7a6a 2d646573 6b746f70 00000000 schedule(2.422456->1355733141.529619) [0x957d4a0]saw incoming RTCP packet 81c90007 d5d12619 3ba47940 00000000 00000569 000002e2 57131b52 00018a30 81ca0005 d5d12619 010a7a6a 2d646573 6b746f70 00000000 RR RTSP client session (id "A1051B03", stream name "proxyStream"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0xd5d12619 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xd5d12619 validated entire RTCP packet schedule(1.728216->1355733142.555872) schedule(3.556653->1355733145.086369) [0x95773b8]saw incoming RTCP packet (from address 192.168.0.250, port 6971) 80c80006 dc48f48d bc17ecab 7e00e27e 278d60a4 00000bd7 003ef868 81ca0005 dc48f48d 010d3139 322e3136 382e302e 31363900 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xdc48f48d UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xdc48f48d validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9a9f5e3c dc48f48d 00ffffff 0001e874 000002ba ecab7e00 000085ba 81ca0005 9a9f5e3c 010a7a6a 2d646573 6b746f70 00000000 reap: checking SSRC 0xdc48f48d: 4 (threshold 0) schedule(5.176315->1355733147.732835) sending REPORT sending RTCP packet 80c80006 3ba47940 d4795719 16284599 e4da032f 00000769 00252f5d 81ca0005 3ba47940 010a7a6a 2d646573 6b746f70 00000000 schedule(2.360809->1355733147.447807) RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:T RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:E RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:A RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:R RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:D RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:O RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:W RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:N RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:p RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:9 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:2 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:6 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:8 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:8 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:4 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:p RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:o RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:x RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:y RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:a RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:m RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:R RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:T RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:P RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:C RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:q RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:2 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:4 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:o RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:n RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:A RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:B RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:3 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:U RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:- RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:A RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:g RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:n RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:L RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:b RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:V RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:L RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:C RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:3 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:( RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:L RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:I RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:V RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:E RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:a RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:m RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:n RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:g RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:M RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:d RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:a RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:v RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:2 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:2 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes:) RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9578620]::handleRequestBytes() read 1 new bytes: parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "proxyStream", urlSuffix "", CSeq "254", Content-Length 0, with 0 bytes following the message. RTCPInstance[0x957d4a0]::~RTCPInstance() sending BYE sending RTCP packet 80c80006 3ba47940 d479571a 8c7e49b2 e4dc0541 0000089d 002b3ad1 81cb0001 3ba47940 ProxyServerMediaSubsession["JPEG"]::closeStreamSource() Sending request: PAUSE rtsp:// 192.168.0.250:8555/PSIA/Streaming/channels/0?videoCodecType=MJPEG/ RTSP/1.0 CSeq: 7 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.11.16) Session: 728AAA5A sending response: RTSP/1.0 200 OK CSeq: 254 Date: Mon, Dec 17 2012 08:37:26 GMT RTSPClientConnection[0x9578620]::handleRequestBytes() read 2 new bytes:$ RTSPClientConnection[0x9578620]::handleRequestBytes() read -1 new bytes (of 9998); terminating connection! Received 84 new bytes of response data. Received a complete PAUSE response: RTSP/1.0 200 OK CSeq: 7 Date: Sat, Jan 01 2000 03:02:08 GMT Session: 728AAA5A sending REPORT sending RTCP packet 81c90007 9a9f5e3c dc48f48d 00ffffff 0001eb5a 000002df ecab7e00 0005b315 81ca0005 9a9f5e3c 010a7a6a 2d646573 6b746f70 00000000 schedule(2.873885->1355733150.607592) [0x95773b8]saw incoming RTCP packet (from address 192.168.0.250, port 6971) 80c80006 dc48f48d bc17ecb1 5f5fd47c 279573f4 00001024 0055942b 81ca0005 dc48f48d 010d3139 322e3136 382e302e 31363900 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xdc48f48d UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xdc48f48d validated entire RTCP packet -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Mon Dec 17 17:49:02 2012 From: bdrung at debian.org (Benjamin Drung) Date: Tue, 18 Dec 2012 02:49:02 +0100 Subject: [Live-devel] shared library In-Reply-To: References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> Message-ID: <1355795342.11454.19.camel@deep-thought> Am Samstag, den 15.12.2012, 17:37 +1000 schrieb Ross Finlayson: > Benjamin, > > > I've now installed a new release - 2012.12.15 - that adds a new > configuration file "config.linux-with-shared-libraries". Thanks. > Please verify that this works properly for you (i.e., after first > running "genMakefiles linux-with-shared-libraries"). (Unfortunately > I'm traveling for the rest of the month, and don't have access to a > Linux system for testing). If there are problems with this, then > please let me know ASAP. I tested linux-with-shared-libraries by creating a shared library packages and building vlc against it. I found some issues: 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). The solution with the additional SHORT_LIB_SUFFIX variable is a bit hacky. 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. 3) Some symbols used by the shared libraries are not found in none of the libraries (build.log attached). -- Benjamin Drung Debian & Ubuntu Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: install-target.patch Type: text/x-patch Size: 4914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: text/x-log Size: 6362 bytes Desc: not available URL: From bdrung at debian.org Mon Dec 17 18:28:27 2012 From: bdrung at debian.org (Benjamin Drung) Date: Tue, 18 Dec 2012 03:28:27 +0100 Subject: [Live-devel] Support for CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS Message-ID: <1355797707.11454.23.camel@deep-thought> Hi, please support CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS. It would be nice if the build system honors these variables if they are set by the user. In Debian, hardening flags are passed through these variables. A patch that add the support is attached. -- Benjamin Drung Debian & Ubuntu Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: pass-variables.patch Type: text/x-patch Size: 2420 bytes Desc: not available URL: From dalcaraz at eye-cam.com Tue Dec 18 06:01:15 2012 From: dalcaraz at eye-cam.com (David Alcaraz Moreno) Date: Tue, 18 Dec 2012 15:01:15 +0100 Subject: [Live-devel] Error RTSP PLAY failed RTSP response was truncated. Increase RTSPClient::responseBufferSize Message-ID: <50D0772B.1060007@eye-cam.com> Hi, someone can explain to me the meaning of this error, I've been looking for the meaning but I don't find nothing that can help me. This error occurs when I try to playing the rtsp url with vlc. If I try to play with opentRTSP and playing the url, there is not error.... This is the output: C:\Development\Tests\openrtsp\Debug>openrtsp.exe -n -v rtsp://192.168.0.49:8554/ testStream Opening connection to 192.168.0.49, port 8554... ...remote connection opened Sending request: OPTIONS rtsp://192.168.0.49:8554/testStream RTSP/1.0 CSeq: 2 User-Agent: openrtsp.exe (LIVE555 Streaming Media v2012.11.30) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Tue, Dec 18 2012 13:54:47 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER Sending request: DESCRIBE rtsp://192.168.0.49:8554/testStream RTSP/1.0 CSeq: 3 User-Agent: openrtsp.exe (LIVE555 Streaming Media v2012.11.30) Accept: application/sdp Received 574 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Tue, Dec 18 2012 13:54:47 GMT Content-Base: rtsp://192.168.0.49:8554/testStream/ Content-Type: application/sdp Content-Length: 405 v=0 o=- 1355838850965672 1 IN IP4 192.168.0.49 s=testStream i=testStream t=0 0 a=tool:LIVE555 Streaming Media v2012.11.30 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.0.49 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:testStream a=x-qt-text-inf:testStream m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:270966402 a=rtpmap:96 MP4V-ES/90000 a=control:track1 Opened URL "rtsp://192.168.0.49:8554/testStream", returning a SDP description: v=0 o=- 1355838850965672 1 IN IP4 192.168.0.49 s=testStream i=testStream t=0 0 a=tool:LIVE555 Streaming Media v2012.11.30 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.0.49 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:testStream a=x-qt-text-inf:testStream m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:270966402 a=rtpmap:96 MP4V-ES/90000 a=control:track1 Created receiver for "video/MP4V-ES" subsession (client ports 1830-1831) Sending request: SETUP rtsp://192.168.0.49:8554/testStream/track1 RTSP/1.0 CSeq: 4 User-Agent: openrtsp.exe (LIVE555 Streaming Media v2012.11.30) Transport: RTP/AVP;unicast;client_port=1830-1831 Received 201 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Tue, Dec 18 2012 13:54:47 GMT Transport: RTP/AVP;unicast;destination=192.168.0.49;source=192.168.0.49;client_p ort=1830-1831;server_port=6970-6971 Session: AA91459D Setup "video/MP4V-ES" subsession (client ports 1830-1831) Outputting data from the "video/MP4V-ES" subsession to 'stdout' Sending request: PLAY rtsp://192.168.0.49:8554/testStream/ RTSP/1.0 CSeq: 5 User-Agent: openrtsp.exe (LIVE555 Streaming Media v2012.11.30) Session: AA91459D Range: npt=0.000- Received 190 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Tue, Dec 18 2012 13:54:47 GMT Range: npt=0.000- Session: AA91459D RTP-Info: url=rtsp://192.168.0.49:8554/testStream/track1;seq=27537;rtptime=27360 04141 Started playing session Receiving streamed data... Data packets have begun arriving [1355838887419] From finlayson at live555.com Tue Dec 18 16:11:12 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Dec 2012 10:11:12 +1000 Subject: [Live-devel] Error RTSP PLAY failed RTSP response was truncated. Increase RTSPClient::responseBufferSize In-Reply-To: <50D0772B.1060007@eye-cam.com> References: <50D0772B.1060007@eye-cam.com> Message-ID: > someone can explain to me the meaning of this error, I've been looking for the meaning but I don't find nothing that can help me. > This error occurs when I try to playing the rtsp url with vlc. > If I try to play with opentRTSP and playing the url, there is not error.... The problem here is probably that VLC is requesting RTP/RTCP-over-TCP streaming, and it's using an old version of the "LIVE555 Streaming Media" software that has a bug (when RTP/RTCP-over-TCP streaming is used) that can cause this error to be reported. If you were to rebuild VLC to use an up-to-date version of our code, you most likely would stop seeing these error messages. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Tue Dec 18 01:59:11 2012 From: bdrung at debian.org (Benjamin Drung) Date: Tue, 18 Dec 2012 10:59:11 +0100 Subject: [Live-devel] changelog.txt in source tarball Message-ID: <1355824751.10895.2.camel@deep-thought> Hi, please put the changelog.txt [1] in the source tarball. We like to put this changelog file into our Debian package and it will make it simpler if the changelog file is in the source tarball. [1] http://live555.com/liveMedia/public/changelog.txt -- Benjamin Drung Debian & Ubuntu Developer From finlayson at live555.com Tue Dec 18 16:33:28 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Dec 2012 10:33:28 +1000 Subject: [Live-devel] changelog.txt in source tarball In-Reply-To: <1355824751.10895.2.camel@deep-thought> References: <1355824751.10895.2.camel@deep-thought> Message-ID: <8F1B1734-E5DD-4EA8-AA6D-75BF9F9D7E6E@live555.com> > please put the changelog.txt [1] in the source tarball. No, because it's important that people know whether or not they have the latest version of the code (and, if they don't, what improvements have been made to later versions). Therefore the changelog is not copied; instead, people should link to it at http://live555.com/liveMedia/public/changelog.txt (Also the changelog - unlike the source code - is *not* licensed under the LGPL; copies or modifications to the changelog are not permitted.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Tue Dec 18 04:19:57 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Tue, 18 Dec 2012 20:19:57 +0800 Subject: [Live-devel] regarding live555 on mulit core Message-ID: <009501cddd1a$00443290$00cc97b0$@126.com> HI, As we know, now the most cpus have mulit core, does live555 optimized for multi cores? I found that the performance of live555 is same when my cpu has 4 cores or 6 cores. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 18 17:00:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Dec 2012 11:00:59 +1000 Subject: [Live-devel] regarding live555 on mulit core In-Reply-To: <009501cddd1a$00443290$00cc97b0$@126.com> References: <009501cddd1a$00443290$00cc97b0$@126.com> Message-ID: <1B4C0E72-FD0C-4C02-8BED-FD4826E4534F@live555.com> > As we know, now the most cpus have mulit core, does live555 optimized for multi cores? Because you have read the FAQ (as everyone was asked to do before posting to the mailing list), I assume that you have already read: http://www.live555.com/liveMedia/faq.html#threads which explains the circumstances under which LIVE555 code can use multiple threads (and thus multiple cores, if they are available). Note, however, that applications that use the "LIVE555 Streaming Media" code are usually "I/O bound" rather than "CPU bound", meaning that they typically spend most of their time waiting for data (e.g., from an input socket, or from a data file), rather than computing. However, one circumstance in which it might make sense to optimize for multiple cores is if you use your own encoder (or decoder) 'filter' class within a LIVE555 source->filter->sink data chain. In this case - because encoders (and decoders) are usually CPU intensive - you might want to think about structuring the implementation of your encoder (or decoder) filter to use multiple threads. You would do this in the usual way: one thread (only!) would run the LIVE555 code itself; the remaining thread(s) would do the encoding (or decoding), and communicate with the LIVE555 thread via event triggers. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalcaraz at eye-cam.com Wed Dec 19 08:19:18 2012 From: dalcaraz at eye-cam.com (David Alcaraz Moreno) Date: Wed, 19 Dec 2012 17:19:18 +0100 Subject: [Live-devel] live-devel Digest, Vol 110, Issue 17 In-Reply-To: References: Message-ID: <50D1E906.8000701@eye-cam.com> Re: Error RTSP PLAY failed RTSP response was truncated. Increase RTSPClient::responseBufferSize (Ross Finlayson) Thanks! I have builded the vlc with the live555 new version, unfortunately I have new error, no data received in 10s, but this is not the one, viewing the network packets, I have seen two messages more: 1- client to server -> RTP packet -> Info = unknown RTP version 3 2- client to server -> ICMP packet -> info = Destination unreachable (unreachable port) for the ICMP message I tried to change the server port (8554) to 554 but the problem was not solve. The computers, server and client, are in the same network, the configuration of the network is ok. The RTP packets has been send because if I have seen the network transfer packets, and the RTP packets has send when I started to play the video url. My rtsp server is developed with the latest version of live555. To see that I have used a sniffer. Any idea? Sorry for my english! thanks! Best regards! Al 19/12/12 01:11, En/na live-devel-request at ns.live555.com ha escrit: > Send live-devel mailing list submissions to > live-devel at lists.live555.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.live555.com/mailman/listinfo/live-devel > or, via email, send a message with subject or body 'help' to > live-devel-request at lists.live555.com > > You can reach the person managing the list at > live-devel-owner at lists.live555.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of live-devel digest..." > > > Today's Topics: > > 1. Re: shared library (Benjamin Drung) > 2. Support for CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS (Benjamin Drung) > 3. Error RTSP PLAY failed RTSP response was truncated. Increase > RTSPClient::responseBufferSize (David Alcaraz Moreno) > 4. Re: Error RTSP PLAY failed RTSP response was truncated. > Increase RTSPClient::responseBufferSize (Ross Finlayson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 Dec 2012 02:49:02 +0100 > From: Benjamin Drung > To: live-devel at ns.live555.com > Subject: Re: [Live-devel] shared library > Message-ID: <1355795342.11454.19.camel at deep-thought> > Content-Type: text/plain; charset="utf-8" > > Am Samstag, den 15.12.2012, 17:37 +1000 schrieb Ross Finlayson: >> Benjamin, >> >> >> I've now installed a new release - 2012.12.15 - that adds a new >> configuration file "config.linux-with-shared-libraries". > Thanks. > >> Please verify that this works properly for you (i.e., after first >> running "genMakefiles linux-with-shared-libraries"). (Unfortunately >> I'm traveling for the rest of the month, and don't have access to a >> Linux system for testing). If there are problems with this, then >> please let me know ASAP. > I tested linux-with-shared-libraries by creating a shared library > packages and building vlc against it. I found some issues: > > 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). The solution with the additional > SHORT_LIB_SUFFIX variable is a bit hacky. > > 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. > > 3) Some symbols used by the shared libraries are not found in none of > the libraries (build.log attached). > From kingaceck at 163.com Wed Dec 19 01:04:37 2012 From: kingaceck at 163.com (kingaceck) Date: Wed, 19 Dec 2012 17:04:37 +0800 Subject: [Live-devel] setup datagram socket fail Message-ID: <201212191704367182546@163.com> I use live555 for a multicast server.I use my client program to connect to the live555 16 times at one operation. After openning and closing my client program,the live555 show errors: 16:47:39 Groupsock(-1: 225.1.1.10, 50822, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50824, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50826, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50828, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50830, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50832, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50834, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50836, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50838, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50840, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50842, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50844, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50846, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50848, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50850, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50852, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50854, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50856, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50858, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50860, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50862, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50864, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50866, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50868, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50870, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50872, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50874, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50876, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50878, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50880, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50882, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor 16:47:39 Groupsock(-1: 225.1.1.10, 50884, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad file descriptor ...... I find that after "sock = socket(AF_INET, type|SOCK_CLOEXEC, 0); " the sock value is -1 and the errno is 24.I creat the rtp groupsock like belows : static portNumBits initialPortNum = 30000;//note that it is a static var struct in_addr destinationAddress ; destinationAddress.s_addr = our_inet_addr(fMulticastAddr);//fMulticastAddr comes from client's url Port serverRTPPort(0); Port serverRTCPPort(0); Groupsock* rtpGroupsock; Groupsock* rtcpGroupsock; NoReuse dummy(envir()); // ensures that we skip over ports that are already in use unsigned i = 1,j=0; if(initialPortNum > 65530)//the max port is 65535 initialPortNum = 30000; for (;i<3; initialPortNum += 2) { serverRTPPort = initialPortNum; j++; if(j>10000)//if can't success after 10000 times try,may be there is a error.exit { fAfterGettingClientData = NULL; return; } rtpGroupsock = new Groupsock(envir(), destinationAddress, serverRTPPort, 255); if (rtpGroupsock->socketNum() < 0) { envir() << "rtp:" << serverRTPPort<<"\n"; delete rtpGroupsock; continue; // try again } serverRTCPPort = initialPortNum+1; rtcpGroupsock = new Groupsock(envir(), destinationAddress, serverRTCPPort, 255); if (rtcpGroupsock->socketNum() < 0) { envir()<< "rtcp:" << serverRTCPPort<<"\n"; delete rtpGroupsock; delete rtcpGroupsock; continue; // try again } if(i == 1){// success fRtpGroupsockAudio = rtpGroupsock; fRtcpGroupsockAudio = rtcpGroupsock; }else{ fRtpGroupsockVideo = rtpGroupsock; fRtcpGroupsockVideo = rtcpGroupsock; } //envir() << "serverPortNum:" << initialPortNum << "\n"; i++; } I have try many days to resolve this. Is there any error,please help me.Tank you very much. 2012-12-19 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Dec 20 07:23:30 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 20 Dec 2012 08:23:30 -0700 Subject: [Live-devel] setup datagram socket fail In-Reply-To: <201212191704367182546@163.com> References: <201212191704367182546@163.com> Message-ID: <50D32D72.60405@etr-usa.com> On 12/19/2012 02:04, kingaceck wrote: > ...... > I find that after "sock = socket(AF_INET, type|SOCK_CLOEXEC, 0); " the > sock value is -1 and the errno is 24. errno 24 is EMFILE, on a Linux box, which means there are too many files open by the current user. Since you say you're running it 16 times and the FD limit on Linux defaults to 1024, it means you're probably not closing some files, at least indirectly. If you run your program through valgrind, you'll probably find that you aren't cleaning up all Live555 objects you're using. From finlayson at live555.com Thu Dec 20 17:01:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Dec 2012 11:01:48 +1000 Subject: [Live-devel] Error RTSP PLAY failed RTSP response was truncated. Increase RTSPClient::responseBufferSize In-Reply-To: <50D1E906.8000701@eye-cam.com> References: <50D1E906.8000701@eye-cam.com> Message-ID: <1E29FF3A-545F-4E14-A2FB-C5E5F07956AF@live555.com> First, when you reply to a mailing list 'Digest', please correct the "Subject:" line of your message (as I have done here), and trim the quoted message in your response. > I have builded the vlc with the live555 new version, unfortunately I have new error, no data received in 10s That error message (from VLC) usually means that - somewhere between your client (VLC) and your server - there is a firewall that is blocking RTP/UDP packets. However, because you also note that: > The computers, server and client, are in the same network, the configuration of the network is ok. This suggests that something may be wrong with your server. Unfortunately, it's hard for us to help you with 'custom' server applications; instead, you should start by running the supplied 'demo' server applications "testOnDemandRTSPServer" and "live555MediaServer" (built using the latest version of our software). Also, because VLC is not our software, you should instead begin by using the 'demo' client applications "testRTSPClient" and "openRTSP". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yossics at gmail.com Wed Dec 19 11:38:20 2012 From: yossics at gmail.com (Yossi Cohen-Shahar) Date: Wed, 19 Dec 2012 21:38:20 +0200 Subject: [Live-devel] RTP over RTSP strange problem Message-ID: Hi, I used the Live 555 to create an RTSP client that receives video a stream of RTP over RTSP (RTP over TCP). Server is not in my control and as far as I know it was developed using Live555 as well. My client is retrieving video in very high rate (around 65-170 fps, 3-9 time faster than the capture rate) and store it for later processing. The client is implemented in VS2010 and run under Win7. I have the following strange phenomena: On a couple of PCs the client can work for hours without any 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. In the beginning, I tried to understand why SocketDescriptor::tcpReadHandler1 (in RTPInterface.cpp) pass the control to the RTSP handler. However, I also captured the traffic with WireShark and saw the same confusion there! Attached please find a small capture file, if it is decoded as RTPS, the wrongfully interpretation can be seen in in packets 17-20 (server IP 10.0.0.213 client 10.0.0.111) If any other information is, larger capture file, etc.. is required ? I will be happy to provide it. I will appreciate any help, hint or idea. Thanks, YocoSha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTP RTSP.pcapng Type: application/octet-stream Size: 34588 bytes Desc: not available URL: From finlayson at live555.com Thu Dec 20 21:43:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Dec 2012 15:43:48 +1000 Subject: [Live-devel] Support for CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS In-Reply-To: <1355797707.11454.23.camel@deep-thought> References: <1355797707.11454.23.camel@deep-thought> Message-ID: > please support CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS. It would be nice if > the build system honors these variables if they are set by the user. In > Debian, hardening flags are passed through these variables. A patch that > add the support is attached. Thanks. This will be included in the next release of the software (which will also update the 'shared library' support, as outlined in your previous message - stay tuned...). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 20 21:55:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Dec 2012 15:55:03 +1000 Subject: [Live-devel] shared library In-Reply-To: <1355795342.11454.19.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> Message-ID: <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> > 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") > 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. > 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??) Anyway, thanks once again for your help with this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 21 18:02:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Dec 2012 12:02:47 +1000 Subject: [Live-devel] RTP over RTSP strange problem In-Reply-To: References: Message-ID: <62E4409D-62E7-4665-9415-CDCE3553FB1A@live555.com> > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Fri Dec 21 07:52:23 2012 From: bdrung at debian.org (Benjamin Drung) Date: Fri, 21 Dec 2012 16:52:23 +0100 Subject: [Live-devel] shared library In-Reply-To: <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> Message-ID: <1356105143.3949.11.camel@deep-thought> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: install-target.patch Type: text/x-patch Size: 599 bytes Desc: not available URL: From bdrung at debian.org Fri Dec 21 07:55:44 2012 From: bdrung at debian.org (Benjamin Drung) Date: Fri, 21 Dec 2012 16:55:44 +0100 Subject: [Live-devel] Patches in the Debian package Message-ID: <1356105344.3949.14.camel@deep-thought> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 020_invalid_casts.diff Type: text/x-patch Size: 1460 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 021_ip_mreq_source.diff Type: text/x-patch Size: 705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 022_synchronous_rtspclient.patch Type: text/x-patch Size: 1462 bytes Desc: not available URL: From bdrung at debian.org Fri Dec 21 08:22:39 2012 From: bdrung at debian.org (Benjamin Drung) Date: Fri, 21 Dec 2012 17:22:39 +0100 Subject: [Live-devel] distclean target Message-ID: <1356106959.8963.2.camel@deep-thought> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: distclean.patch Type: text/x-patch Size: 524 bytes Desc: not available URL: From finlayson at live555.com Fri Dec 21 18:51:01 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Dec 2012 12:51:01 +1000 Subject: [Live-devel] shared library In-Reply-To: <1356105143.3949.11.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> <1356105143.3949.11.camel@deep-thought> Message-ID: <0B9AE2DD-DF09-4D21-8CB4-6748C48573B1@live555.com> > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 21 19:06:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Dec 2012 13:06:42 +1000 Subject: [Live-devel] distclean target In-Reply-To: <1356106959.8963.2.camel@deep-thought> References: <1356106959.8963.2.camel@deep-thought> Message-ID: > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 21 19:22:18 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Dec 2012 13:22:18 +1000 Subject: [Live-devel] Patches in the Debian package In-Reply-To: <1356105344.3949.14.camel@deep-thought> References: <1356105344.3949.14.camel@deep-thought> Message-ID: > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Dec 21 18:56:47 2012 From: kingaceck at 163.com (kingaceck) Date: Sat, 22 Dec 2012 10:56:47 +0800 Subject: [Live-devel] about MultiFramedRTPSink::fOurMaxPacketSize Message-ID: <201212221056469376011@163.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 21 22:21:27 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Dec 2012 16:21:27 +1000 Subject: [Live-devel] about MultiFramedRTPSink::fOurMaxPacketSize In-Reply-To: <201212221056469376011@163.com> References: <201212221056469376011@163.com> Message-ID: <0C938B45-BE22-42C1-872F-A274E0B9CE69@live555.com> > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Sat Dec 22 05:01:22 2012 From: bdrung at debian.org (Benjamin Drung) Date: Sat, 22 Dec 2012 14:01:22 +0100 Subject: [Live-devel] shared library In-Reply-To: <0B9AE2DD-DF09-4D21-8CB4-6748C48573B1@live555.com> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> <1356105143.3949.11.camel@deep-thought> <0B9AE2DD-DF09-4D21-8CB4-6748C48573B1@live555.com> Message-ID: <1356181282.3327.2.camel@deep-thought> Am Samstag, den 22.12.2012, 12:51 +1000 schrieb Ross Finlayson: > > 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). Spaces are used instead of the required tabs in the install target (patch to fix this is attached). > > 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... https://en.wikipedia.org/wiki/Pkg-config http://people.freedesktop.org/~dbn/pkg-config-guide.html > > > > 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 :-) -- Benjamin Drung Debian & Ubuntu Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: install-target.patch Type: text/x-patch Size: 920 bytes Desc: not available URL: From bdrung at debian.org Sat Dec 22 05:08:47 2012 From: bdrung at debian.org (Benjamin Drung) Date: Sat, 22 Dec 2012 14:08:47 +0100 Subject: [Live-devel] Patches in the Debian package In-Reply-To: References: <1356105344.3949.14.camel@deep-thought> Message-ID: <1356181727.3327.8.camel@deep-thought> Am Samstag, den 22.12.2012, 13:22 +1000 schrieb Ross Finlayson: > > we carry three patches (attached) in the Debian package that predate > > my > > involvement in the Debian packaging. > > > 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). Why do you cast integers/bytes into void pointers? Unless there is a reason, I think the patch should be applied? > 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. I found a reason in the logs: "ip_mreq_source is defined in all glibc not just on kfreebsd. Fix hurd FTBFS" I'll check if this patch is still 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. I see a problem here: We build a static/shared library without the deprecated old, synchronous RTSPClient interface. If a user defines RTSPCLIENT_SYNCHRONOUS_INTERFACE, he will get the old header functions, but linking with the static/shared library will fail. -- Benjamin Drung Debian & Ubuntu Developer From bdrung at debian.org Sat Dec 22 06:03:02 2012 From: bdrung at debian.org (Benjamin Drung) Date: Sat, 22 Dec 2012 15:03:02 +0100 Subject: [Live-devel] Patches in the Debian package In-Reply-To: References: <1356105344.3949.14.camel@deep-thought> Message-ID: <1356184982.3327.10.camel@deep-thought> Am Samstag, den 22.12.2012, 13:22 +1000 schrieb Ross Finlayson: > 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. This patch is needed for Debian GNU/Hurd. Otherwise it will fail with c++ -c -Iinclude -I../UsageEnvironment/include -I. -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -Wall -DBSD=1 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security GroupsockHelper.cpp GroupsockHelper.cpp:447:8: error: redefinition of ?struct ip_mreq_source? In file included from include/NetCommon.h:91:0, from include/NetAddress.hh:29, from include/GroupsockHelper.hh:25, from GroupsockHelper.cpp:21: /usr/include/netinet/in.h:260:8: error: previous definition of ?struct ip_mreq_source? -- Benjamin Drung Debian & Ubuntu Developer From finlayson at live555.com Sat Dec 22 22:40:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 Dec 2012 16:40:03 +1000 Subject: [Live-devel] shared library In-Reply-To: <1356181282.3327.2.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> <1356105143.3949.11.camel@deep-thought> <0B9AE2DD-DF09-4D21-8CB4-6748C48573B1@live555.com> <1356181282.3327.2.camel@deep-thought> Message-ID: > Spaces are used instead of the required tabs in the install target Oops - fixed now. (I understand why many people hate Makefiles :-) Ross. From bdrung at debian.org Sun Dec 23 07:17:05 2012 From: bdrung at debian.org (Benjamin Drung) Date: Sun, 23 Dec 2012 16:17:05 +0100 Subject: [Live-devel] shared library In-Reply-To: References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> <1356105143.3949.11.camel@deep-thought> <0B9AE2DD-DF09-4D21-8CB4-6748C48573B1@live555.com> <1356181282.3327.2.camel@deep-thought> Message-ID: <1356275825.6252.0.camel@deep-thought> Am Sonntag, den 23.12.2012, 16:40 +1000 schrieb Ross Finlayson: > > Spaces are used instead of the required tabs in the install target > > Oops - fixed now. (I understand why many people hate Makefiles :-) It's still not fixed in 2012.12.23 and I actually like Makefiles. -- Benjamin Drung Debian & Ubuntu Developer From finlayson at live555.com Sun Dec 23 16:23:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Dec 2012 10:23:47 +1000 Subject: [Live-devel] shared library In-Reply-To: <1356275825.6252.0.camel@deep-thought> References: <1354966865.19778.9.camel@deep-thought> <5D6F8A39-6FBD-4E09-919B-90C7006232B2@live555.com> <1354993900.21788.18.camel@deep-thought> <1355249189.15977.53.camel@deep-thought> <1355795342.11454.19.camel@deep-thought> <21C3ED42-C19A-4286-970D-463459EE63F6@live555.com> <1356105143.3949.11.camel@deep-thought> <0B9AE2DD-DF09-4D21-8CB4-6748C48573B1@live555.com> <1356181282.3327.2.camel@deep-thought> <1356275825.6252.0.camel@deep-thought> Message-ID: <4FF09679-FF83-4473-B54D-BD9096CB1CBA@live555.com> > Am Sonntag, den 23.12.2012, 16:40 +1000 schrieb Ross Finlayson: >>> Spaces are used instead of the required tabs in the install target >> >> Oops - fixed now. (I understand why many people hate Makefiles :-) > > It's still not fixed in 2012.12.23 Argh! Brain fart! It's fixed for real now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Dec 23 16:30:25 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Dec 2012 10:30:25 +1000 Subject: [Live-devel] Patches in the Debian package In-Reply-To: <1356181727.3327.8.camel@deep-thought> References: <1356105344.3949.14.camel@deep-thought> <1356181727.3327.8.camel@deep-thought> Message-ID: <94FF1B20-18E8-408A-BB7A-4EEF9C2CE7E2@live555.com> >> 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). > > Why do you cast integers/bytes into void pointers? Unless there is a > reason, I think the patch should be applied? Perhaps, but I'll probably just change the code to eliminate the compiler warnings. >> 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. > > I found a reason in the logs: "ip_mreq_source is defined in all glibc > not just on kfreebsd. Fix hurd FTBFS" I'll check if this patch is still > needed. See my next message... >> 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. > > I see a problem here: We build a static/shared library without the > deprecated old, synchronous RTSPClient interface. If a user defines > RTSPCLIENT_SYNCHRONOUS_INTERFACE, he will get the old header functions, > but linking with the static/shared library will fail. There's no problem here. In lots of places in the code, there are pieces of code that are #ifdef'd out by default. (E.g., these often add extra diagnostic output to help with debugging.) It's always been understood that if a developer wants to enable these pieces of code, then they need to build the library themselves - with appropriate compile-time flags - rather than rely upon a pre-built library. This is no different. So the third patch should be removed. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Dec 23 16:36:44 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Dec 2012 10:36:44 +1000 Subject: [Live-devel] Patches in the Debian package In-Reply-To: <1356184982.3327.10.camel@deep-thought> References: <1356105344.3949.14.camel@deep-thought> <1356184982.3327.10.camel@deep-thought> Message-ID: <64A03C4E-C1C0-4533-BE6B-B96FA7E8F8E6@live555.com> On Dec 23, 2012, at 12:03 AM, Benjamin Drung wrote: > Am Samstag, den 22.12.2012, 13:22 +1000 schrieb Ross Finlayson: >> 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. > > This patch is needed for Debian GNU/Hurd. Otherwise it will fail with > > c++ -c -Iinclude -I../UsageEnvironment/include -I. -O2 > -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -Wall > -DBSD=1 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector > --param=ssp-buffer-size=4 -Wformat -Werror=format-security > GroupsockHelper.cpp > GroupsockHelper.cpp:447:8: error: redefinition of ?struct > ip_mreq_source? The issue is not the fact that Debian GNU/Hurd defines "struct ip_mreq_source". That's perfectly understandable; lots of systems do that. The problem is that this piece of code (where we give our own definition of "struct ip_mreq_source") is being reached only because the constant "IP_ADD_SOURCE_MEMBERSHIP" is *not* defined. This is a mistake. "IP_ADD_SOURCE_MEMBERSHIP" *has to be* defined somewhere, otherwise "struct ip_mreq_source" has no purpose. So the real solution here - rather than this bogus patch - is to find out where (in this system) IP_ADD_SOURCE_MEMBERSHIP is defined, and to add a patch, if necessary, that makes sure that the appropriate header file is #include'd. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdrung at debian.org Sun Dec 23 17:18:15 2012 From: bdrung at debian.org (Benjamin Drung) Date: Mon, 24 Dec 2012 02:18:15 +0100 Subject: [Live-devel] Patches in the Debian package In-Reply-To: <94FF1B20-18E8-408A-BB7A-4EEF9C2CE7E2@live555.com> References: <1356105344.3949.14.camel@deep-thought> <1356181727.3327.8.camel@deep-thought> <94FF1B20-18E8-408A-BB7A-4EEF9C2CE7E2@live555.com> Message-ID: <1356311895.19885.3.camel@deep-thought> Am Montag, den 24.12.2012, 10:30 +1000 schrieb Ross Finlayson: > > > > 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). > > > > Why do you cast integers/bytes into void pointers? Unless there is a > > reason, I think the patch should be applied? > > > Perhaps, but I'll probably just change the code to eliminate the > compiler warnings. I am happy by either carrying the patch or having the warnings fixes by a change from you. There was no convincing argument mentioned to drop the patch. > > > 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. > > > > I see a problem here: We build a static/shared library without the > > deprecated old, synchronous RTSPClient interface. If a user defines > > RTSPCLIENT_SYNCHRONOUS_INTERFACE, he will get the old header > > functions, > > but linking with the static/shared library will fail. > > > There's no problem here. In lots of places in the code, there are > pieces of code that are #ifdef'd out by default. (E.g., these often > add extra diagnostic output to help with debugging.) It's always been > understood that if a developer wants to enable these pieces of code, > then they need to build the library themselves - with appropriate > compile-time flags - rather than rely upon a pre-built library. This > is no different. So the third patch should be removed. I have removed the patch. Please keep in mind that future changes like that causes an ABI breakage (and therefore a soname bump). -- Benjamin Drung Debian & Ubuntu Developer From bdrung at debian.org Sun Dec 23 17:37:23 2012 From: bdrung at debian.org (Benjamin Drung) Date: Mon, 24 Dec 2012 02:37:23 +0100 Subject: [Live-devel] Patches in the Debian package In-Reply-To: <64A03C4E-C1C0-4533-BE6B-B96FA7E8F8E6@live555.com> References: <1356105344.3949.14.camel@deep-thought> <1356184982.3327.10.camel@deep-thought> <64A03C4E-C1C0-4533-BE6B-B96FA7E8F8E6@live555.com> Message-ID: <1356313043.19885.8.camel@deep-thought> Am Montag, den 24.12.2012, 10:36 +1000 schrieb Ross Finlayson: > > On Dec 23, 2012, at 12:03 AM, Benjamin Drung > wrote: > > > Am Samstag, den 22.12.2012, 13:22 +1000 schrieb Ross Finlayson: > > > 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. > > > > This patch is needed for Debian GNU/Hurd. Otherwise it will fail > > with > > > > c++ -c -Iinclude -I../UsageEnvironment/include -I. -O2 > > -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 > > -Wall > > -DBSD=1 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector > > --param=ssp-buffer-size=4 -Wformat -Werror=format-security > > GroupsockHelper.cpp > > GroupsockHelper.cpp:447:8: error: redefinition of ?struct > > ip_mreq_source? > > > The issue is not the fact that Debian GNU/Hurd defines "struct > ip_mreq_source". That's perfectly understandable; lots of systems do > that. The problem is that this piece of code (where we give our own > definition of "struct ip_mreq_source") is being reached only because > the constant "IP_ADD_SOURCE_MEMBERSHIP" is *not* defined. This is a > mistake. "IP_ADD_SOURCE_MEMBERSHIP" *has to be* defined somewhere, > otherwise "struct ip_mreq_source" has no purpose. On my system (Ubuntu 12.10, amd64), IP_ADD_SOURCE_MEMBERSHIP is defined in /usr/include/x86_64-linux-gnu/bits/in.h () and /usr/include/linux/in.h (). struct ip_mreq_source is defined in /usr/include/netinet/in.h (). On Debian GNU/Hurd, IP_ADD_SOURCE_MEMBERSHIP is defined nowhere in /usr/include and struct ip_mreq_source is defined in /usr/include/netinet/in.h () as on Linux. > So the real solution here - rather than this bogus patch - is to find > out where (in this system) IP_ADD_SOURCE_MEMBERSHIP is defined, and to > add a patch, if necessary, that makes sure that the appropriate header > file is #include'd. -- Benjamin Drung Debian & Ubuntu Developer From finlayson at live555.com Sun Dec 23 19:45:04 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Dec 2012 13:45:04 +1000 Subject: [Live-devel] Patches in the Debian package In-Reply-To: <1356313043.19885.8.camel@deep-thought> References: <1356105344.3949.14.camel@deep-thought> <1356184982.3327.10.camel@deep-thought> <64A03C4E-C1C0-4533-BE6B-B96FA7E8F8E6@live555.com> <1356313043.19885.8.camel@deep-thought> Message-ID: > On my system (Ubuntu 12.10, amd64), IP_ADD_SOURCE_MEMBERSHIP is defined > in /usr/include/x86_64-linux-gnu/bits/in.h () > and /usr/include/linux/in.h (). struct ip_mreq_source is > defined in /usr/include/netinet/in.h (). > > On Debian GNU/Hurd, IP_ADD_SOURCE_MEMBERSHIP is defined nowhere > in /usr/include and struct ip_mreq_source is defined > in /usr/include/netinet/in.h () as on Linux. OK, so it sounds like (someone) should submit a bug report for "Debian GNU/Hurd", noting that it needs to define IP_ADD_SOURCE_MEMBERSHIP (and IP_DROP_SOURCE_MEMBERSHIP) - presumably in "in.h" - in order for the source-specific multicast API (using "struct ip_mreq_source") to work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferielbenghorbel at gmail.com Wed Dec 26 06:38:17 2012 From: ferielbenghorbel at gmail.com (feriel ben ghorbel) Date: Wed, 26 Dec 2012 15:38:17 +0100 Subject: [Live-devel] Question live555MediaServer Message-ID: Bonjour , Est ce que en utilisant "live555MediaServer" peut on afficher un flux ou plusieurs flux ".ts" ? travers un browser ?? Cordialement From rafael.gdm at vaelsys.com Thu Dec 27 07:02:29 2012 From: rafael.gdm at vaelsys.com (Rafael Gil) Date: Thu, 27 Dec 2012 16:02:29 +0100 Subject: [Live-devel] QuickTime does not work with proxyServer program Message-ID: Hi, I'm trying to access a live RTSP stream from an AXIS camera through the RTSP proxy with the proxyServer program. So far no luck. It works just fine for VLC but not for QuickTime. The problem seems to be that RR packets are not treated the same way: with VLC the noteClientLiveness method is called so the client session does not timeout. With QuickTime noteClientLiveness is not called so after a few seconds I get the message "RTSP client session (id "6F559A12", stream name "proxyStream") has timed out (due to inactivity)". Find attached both logs in verbose and debug mode. Any ideas? Thank you in advance -- Rafael Gil Vaelsys -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt.log Type: application/octet-stream Size: 47115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vlc.log Type: application/octet-stream Size: 33211 bytes Desc: not available URL: From finlayson at live555.com Thu Dec 27 09:50:27 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Dec 2012 06:50:27 +1300 Subject: [Live-devel] QuickTime does not work with proxyServer program In-Reply-To: References: Message-ID: <56D328FC-D8D1-4E82-93EB-4FD7CBDAB575@live555.com> > I'm trying to access a live RTSP stream from an AXIS camera through the RTSP proxy with the proxyServer program. So far no luck. It works just fine for VLC but not for QuickTime. The problem seems to be that RR packets are not treated the same way: with VLC the noteClientLiveness method is called so the client session does not timeout. With QuickTime noteClientLiveness is not called so after a few seconds I get the message "RTSP client session (id "6F559A12", stream name "proxyStream") has timed out (due to inactivity)". Find attached both logs in verbose and debug mode. Any ideas? Hmm, you failed to mention that there are a lot of things different about your two client sessions - apart from just the media player application that they use. You are apparently running VLC on the same computer (192.168.0.26) on which you're running the "LIVE555 Proxy Server". That's OK, but strange. On the other hand, you are running QuickTime Player on a different computer: 192.168.0.28. That's also OK (and not strange :-). What *is* strange, however, is that QuickTime Player is requesting RTSP-over-HTTP streaming (using port 8000), even though it seems to be running on the same subnet as the proxy server, and therefore could probably just requested regular RTSP streaming instead. The problem seems to be that - for some unknown reason (perhaps an incompatibility in the way that QuickTime Player implements RTSP-over-HTTP streaming?) - the QuickTime Player client is not sending periodic RTCP packets to indicate its liveness. The quickest solution would be to stop your QuickTime Player client from requesting RTSP-over-HTTP streaming - something that it probably doesn't need to do. Another solution (not recommended) would be to stop the proxy server from timing out clients due to inactivity. You can do that by setting the "reclamationTestSeconds" parameter to 0 in the calls to "RTSPServer::createNew()" in "proxyServer/live555ProxyServer.cpp". I.e., change the calls to RTSPServer::createNew(*env, rtspServerPortNum, authDB); to RTSPServer::createNew(*env, rtspServerPortNum, authDB, 0); (The disadvantage of this, however, is that TCP connections (and sockets) for clients that die without doing a RTSP "TEARDOWN" will stay around indefinitely, and eventually your proxy server will run out of sockets.) The ideal solution would be fix whatever problem is causing QuickTime (when using RTSP-over-HTTP streaming) to apparently not send RTCP "RR" packets correctly. Unfortunately we can't help you with this; however, you should make sure that QuickTime is up-to-date on this computer (which looks like it's running Windows XP). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Dec 27 16:30:19 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 27 Dec 2012 17:30:19 -0700 Subject: [Live-devel] Question live555MediaServer In-Reply-To: References: Message-ID: <50DCE81B.2030609@etr-usa.com> On 12/26/2012 07:38, feriel ben ghorbel wrote: > Bonjour , You're going to get more help if you use English than French. > Est ce que en utilisant "live555MediaServer" peut on afficher un flux > ou plusieurs flux ".ts" ? travers un browser ?? VLC has a browser plugin that can catch MPEG TS streams sent by Live555's media server. If you must work with native browser facilities, then no, there is no direct support right now. Browsers natively expect video to be delivered via HTTP, not RTSP. Apple browsers (desktop Safari and iOS Safari) support a variant of straight HTTP downloads called HLS, which is supported in Live555 right now, but that's not going to help you with other browsers. From tayeb.dotnet at gmail.com Thu Dec 27 01:07:44 2012 From: tayeb.dotnet at gmail.com (Tayeb Meftah) Date: Thu, 27 Dec 2012 10:07:44 +0100 Subject: [Live-devel] Question live555MediaServer References: Message-ID: <52868E0AA74B40C6947E3DA5EA0E888F@worksc08f920f1> Salam Feriel ;) le Live555 Media server support les flues .TS et d'autre, mais le .TS n'est pas recomand? pour les browsers s'il include un codec MPEG2. tu doit l'avoir en H.264 et l'audio MP3 ou AAC. qu'elle est vos besoin svp ? Merci. ----- Original Message ----- From: "feriel ben ghorbel" To: Sent: Wednesday, December 26, 2012 3:38 PM Subject: [Live-devel] Question live555MediaServer Bonjour , Est ce que en utilisant "live555MediaServer" peut on afficher un flux ou plusieurs flux ".ts" ? travers un browser ?? Cordialement _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From rafael.gdm at vaelsys.com Fri Dec 28 02:08:47 2012 From: rafael.gdm at vaelsys.com (Rafael Gil) Date: Fri, 28 Dec 2012 11:08:47 +0100 Subject: [Live-devel] QuickTime does not work with proxyServer program In-Reply-To: <56D328FC-D8D1-4E82-93EB-4FD7CBDAB575@live555.com> References: <56D328FC-D8D1-4E82-93EB-4FD7CBDAB575@live555.com> Message-ID: Hi, Thanks for the quick answer. You are right: when QuickTime is configured to run RTSP over UDP it seems to work fine. Unfortunately I need it to be TCP or HTTP as I'm planning to use connections over a WAN 3G network where UDP traffic may not be allowed. Is there a way to be 100% sure this is a player issue? Which other players do you suggest? I tried VLC but the Web plugin does not seems to be very stable... The other solution, setting reclamationTestSeconds to 0, does not seems to work. In fact, it ends very bad as the program terminates unexpectedly (see attached log). Any ideas on this one? Is QT supposed to work over HTTP? I mean, has this been tested? Regards Rafael Gil Vaelsys 2012/12/27 Ross Finlayson > I'm trying to access a live RTSP stream from an AXIS camera through the > RTSP proxy with the proxyServer program. So far no luck. It works just fine > for VLC but not for QuickTime. The problem seems to be that RR packets are > not treated the same way: with VLC the noteClientLiveness method is called > so the client session does not timeout. With QuickTime noteClientLiveness > is not called so after a few seconds I get the message "RTSP client session > (id "6F559A12", stream name "proxyStream") has timed out (due to > inactivity)". Find attached both logs in verbose and debug mode. Any ideas? > > > Hmm, you failed to mention that there are a lot of things different about > your two client sessions - apart from just the media player application > that they use. > > You are apparently running VLC on the same computer (192.168.0.26) on > which you're running the "LIVE555 Proxy Server". That's OK, but strange. > > On the other hand, you are running QuickTime Player on a different > computer: 192.168.0.28. That's also OK (and not strange :-). What *is* > strange, however, is that QuickTime Player is requesting RTSP-over-HTTP > streaming (using port 8000), even though it seems to be running on the same > subnet as the proxy server, and therefore could probably just requested > regular RTSP streaming instead. > > The problem seems to be that - for some unknown reason (perhaps an > incompatibility in the way that QuickTime Player implements RTSP-over-HTTP > streaming?) - the QuickTime Player client is not sending periodic RTCP > packets to indicate its liveness. > > The quickest solution would be to stop your QuickTime Player client from > requesting RTSP-over-HTTP streaming - something that it probably doesn't > need to do. > > Another solution (not recommended) would be to stop the proxy server from > timing out clients due to inactivity. You can do that by setting the > "reclamationTestSeconds" parameter to 0 in the calls to > "RTSPServer::createNew()" in "proxyServer/live555ProxyServer.cpp". I.e., > change the calls to > RTSPServer::createNew(*env, rtspServerPortNum, authDB); > to > RTSPServer::createNew(*env, rtspServerPortNum, authDB, 0); > (The disadvantage of this, however, is that TCP connections (and sockets) > for clients that die without doing a RTSP "TEARDOWN" will stay around > indefinitely, and eventually your proxy server will run out of sockets.) > > The ideal solution would be fix whatever problem is causing QuickTime > (when using RTSP-over-HTTP streaming) to apparently not send RTCP "RR" > packets correctly. Unfortunately we can't help you with this; however, you > should make sure that QuickTime is up-to-date on this computer (which looks > like it's running Windows XP). > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- Rafael Gil Vaelsys -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt-no-reclamation.log Type: application/octet-stream Size: 37147 bytes Desc: not available URL: From finlayson at live555.com Fri Dec 28 03:34:52 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Dec 2012 00:34:52 +1300 Subject: [Live-devel] QuickTime does not work with proxyServer program In-Reply-To: References: <56D328FC-D8D1-4E82-93EB-4FD7CBDAB575@live555.com> Message-ID: <345787DF-6DAA-439D-B3E1-BAD7C44127D9@live555.com> > I tried VLC but the Web plugin does not seems to be very stable... Why don't you ask VLC about this? > The other solution, setting reclamationTestSeconds to 0, does not seems to work. In fact, it ends very bad as the program terminates unexpectedly (see attached log). Any ideas on this one? This might be an independent bug. I'm currently investigating this. > Is QT supposed to work over HTTP? I presume so; however, I'm not Apple. Only Apple knows why QuickTime Player is apparently not sending RTCP "RR" packets. If you want to investigate this, then I suggest asking Apple (perhaps via a QuickTime mailing list). I wouldn't hold my breath, though, because Apple's support of QuickTime has recently been marginal, at best. (These days, they seem to be more focused on 'HTTP Live Streaming' instead.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.gdm at vaelsys.com Fri Dec 28 04:16:31 2012 From: rafael.gdm at vaelsys.com (Rafael Gil) Date: Fri, 28 Dec 2012 13:16:31 +0100 Subject: [Live-devel] Open only video stream in RTSP proxy Message-ID: Is there a way to open only the video stream from a source when proxying an RTSP stream? That is, my source has both video and audio but I want to proxy only video and avoid the "backend" audio traffic overhead as I am not interested on audio. Thank you -- Rafael Gil Vaelsys -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.gdm at vaelsys.com Fri Dec 28 08:27:46 2012 From: rafael.gdm at vaelsys.com (Rafael Gil) Date: Fri, 28 Dec 2012 17:27:46 +0100 Subject: [Live-devel] RTSP/1.0 454 Session Not Found Message-ID: At some point my RTSP source answers with error code "RTSP/1.0 454 Session Not Found" to RTSP commands but seems not being handled by RTSP client. Why? Is this an invalid error code? How can I treat the error properly? Regards -- Rafael Gil Vaelsys -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 28 08:51:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Dec 2012 05:51:59 +1300 Subject: [Live-devel] Open only video stream in RTSP proxy In-Reply-To: References: Message-ID: <76C05CE4-E0D9-4C3E-9A4C-0EC019BE8C2F@live555.com> > Is there a way to open only the video stream from a source when proxying an RTSP stream? That is, my source has both video and audio but I want to proxy only video and avoid the "backend" audio traffic overhead as I am not interested on audio. You should try the following, in order: 1/ Check whether you can reconfigure your back-end RTSP server to stream only video. 2/ Check whether you can use the 'back-end' "rtsp://" URL (that you give to your proxy) to request that your back-end RTSP server stream only video, using the "a=control:" string specified in the SDP description. E.g., using your example, try to proxy the "rtsp://" URL: rtsp://root:root at 192.168.0.74/axis-media/media.amp/trackID=1 (Note that this probably won't work, but is worth trying, just in case.) 3/ (If neither 1 nor 2 works): Modify the code for the function "ProxyServerMediaSession::continueAfterDESCRIBE()", adding the following statement at line 117: if (strcmp(mss->mediumName(), "video") != 0) continue; Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 28 08:59:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Dec 2012 05:59:20 +1300 Subject: [Live-devel] RTSP/1.0 454 Session Not Found In-Reply-To: References: Message-ID: <22EFD09E-5E20-44BB-8C20-C57D9A9F81F2@live555.com> > At some point my RTSP source answers with error code "RTSP/1.0 454 Session Not Found" to RTSP commands but seems not being handled by RTSP client. Why? Is this an invalid error code? Yes. It is usually returned by the server when the client attempts to access a stream using an invalid RTSP 'session id' string. That shouldn't be happening (with our RTSP client or proxy code), so I'm curious as to why you're getting this error. (See below.) > How can I treat the error properly? You can't - because it's an error. The real question is: Why is this error occurring? The only way I can answer this is to see the RTSP protocol exchange that's causing it. If you are seeing this error from your 'back-end' server when running the "LIVE555 Proxy Server", then send us the diagnostic output that you get when you run the proxy server with the "-V" flag. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.gdm at vaelsys.com Fri Dec 28 10:06:34 2012 From: rafael.gdm at vaelsys.com (Rafael Gil) Date: Fri, 28 Dec 2012 19:06:34 +0100 Subject: [Live-devel] RTSP/1.0 454 Session Not Found In-Reply-To: <22EFD09E-5E20-44BB-8C20-C57D9A9F81F2@live555.com> References: <22EFD09E-5E20-44BB-8C20-C57D9A9F81F2@live555.com> Message-ID: There you go. I had to "play" a little bit with it before the error occurs so the log is pretty big (also I added some printfs myself) but the whole sequence is there and you get the error at the end. I'm curious of how would I have to reset/close the connection so it could be reopened by the client to stablish a new session. If the error occurs, at least I would like the system to recover even if it is with a new session. Is this possible? Thank you 2012/12/28 Ross Finlayson > At some point my RTSP source answers with error code "RTSP/1.0 454 Session > Not Found" to RTSP commands but seems not being handled by RTSP client. > Why? Is this an invalid error code? > > > Yes. It is usually returned by the server when the client attempts to > access a stream using an invalid RTSP 'session id' string. That shouldn't > be happening (with our RTSP client or proxy code), so I'm curious as to why > you're getting this error. (See below.) > > > How can I treat the error properly? > > > You can't - because it's an error. The real question is: Why is this > error occurring? The only way I can answer this is to see the RTSP > protocol exchange that's causing it. If you are seeing this error from > your 'back-end' server when running the "LIVE555 Proxy Server", then send > us the diagnostic output that you get when you run the proxy server with > the "-V" flag. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- Rafael Gil Vaelsys -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vrtspproxy.stderr Type: application/octet-stream Size: 53030 bytes Desc: not available URL: From finlayson at live555.com Fri Dec 28 13:37:01 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Dec 2012 10:37:01 +1300 Subject: [Live-devel] RTSP/1.0 454 Session Not Found In-Reply-To: References: <22EFD09E-5E20-44BB-8C20-C57D9A9F81F2@live555.com> Message-ID: <5B43BD47-D46C-4366-B0E4-B321DC83DB42@live555.com> Well, what's happening here is that - for some strange reason - the RTSP connection between your front-end client and the proxy is timing out (due to inactivity). I say "for some strange reason" because - prior to this - the proxy was receiving periodic RTCP "RR" packets from the packets OK, but (again, for some strange reason) did not recognize these RTCP packets as indicating client 'liveness'. You are going to have to figure out yourself why this is happening, because (1) I don't understand why it's happening, and (2) I'm not convinced that the problem is not somehow caused by your own modifications to the supplied code. (You have already modified the code to add your own debugging printfs, but I suspect you have done more than this.) In any case, you're on your own here. The resulting 454 errors - in response to the front-end client's "TEARDOWN" request - are therefore understandable, but you shouldn't be caring at all about this. The front-end client (VLC) has chosen to close the stream - which turns out to have already been closed by the proxy. Big deal. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferielbenghorbel at gmail.com Fri Dec 28 13:04:17 2012 From: ferielbenghorbel at gmail.com (feriel ben ghorbel) Date: Fri, 28 Dec 2012 22:04:17 +0100 Subject: [Live-devel] Question live555MediaServer In-Reply-To: <52868E0AA74B40C6947E3DA5EA0E888F@worksc08f920f1> References: <52868E0AA74B40C6947E3DA5EA0E888F@worksc08f920f1> Message-ID: Hi At first Thanks Warren Young and Tayeb Meftah for your quick answers. Actually and as you said Warren I used Embedding VLC plugin in a HTML Page(browser: Mozilla Firefox) using Apache2 and all is included with Ubuntu(11.10) my problem is when I reach the Html Page ; the stream ".ts" is not working and usually Mozilla Firefox crash when I run the HTML Page the code that I used in the HTML pages is Live555 Media

Flux


Play video Pause video Stop video Fullscreen Best Regards Le 27 d?cembre 2012 10:07, Tayeb Meftah a ?crit : > Salam Feriel ;) > le Live555 Media server support les flues .TS et d'autre, mais le .TS n'est > pas recomand? pour les browsers s'il include un codec MPEG2. > tu doit l'avoir en H.264 et l'audio MP3 ou AAC. > qu'elle est vos besoin svp ? > Merci. > ----- Original Message ----- From: "feriel ben ghorbel" > > To: > Sent: Wednesday, December 26, 2012 3:38 PM > Subject: [Live-devel] Question live555MediaServer > > > > Bonjour , > > Est ce que en utilisant "live555MediaServer" peut on afficher un flux > ou plusieurs flux ".ts" ? travers un browser ?? > > Cordialement > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From jshanab at smartwire.com Fri Dec 28 13:54:15 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 28 Dec 2012 21:54:15 +0000 Subject: [Live-devel] Question live555MediaServer In-Reply-To: <50DCE81B.2030609@etr-usa.com> References: <50DCE81B.2030609@etr-usa.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC22524035B@IL-BOL-EXCH01.smartwire.com> No direct support, you have to write something, a plugin, but the live555 libraries help a lot!. I use live555 libraries in a browser plugin written using the FireBreath Cross browser plugin framework. I am connecting directly to rtsp streams of security cameras as well as our own http. I also subclassed some of the live555 so that I can create HLS on the fly on my server to serve out HLS to ipad,ios, and droid, but we are moving away from it because the inherent latency is not appropriate for security cameras. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Warren Young Sent: Thursday, December 27, 2012 6:30 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Question live555MediaServer On 12/26/2012 07:38, feriel ben ghorbel wrote: > Bonjour , You're going to get more help if you use English than French. > Est ce que en utilisant "live555MediaServer" peut on afficher un flux > ou plusieurs flux ".ts" ? travers un browser ?? VLC has a browser plugin that can catch MPEG TS streams sent by Live555's media server. If you must work with native browser facilities, then no, there is no direct support right now. Browsers natively expect video to be delivered via HTTP, not RTSP. Apple browsers (desktop Safari and iOS Safari) support a variant of straight HTTP downloads called HLS, which is supported in Live555 right now, but that's not going to help you with other browsers. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From tayeb.dotnet at gmail.com Fri Dec 28 14:29:33 2012 From: tayeb.dotnet at gmail.com (Tayeb Meftah) Date: Fri, 28 Dec 2012 23:29:33 +0100 Subject: [Live-devel] Question live555MediaServer References: <52868E0AA74B40C6947E3DA5EA0E888F@worksc08f920f1> Message-ID: <9D49147F1DD4479296E2D066E40BC390@worksc08f920f1> Ferial, i recomand the following: 1. transcode the .TS to a Mpeg4 contained stream, with H.264 and AAC codecs 2. upload it to any web server 3. use JPlayer, free, open source HTML5/Flash media player with auto fallback Ross, Can Live555 Media Server serv media over http ? Thank ----- Original Message ----- From: "feriel ben ghorbel" To: "LIVE555 Streaming Media - development & use" Sent: Friday, December 28, 2012 10:04 PM Subject: Re: [Live-devel] Question live555MediaServer Hi At first Thanks Warren Young and Tayeb Meftah for your quick answers. Actually and as you said Warren I used Embedding VLC plugin in a HTML Page(browser: Mozilla Firefox) using Apache2 and all is included with Ubuntu(11.10) my problem is when I reach the Html Page ; the stream ".ts" is not working and usually Mozilla Firefox crash when I run the HTML Page the code that I used in the HTML pages is Live555 Media

Flux


Play video Pause video Stop video Fullscreen Best Regards Le 27 d?cembre 2012 10:07, Tayeb Meftah a ?crit : > Salam Feriel ;) > le Live555 Media server support les flues .TS et d'autre, mais le .TS > n'est > pas recomand? pour les browsers s'il include un codec MPEG2. > tu doit l'avoir en H.264 et l'audio MP3 ou AAC. > qu'elle est vos besoin svp ? > Merci. > ----- Original Message ----- From: "feriel ben ghorbel" > > To: > Sent: Wednesday, December 26, 2012 3:38 PM > Subject: [Live-devel] Question live555MediaServer > > > > Bonjour , > > Est ce que en utilisant "live555MediaServer" peut on afficher un flux > ou plusieurs flux ".ts" ? travers un browser ?? > > Cordialement > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Fri Dec 28 14:49:41 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Dec 2012 11:49:41 +1300 Subject: [Live-devel] Question live555MediaServer In-Reply-To: <9D49147F1DD4479296E2D066E40BC390@worksc08f920f1> References: <52868E0AA74B40C6947E3DA5EA0E888F@worksc08f920f1> <9D49147F1DD4479296E2D066E40BC390@worksc08f920f1> Message-ID: <14707151-6F98-468E-9729-0B2F9BBEA9CB@live555.com> > Ross, > Can Live555 Media Server serv media over http ? No (except for "RTSP-over-HTTP", which is not what you're talking about here). Therefore, this thread has become off-topic for this mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Dec 28 16:48:11 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 28 Dec 2012 17:48:11 -0700 Subject: [Live-devel] Question live555MediaServer In-Reply-To: References: <52868E0AA74B40C6947E3DA5EA0E888F@worksc08f920f1> Message-ID: <50DE3DCB.1080501@etr-usa.com> On 12/28/2012 14:04, feriel ben ghorbel wrote: > > Actually and as you said Warren I used Embedding VLC plugin in a > HTML Page(browser: Mozilla Firefox) using Apache2 and all is > included with Ubuntu(11.10) > my problem is when I reach the Html Page ; the stream ".ts" is not > working and usually Mozilla Firefox crash when I run the HTML Page VLC went through a period of a few years where the browser plugins didn't get a lot of attention. Things seem to be getting better in recent releases, but since you're using an older version of Ubuntu, perhaps upgrading will help. If upgrading doesn't help, it may be that the Linux plugins remain brittle, while the Windows and Mac plugins have been fixed. That sort of situation is common with VLC...the more popular platforms often get fixes that don't get reflected into the versions for less popular platforms. This is because so much of the internal codebase is fragmented into platform-specific parts, each maintained by different groups of developers. Anyway, VLC problems aren't on topic here, so if you continue to have problems with it, you should ask on the VLC mailing lists. As a broader test to discern whether your problem is with VLC or Live555, if the browser plugin works on Windows but not Linux, you can be pretty sure it's a problem with VLC. And in this particular case, I think you'll find that the problem is with VLC. From eric at sound4.biz Mon Dec 31 02:22:32 2012 From: eric at sound4.biz (Eric HEURTEL) Date: Mon, 31 Dec 2012 11:22:32 +0100 Subject: [Live-devel] RTSP/1.0 454 Session Not Found In-Reply-To: References: Message-ID: <50E16768.4030205@sound4.biz> Hi, >>> At some point my RTSP source answers with error code "RTSP/1.0 454 Session >>> Not Found" to RTSP commands but seems not being handled by RTSP client. >>> Why? Is this an invalid error code? >> Yes. It is usually returned by the server when the client attempts to >> access a stream using an invalid RTSP 'session id' string. That shouldn't >> be happening (with our RTSP client or proxy code), so I'm curious as to why >> you're getting this error. (See below.) > There you go. I had to "play" a little bit with it before the error occurs > so the log is pretty big (also I added some printfs myself) but the whole > sequence is there and you get the error at the end. > I'm curious of how would I have to reset/close the connection so it could > be reopened by the client to stablish a new session. If the error occurs, > at least I would like the system to recover even if it is with a new > session. Is this possible? I had a problem which may be relative to this one and may help here : RTSP client adds a '/' at the end of baseURL and cannot be used for reconnection else a 404 Session Not Found occurs. By "Reconnection" I mean calling sendDescribeCommand() after a deconnection, for an automatic reconnection, without destroying the RTSP client object. As a workaround I had to save the original URL in an additional field for this to work. I'm talking of a relatively old Live version (LIVE555 2012.09.12) and have not checked if this has been changed since. Cheers E. HEURTEL -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at sound4.biz Mon Dec 31 09:19:23 2012 From: eric at sound4.biz (Eric HEURTEL) Date: Mon, 31 Dec 2012 18:19:23 +0100 Subject: [Live-devel] SDP attribute extension In-Reply-To: References: Message-ID: <50E1C91B.7030004@sound4.biz> Hi, I have to deal with application-specific SDP attributes (a=my_attribute:value). I have my own subclass of MediaSubsession. I was wondering if parsing of subsession description lines (c=, b=, a=rtpmap... ) could be done in a virtual new method (ie MediaSubsession::parseSDPline()) that could be overloaded, instead of being hardcoded in MediaSession::initializeWithSDP(). What do you think ? Do you see another nice way to deal with extra SDP attributes ? Best wishes to everybody E. HEURTEL -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 31 11:01:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jan 2013 08:01:26 +1300 Subject: [Live-devel] SDP attribute extension In-Reply-To: <50E1C91B.7030004@sound4.biz> References: <50E1C91B.7030004@sound4.biz> Message-ID: <6656CB66-69E6-4C9E-8FFD-942FAE07CCCA@live555.com> > I have to deal with application-specific SDP attributes (a=my_attribute:value). I have my own subclass of MediaSubsession. > I was wondering if parsing of subsession description lines (c=, b=, a=rtpmap... ) could be done in a virtual new method (ie MediaSubsession::parseSDPline()) that could be overloaded, instead of being hardcoded in MediaSession::initializeWithSDP(). > What do you think ? This is a possibility, but I consider changes like this - whose sole purpose is to support non-standard protocol extensions - to be low priority. What 'application-specific SDP attributes' do you have in mind? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: