From temp2010 at forren.org Fri Mar 1 04:46:35 2013 From: temp2010 at forren.org (temp2010 at forren.org) Date: Fri, 1 Mar 2013 07:46:35 -0500 Subject: [Live-devel] Question on streams in Windows In-Reply-To: References: Message-ID: Chris, I've gotten a very similar pipe thing working. Ross was invaluable in helping. Here are two points you may need to recall, to finally get it working properly. This advice relates to using H.264. It may only partially relate to your application. 1) You must make sure that you're sending both an SPS and a PPS NAL to Live555 *after* VLC tries to connect. My initial code wasn't doing this. My stream origination used an H.264 encoder that sends these two NAL records out first, and it was always running. So when VLC came along, those two NAL records had long since passed. I had to use tricks to send them again *in response* to the VLC connecting. Aside from Ross knowing it off the top, before hearing his advice I located this issue by tracing through the Live555 code and discovering it's refusal to continue without having seen those two NAL records. 2) With the above, I got video, but it was very choppy. Again, Ross was correct in suggesting it had to do with providing a steady stream of input. But how to do so was less obvious. The culprit was partially a lack of horsepower on one machine to do the full job with the debug-compiled code. The other culprit was needing to provide a large enough amount of memory to the pipe on creation. Good luck! On Thu, Feb 28, 2013 at 9:14 PM, Ross Finlayson wrote: > As far as Windows developers who use gmail...I can understand the > anti-windows sentiment, but I don't know what you have against gmail... > > > This is explained clearly in the FAQ (that everyone was asked to read > before posting to the mailing list :-) > > > And I code in Windows because I'm paid too...and I know *exactly* how to > do asynchronous, non-blocking file IO in windows. Be careful with the word > "impossible." ;-) > > > The issue with doing asynchronous file reading in Windows is that - in > Windows - extra work needs to be done to handle the 'data is available on > the open file' event. In other OSs, open files are sockets that can be > passed to "select()", as we do in the the implementation of > "BasicTaskScheduler" (the "TaskScheduler" subclass that we provide with the > supplied code). In (at least some versions of) Windows, however, open > files are not "select()"able sockets. Therefore, to do asynchronous file > reads in Windows, you would need to write your own subclass of > "TaskScheduler" (that reimplements the "setBackgroundHandling()" virtual > function). > > 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 cvanbrederode at gmail.com Fri Mar 1 13:13:10 2013 From: cvanbrederode at gmail.com (Chris Van Brederode) Date: Fri, 1 Mar 2013 16:13:10 -0500 Subject: [Live-devel] Question on streams in Windows In-Reply-To: References: Message-ID: Okay, I did some more testing of the problem. Step one: I set the max_key_interval in the encoder to 25 (one per second and current fps). Xvid sends a Bitstream header with each keyframe, so the streamer shouldn't have to wait for more than a second max for that information. Step two: I wrote a tiny program that does nothing but open the pipe and read data from it, using fopen and fread. That program was able to connect and pull data from the pipe, so I know the pipe is working. At this point I switch back to the streamer program and tried again. Still no video in VLC. Step three: I built openRTSP and tried to connect to the stream. I got what seems to be a good conversation between it and the streamer, which ends with "Started playing session" and "Receiving streamed data..." But the video-MP4V-ES-1 file that it creates is only 58 bytes long. As openRTSP was connecting to the streamer, I watched it in Process Explorer, and I saw that upon openRTSP connecting it was opening the pipe. But once openRTSP said "Started playing session", it closes the pipe. (I'll attach the output from openRTSP below) What can be going on in the stream that will cause the live555 library to close the file (which to what I can see only happens in the ~ByteStreamFileSource()) as it starts to stream, without error messages? Chris Van Brederode Software Engineer International Logistics Systems, Inc. http://www.intlogys.com cvanbrederode at intlogsys.com -------------------------------------------------- Output from openRTSP -------------------------------------------------- Opening connection to 172.16.3.53, port 8554... ...remote connection opened Sending request: OPTIONS rtsp://172.16.3.53:8554/test RTSP/1.0 CSeq: 2 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Fri, Mar 01 2013 20:37:57 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://172.16.3.53:8554/test RTSP/1.0 CSeq: 3 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15) Accept: application/sdp Received 659 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Fri, Mar 01 2013 20:38:04 GMT Content-Base: rtsp://172.16.3.53:8554/test/ Content-Type: application/sdp Content-Length: 497 v=0 o=- 1362170268711363 1 IN IP4 172.16.3.53 s=ECP ETA Streaming server i=test t=0 0 a=tool:LIVE555 Streaming Media v2013.01.15 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:ECP ETA Streaming server a=x-qt-text-inf:test m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=244;config=000001B0F4000001B509000001000000012008CA0D8800CE18A021E0A1C1000001B2446976583530336231333933000001B25876694430303634 a=control:track1 Opened URL "rtsp://172.16.3.53:8554/test", returning a SDP description: v=0 o=- 1362170268711363 1 IN IP4 172.16.3.53 s=ECP ETA Streaming server i=test t=0 0 a=tool:LIVE555 Streaming Media v2013.01.15 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:ECP ETA Streaming server a=x-qt-text-inf:test m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=244;config=000001B0F4000001B509000001000000012008CA0D8800CE18A021E0A1C1000001B2446976583530336231333933000001B25876694430303634 a=control:track1 Created receiver for "video/MP4V-ES" subsession (client ports 50586-50587) Sending request: SETUP rtsp://172.16.3.53:8554/test/track1 RTSP/1.0 CSeq: 4 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15) Transport: RTP/AVP;unicast;client_port=50586-50587 Received 201 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Fri, Mar 01 2013 20:38:04 GMT Transport: RTP/AVP;unicast;destination=172.16.3.53;source=172.16.3.53;client_port=50586-50587;server_port=6970-6971 Session: 5FBE8E99 Setup "video/MP4V-ES" subsession (client ports 50586-50587) Created output file: "video-MP4V-ES-1" Sending request: PLAY rtsp://172.16.3.53:8554/test/ RTSP/1.0 CSeq: 5 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15) Session: 5FBE8E99 Range: npt=0.000- Received 183 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Fri, Mar 01 2013 20:38:04 GMT Range: npt=0.000- Session: 5FBE8E99 RTP-Info: url=rtsp:// 172.16.3.53:8554/test/track1;seq=16594;rtptime=2519251020 Started playing session Receiving streamed data... ^C ---------------------------------------------------------- End of output ---------------------------------------------------------- On Fri, Mar 1, 2013 at 7:46 AM, temp2010 at forren.org wrote: > Chris, > > I've gotten a very similar pipe thing working. Ross was invaluable in > helping. Here are two points you may need to recall, to finally get it > working properly. > > This advice relates to using H.264. It may only partially relate to your > application. > > 1) You must make sure that you're sending both an SPS and a PPS NAL to > Live555 *after* VLC tries to connect. My initial code wasn't doing this. > My stream origination used an H.264 encoder that sends these two NAL > records out first, and it was always running. So when VLC came along, > those two NAL records had long since passed. I had to use tricks to send > them again *in response* to the VLC connecting. Aside from Ross knowing it > off the top, before hearing his advice I located this issue by tracing > through the Live555 code and discovering it's refusal to continue without > having seen those two NAL records. > > 2) With the above, I got video, but it was very choppy. Again, Ross was > correct in suggesting it had to do with providing a steady stream of input. > But how to do so was less obvious. The culprit was partially a lack of > horsepower on one machine to do the full job with the debug-compiled code. > The other culprit was needing to provide a large enough amount of memory > to the pipe on creation. > > Good luck! > > On Thu, Feb 28, 2013 at 9:14 PM, Ross Finlayson wrote: > >> As far as Windows developers who use gmail...I can understand the >> anti-windows sentiment, but I don't know what you have against gmail... >> >> >> This is explained clearly in the FAQ (that everyone was asked to read >> before posting to the mailing list :-) >> >> >> And I code in Windows because I'm paid too...and I know *exactly* how to >> do asynchronous, non-blocking file IO in windows. Be careful with the word >> "impossible." ;-) >> >> >> The issue with doing asynchronous file reading in Windows is that - in >> Windows - extra work needs to be done to handle the 'data is available on >> the open file' event. In other OSs, open files are sockets that can be >> passed to "select()", as we do in the the implementation of >> "BasicTaskScheduler" (the "TaskScheduler" subclass that we provide with the >> supplied code). In (at least some versions of) Windows, however, open >> files are not "select()"able sockets. Therefore, to do asynchronous file >> reads in Windows, you would need to write your own subclass of >> "TaskScheduler" (that reimplements the "setBackgroundHandling()" virtual >> function). >> >> 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 >> >> > > _______________________________________________ > 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 raghav at fossilshale.com Sat Mar 2 04:31:07 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Sat, 02 Mar 2013 05:31:07 -0700 Subject: [Live-devel] Multiple Channel Issue Message-ID: <20130302053107.24734i9vapwyzgnf@mail.fossilshale.com> Hi Ross, I am Trying to streaming Video data from Camera it has multiple channels like url://.../stream1 ,url://...stream2 soon.When i opened first channel it was working fine when i try to open second channel it gets slow down i check the bitrate it is not what we set.but there is no Frame loss am using vlc as client. Rgds, Raghav. From lukasz.wychrystenko at novamedia.pl Mon Mar 4 03:57:43 2013 From: lukasz.wychrystenko at novamedia.pl (=?UTF-8?B?xYF1a2FzeiBXeWNocnlzdGVua28=?=) Date: Mon, 04 Mar 2013 12:57:43 +0100 Subject: [Live-devel] unique source file format for rtspserver Message-ID: <51348C37.9050500@novamedia.pl> Hello everyone I want to build rtspserver for unique file format. Each file have recorded video streams (mpeg2 or h264 sometime with audio acc, raw frames with in, variable fps - usually 4-16 ) from multiple sources. It is in 5 minute chunks and chunks are located in separate dirs. Of course i know how to extract any data from that file. What I want to do in detail: - rtsp server that can access concrete stream source eg: rtsp://localhost/cam1.spd....cam10.sdp - services should have 'trick play' - i have all necessary data in that unique files but i don't know how to create specific index file 'tsx'(jet - maybe speed will not by issue here) or do I really need it? - chunks can be removed - how to handle that situation in live555 - normally inotify and some thread that will watch on dir should do the trick however i had bad experience trying to use live555 rtsp client in MT application. - each frame in that 'magic' file have some specific text data attached - is there a way to transfer it in 'rtsp'? What it most forward way to do it, and pls be verbose? I was playing with MPEG1or2FileServerDemux, got confused by ByteStreamMultiFileSource(do I need ByteStreamFileSource?) and now I'm only sure that I need ServerMediaSubsession - I'm missing here the whole picture? thx To Moderator: Due to some issue with vpn I was unable to send this msg from my company account and I sent it from my private account - lukasz.wychrystenko at gmail.com. Pls delete msg from my private account and forget that i send this message twice :) From finlayson at live555.com Mon Mar 4 09:50:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Mar 2013 06:50:46 +1300 Subject: [Live-devel] unique source file format for rtspserver In-Reply-To: <51348C37.9050500@novamedia.pl> References: <51348C37.9050500@novamedia.pl> Message-ID: <01BCDDF2-40B1-4D33-B0BC-75CD76664890@live555.com> > I want to build rtspserver for unique file format. You can do this, but instead you should consider using a *standard* file format - not a file format that only you understand. In particular, if you chose to use the "Matroska" file format, you would find that we already support streaming from this file format (including Matroska files that contain H.264 video and AAC audio). Also, standard media player applications (such as VLC) would be able to play the file. > Each file have recorded video streams (mpeg2 or h264 sometime with > audio acc, raw frames with in, variable fps - usually 4-16 ) from > multiple sources. It is in 5 minute chunks and chunks are located in > separate dirs. Of course i know how to extract any data from that > file. The most important feature that you need in your file format - if you want to be able to stream from it properly - is the ability to generate an accurate 'presentation time' for each frame. In particular, you would need a subclass of "FramedSource" (that you would write) - one for video; one for audio - that delivers one frame at a time from your input file(s), with each frame having an accurate 'presentation time'. (This presentation time should be aligned with 'wall clock time' - the times that you would get by calling "gettimeofday()". Then, you will need your own subclass of "OnDemandServerMediaSubsession" for each codec that you wish to stream from your custom file format. See http://www.live555.com/liveMedia/faq.html#liveInput-unicast Unfortunately, because your input file format is something that only you plan to support, I don't have time on this mailing list to help you with the details of this. > - services should have 'trick play' See http://www.live555.com/liveMedia/faq.html#trick-mode > i had bad experience trying to use live555 rtsp client > in MT application. See http://www.live555.com/liveMedia/faq.html#threads !!! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From guanxiansun at gmail.com Mon Mar 4 01:50:38 2013 From: guanxiansun at gmail.com (Guan Xsun) Date: Mon, 4 Mar 2013 17:50:38 +0800 Subject: [Live-devel] Can I use live555 write audio/video conference media server Message-ID: HI,Ross. How are you ! Can I use live555 to write audio/video conference media server. I design my conference media server will receive RTP media(audio) from clients, and then mix them then send mixer audio to every client. Can I use live555 write this media server? Best Regards! Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Tue Mar 5 03:19:50 2013 From: ashfaque at iwavesystems.com (Ashfaque) Date: Tue, 5 Mar 2013 16:49:50 +0530 Subject: [Live-devel] Adding Audio Stream Session Message-ID: Hi Ross, Been using Live555 for Video streaming on multiple platforms, used on Linux, iOS and now ported to WinCE7. Video streaming works like a charm. Now I want to add the audio stream in the media session. As a test I want stream a mp3 file with video stream (H.264 video data generated by a encoder source). I am assuming to use MP3AudioFileServerMediaSubsession as audio subsession and add it to ServerMediaSession. Below is my code: const Port rtpPort(rtpPortNum); const Port rtcpPort(rtcpPortNum); Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl); rtpGroupsock.multicastSendOnly(); // we're a SSM source Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); rtcpGroupsock.multicastSendOnly(); // we're a SSM source // Create a 'H264 Video RTP' sink from the RTP 'groupsock': OutPacketBuffer::maxSize = 500000; videoSink = H264VideoRTPSink::createNew(*env, &rtpGroupsock, 96); // Create (and start) a 'RTCP instance' for this RTP sink: const unsigned estimatedSessionBandwidth = 500; // in kbps; for RTCP b/w share const unsigned maxCNAMElen = 100; unsigned char CNAME[maxCNAMElen+1]; gethostname((char*)CNAME, maxCNAMElen); CNAME[maxCNAMElen] = '\0'; // just in case RTCPInstance* rtcp = RTCPInstance::createNew(*env, &rtcpGroupsock, estimatedSessionBandwidth, CNAME, videoSink, NULL /* we're a server */, True /* we're a SSM source */); // Note: This starts RTCP running automatically RTSPServer* rtspServer = RTSPServer::createNew(*env, 8554); if (rtspServer == NULL) { *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n"; exit(1); } ServerMediaSession* sms = ServerMediaSession::createNew(*env, "testStream", inputFileName, "Session streamed by \"testH264VideoStreamer\"", True /*SSM*/); ServerMediaSubsession* VideoSession = NULL; VideoSession = PassiveServerMediaSubsession::createNew(*videoSink, rtcp); sms->addSubsession(VideoSession); //rtspServer->addServerMediaSession(sms); ServerMediaSubsession* AudioSession = NULL; AudioSession = MP3AudioFileServerMediaSubsession ::createNew(*env, inputaudioFileName, reuseFirstSource, true, NULL); sms->addSubsession(AudioSession); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); Please let me know whether this is the correct method of adding audio stream with video. I don?t have a audio codec source, hence want to test with MP3 file only. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi.tal at connesta.com Tue Mar 5 03:57:07 2013 From: avi.tal at connesta.com (Avi Tal) Date: Tue, 5 Mar 2013 13:57:07 +0200 Subject: [Live-devel] LIVE555 Media Server source code Message-ID: <009701ce1998$9044bb70$b0ce3250$@connesta.com> Dear friends, How can I download the LIVE555 Media Server source code for Windows 7 32 bit? Thanks, Avi Tal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 5 07:02:20 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Mar 2013 04:02:20 +1300 Subject: [Live-devel] LIVE555 Media Server source code In-Reply-To: <009701ce1998$9044bb70$b0ce3250$@connesta.com> References: <009701ce1998$9044bb70$b0ce3250$@connesta.com> Message-ID: <33801617-398E-43F8-BCA6-B9E61349C529@live555.com> > How can I download the LIVE555 Media Server source code for Windows 7 32 bit? See our online documentation http://www.live555.com/mediaServer/#downloading under "Source code". (The source code, like all of our application source code, is multi-platform.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 5 07:11:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Mar 2013 04:11:35 +1300 Subject: [Live-devel] Adding Audio Stream Session In-Reply-To: References: Message-ID: <7AAA7B7D-FE1F-471F-ABB5-AB234E33D4FF@live555.com> > Been using Live555 for Video streaming on multiple platforms, used on Linux, iOS and now ported to WinCE7. Video streaming works like a charm. > Now I want to add the audio stream in the media session. As a test I want stream a mp3 file with video stream (H.264 video data generated by a encoder source). > I am assuming to use MP3AudioFileServerMediaSubsession as audio subsession No, because that class - being a subclass of "OnDemandServerMediaSubsession" - is used only for *unicast* streaming, and you are instead doing *multicast* streaming. Instead, you should be using the code from the "testMP3Streamer" demo application as a model. Therefore, you should be adding - to the "RTSPServer" object - another "PassiveServerMediaSubsession". You *must*, however, use different port numbers (for RTP and RTCP), different "Groupsock" objects, and, of course, a different "RTPSink" (subclass) object (it should be a "MPEG1or2AudioRTPSink"). As with your video stream, you will call "startPlaying()" on this "MPEG1or2AudioRTPSink" object, before entering the event loop. You can, however, use the same IP multicast address - i.e., "destinationAddress" - for both video and audio, but you must use a different port number pair (RTP,RTCP) for audio. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinodh.g.us at gmail.com Tue Mar 5 04:50:47 2013 From: vinodh.g.us at gmail.com (Vinodh Kumar) Date: Tue, 5 Mar 2013 18:20:47 +0530 Subject: [Live-devel] Query Regarding Live555 not thread safe. Message-ID: Hi There, I have a *requirement* like stream a video from my iPhone(what I am currently watching) to many other clients devices, I have used code from *live555MediaServer*.cpp for starting the live555server, Since my iOS application freezes if I start the live555server in main thread, so I start the live555MediaServer in background thread, know I need to play and stream a video which is in my application bundle. I have a open source *ffmpeg* video player for playing the video from live555server using RTSP. Since I have started the live555server in background thread, my *ffmpeg*videoplayer plays the video in main thread, how can I solve this problem? Or any other way of solving my *requirement*. Regards, Vinodh -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvanbrederode at gmail.com Tue Mar 5 13:17:15 2013 From: cvanbrederode at gmail.com (Chris Van Brederode) Date: Tue, 5 Mar 2013 16:17:15 -0500 Subject: [Live-devel] Tracked down the problem with latency Message-ID: I believe I have tracked down the problem with latency and slow connections: When the video feed (from a 3D rendering engine) is more or less static, the data size of frames from XVID is very small, on the order of 100-200 bytes per frame, sometimes down to a minimum of 57 bytes per frame, for many frames in a row. If I make the video non-static (by turning/moving the camera), the average size of the frames jumps to several thousand bytes each. I have far less problems connecting clients when the camera is moving, and the latency is on the order of a few seconds, instead of 30 seconds. If I understand things correctly, getNextFrame is being called with maxSize set to the available space in the buffer. Since MPEG4VideoFileServerMediaSubsession does not specify preferredFrameSize on creation of its ByteSTreamFileSource, the file reads (on Windows) will block until maxSize bytes have been read, causing the long stream startups and high latency. Is there any recourse for this other than overloading MPEG4VideoFileMediaSubsession (with a version that sets preferredFrameSize to a lower value)? What kind of problems can crop up if I set preferredFrameSize to something on the order of 200 bytes? Chris V. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 5 16:08:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Mar 2013 13:08:17 +1300 Subject: [Live-devel] Tracked down the problem with latency In-Reply-To: References: Message-ID: <9B8C3C6F-1103-4B9B-88C8-A27490CAA134@live555.com> > What kind of problems can crop up if I set preferredFrameSize to something on the order of 200 bytes? This might not work, because you are reading/parsing a byte stream source. Our stream parsing code might not be able to handle reads that small. But a much better solution would be to have your input source class deliver *discrete* MPEG-4 video frames - one at a time - directly to the server, instead of delivering an arbitrary-sized byte stream (via a pipe). If you do this, your "OnDemandServerMediaSubsession" subclass will need to use a "MPEG4VideoStreamDiscreteFramer" (instead of a "MPEG4VideoStreamFramer"). But your latency should be lowered considerably (and your code will be much more efficient). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Wed Mar 6 04:58:01 2013 From: zanglan at yahoo.com (Lan Zang) Date: Wed, 6 Mar 2013 20:58:01 +0800 (CST) Subject: [Live-devel] Nice cleanup when end session Message-ID: <1362574681.66069.YahooMailNeo@web15808.mail.cnb.yahoo.com> Hi, ? ? I am trying to end a RTP session using SimpleRTPSource plus MPEG2TransportUDPServerMediaSubsession, as it is used in?testOnDemandRTSPServer. When I decided to end this session, I met a problem.? ? ? I tried to use?RTSPClientSession::reclaimStreamStates() and? RTSPClientConnection::closeSockets(). But the socket created by SimpleRTPSource is just not closed. How can I close this socket and also cleanup gracefully, without exiting the process? Regards, Lan Zang(Sander) ? From michel.promonet at thalesgroup.com Thu Mar 7 06:53:26 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 7 Mar 2013 15:53:26 +0100 Subject: [Live-devel] lost fix about SEGV processing RTSP GET_PARAMETER Message-ID: <25090_1362668009_5138A9E8_25090_10_1_1BE8971B6CFF3A4F97AF4011882AA25501560CDE2302@THSONEA01CMS01P.one.grp> Hi Ross, The fix you included in release 2013.02.11 disappear in release 2013.02.27. Is it possible to re-include this fix in RTSPClient.cpp ? Thanks & Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Mar 7 15:02:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Mar 2013 12:02:05 +1300 Subject: [Live-devel] lost fix about SEGV processing RTSP GET_PARAMETER In-Reply-To: <25090_1362668009_5138A9E8_25090_10_1_1BE8971B6CFF3A4F97AF4011882AA25501560CDE2302@THSONEA01CMS01P.one.grp> References: <25090_1362668009_5138A9E8_25090_10_1_1BE8971B6CFF3A4F97AF4011882AA25501560CDE2302@THSONEA01CMS01P.one.grp> Message-ID: > The fix you included in release 2013.02.11 disappear in release 2013.02.27. Oops - sorry about that; my mistake. It's now been restored in the latest version (2012.03.07) of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Mar 7 15:03:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Mar 2013 12:03:17 +1300 Subject: [Live-devel] live555 server and webm issue In-Reply-To: <512F7701.1080705@celeos.eu> References: <512F7701.1080705@celeos.eu> Message-ID: <84D46146-27BA-4E3C-9BFC-75CE1FCACE69@live555.com> > So I think it is a bug in the server. FYI, this bug should be fixed in the latest release (2012.03.07) of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi.tal at connesta.com Fri Mar 8 14:03:11 2013 From: avi.tal at connesta.com (Avi Tal) Date: Sat, 9 Mar 2013 00:03:11 +0200 Subject: [Live-devel] LIVE555 Media Server source code In-Reply-To: <33801617-398E-43F8-BCA6-B9E61349C529@live555.com> References: <009701ce1998$9044bb70$b0ce3250$@connesta.com> <33801617-398E-43F8-BCA6-B9E61349C529@live555.com> Message-ID: <001e01ce1c48$bc7636d0$3562a470$@connesta.com> Dear Ross Finlayson, Thank you for your reply. Where can I find a LIVE555 Media Server Visual Studio project for Windows 7 32bit (or something close to it)? Thanks, Avi Tal. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, March 05, 2013 5:02 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] LIVE555 Media Server source code How can I download the LIVE555 Media Server source code for Windows 7 32 bit? See our online documentation http://www.live555.com/mediaServer/#downloading under "Source code". (The source code, like all of our application source code, is multi-platform.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sun Mar 10 11:46:56 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Sun, 10 Mar 2013 18:46:56 +0000 Subject: [Live-devel] Access Violation in ReorderingPacetBuffer::freePacket Message-ID: <615FD77639372542BF647F5EBAA2DBC225261E7F@IL-BOL-EXCH01.smartwire.com> I have a new source(new brand of camera) that is somehow causing my application to crash. The crash is similar to one I had when I switched over to async interface in that I am seeing that an access violation occurs on an otherwise complete bPacket on the fBuf pointer that is the magic value 0xdddddddd Which is an indicator that this memory has already been deleted. It is allocated in the CTOR in the MultiFramedRtpSource (without check for failure) ... fBuf(new unsigned char[MaxPacketSize]) ... The special value indicates to me this memory is deleted, not failed to allocate. This happens after 30 min to an hour of failed connects and reconnects so I am thinking I am not handling something correctly and occasionally losing a race. I need this code to be robust. It is ok if this camera fails, but it needs to not crash the app. (I cannot "catch" and access violation :)) My live555 code is from 2012.2.29 Kinda Old, could that be the problem? Should I start with upgrading live555? Do we know if there has been changes in this area? Or... Can someone suggest how to debug this. I am looking with memory tools and of course, it hasn't failed when run inside the tool yet. My code is very much like the openRTSP example. It appears as if the command to get OPTIONS does not return a value but the event loop is started already and the teardown tries to delete the buffer that never got any data. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Sun Mar 10 12:23:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 10 Mar 2013 15:23:35 -0400 Subject: [Live-devel] Access Violation in ReorderingPacetBuffer::freePacket In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225261E7F@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225261E7F@IL-BOL-EXCH01.smartwire.com> Message-ID: > My live555 code is from 2012.2.29 > Kinda Old, could that be the problem? Should I start with upgrading live555? OF COURSE you should start by upgrading! EVERYONE who is having problems with the "LIVE555 Streaming Media" code should check to see whether they are using an up-to-date version of the code - and, if not, upgrade. > Do we know if there has been changes in this area? I don't know what "this area" is, but looking at the changelog, I see that since 2012.02.29, there have been something like 72 revisions of the code, with about 500 lines of changelog text describing them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Mon Mar 11 06:27:03 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Mon, 11 Mar 2013 13:27:03 +0000 Subject: [Live-devel] Breaking change Message-ID: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> I am updating live555 from 2012.2.29 to 2013.03.07 and found a change in Boolean.hh that breaks my build. From reading the changelog, I think this is recent. The line " #define Boolean bool " Overwrites a class name in boost (move.cpp) where there is a class with the name Boolean In the past I have had this collide with libavcodec. So I end up modifying this file every time I upgrade. Is the problem a tough one to fix for live555? too many years of too many people doing their own thing. (amazing for only two states how many conflicting definitions there are) Is there a long term solution? Take it out of preprocessing with a typedef? Or *cough* rework live555 to have it's own bool type and one header to map that to all the platforms? I just remove the second part of the condition so it disables the first case (lines 20-22), But I have not used Borland for years. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Mon Mar 11 07:22:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Mar 2013 10:22:18 -0400 Subject: [Live-devel] Breaking change In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> Message-ID: <6154227A-59A1-402C-AD17-1C51B568F14D@live555.com> > I am updating live555 from 2012.2.29 to 2013.03.07 and found a change in Boolean.hh that breaks my build. From reading the changelog, I think this is recent. > > The line > ? #define Boolean bool ? No, it's *not* recent; it's almost 9 months old! From the changelog: 2012.06.12: - Updated "UsageEnvironment/include/Boolean.hh" to use the 'bool' type defined for "MSVC++ 8.0, Visual Studio 2005 and higher", if that development environment is being used. Also, fixed a few places in the code where we were using boolean types incorrectly. (Thanks to Nikolai Vorontsov for these suggestions.) > Overwrites a class name in boost (move.cpp) where there is a class with the name Boolean Here is the current contents of "UsageEnvironment/include/Boolean.hh". Feel free to propose a change that you think works for you (and is not likely to break for everyone else, for which this existing code works!): #if defined(__BORLANDC__) || (defined(_MSC_VER) && _MSC_VER >= 1400) // MSVC++ 8.0, Visual Studio 2005 and higher #define Boolean bool #define False false #define True true #else typedef unsigned char Boolean; #ifndef __MSHTML_LIBRARY_DEFINED__ #ifndef False const Boolean False = 0; #endif #ifndef True const Boolean True = 1; #endif #endif #endif > In the past I have had this collide with libavcodec. Huh? Why are you compiling "libavcodec" code with our header files? > So I end up modifying this file every time I upgrade. If you modifiy the supplied code, you can expect *no* support on this mailing list! > Is the problem a tough one to fix for live555? As I noted above, the current "Boolean.hh" has been there for almost 9 months. Noone else has complained in that time; this (IMHO) calls into question the legitimacy of your complaint. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolai.vorontsov at quadrox.be Mon Mar 11 07:28:56 2013 From: nikolai.vorontsov at quadrox.be (Nikolai Vorontsov) Date: Mon, 11 Mar 2013 15:28:56 +0100 Subject: [Live-devel] Breaking change In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> Message-ID: <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0E@s-giant.herent.quadrox.be> Hi Ross, may be the easiest solution for such issue is to wrap all Live555 functionality in a namespace? And place "using namespace Live555;" somewhere in it's header. Then people that uses boost (or any other library that clashes with your lib by internal names/types) should not have a problem... Nikolai ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeff Shanab Sent: Monday, March 11, 2013 2:27 PM To: live-devel at lists.live555.com Subject: [Live-devel] Breaking change I am updating live555 from 2012.2.29 to 2013.03.07 and found a change in Boolean.hh that breaks my build. From reading the changelog, I think this is recent. The line " #define Boolean bool " Overwrites a class name in boost (move.cpp) where there is a class with the name Boolean In the past I have had this collide with libavcodec. So I end up modifying this file every time I upgrade. Is the problem a tough one to fix for live555? too many years of too many people doing their own thing. (amazing for only two states how many conflicting definitions there are) Is there a long term solution? Take it out of preprocessing with a typedef? Or *cough* rework live555 to have it's own bool type and one header to map that to all the platforms? I just remove the second part of the condition so it disables the first case (lines 20-22), But I have not used Borland for years. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From nikolai.vorontsov at quadrox.be Mon Mar 11 08:02:05 2013 From: nikolai.vorontsov at quadrox.be (Nikolai Vorontsov) Date: Mon, 11 Mar 2013 16:02:05 +0100 Subject: [Live-devel] Breaking change In-Reply-To: <6154227A-59A1-402C-AD17-1C51B568F14D@live555.com> References: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> <6154227A-59A1-402C-AD17-1C51B568F14D@live555.com> Message-ID: <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0F@s-giant.herent.quadrox.be> Hi Ross & Jeff, first of all in Boost 1.49 I didn't find a Boolean class. May be it's in a newer version defined. Second, Ross - the issue here is that someone might need to have to include both Live555 and other library (boost or libvc) headers to his _single_ source file. If other library declares it's own Boolean type (class) then this one will have a name conflict. The exact solution for that problem is namespaces. If you place all your library names to a separate namespace, then you become independent from other declarations. To simplify migration for existing code, you might add "using namespace" statement and then it should be completely transparent for customers. The person with clashes might need to add specifies like boost:: or live555:: before Boolean object declaration to resolve ambiguity. Also, if some of supported compilers doesn't use namespaces (well, may be some embedded one) - then you might need to use conditional compilation as you did over 9000 times before ;-) Nikolai ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, March 11, 2013 3:22 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Breaking change I am updating live555 from 2012.2.29 to 2013.03.07 and found a change in Boolean.hh that breaks my build. From reading the changelog, I think this is recent. The line " #define Boolean bool " No, it's *not* recent; it's almost 9 months old! From the changelog: 2012.06.12: - Updated "UsageEnvironment/include/Boolean.hh" to use the 'bool' type defined for "MSVC++ 8.0, Visual Studio 2005 and higher", if that development environment is being used. Also, fixed a few places in the code where we were using boolean types incorrectly. (Thanks to Nikolai Vorontsov for these suggestions.) Overwrites a class name in boost (move.cpp) where there is a class with the name Boolean Here is the current contents of "UsageEnvironment/include/Boolean.hh". Feel free to propose a change that you think works for you (and is not likely to break for everyone else, for which this existing code works!): #if defined(__BORLANDC__) || (defined(_MSC_VER) && _MSC_VER >= 1400) // MSVC++ 8.0, Visual Studio 2005 and higher #define Boolean bool #define False false #define True true #else typedef unsigned char Boolean; #ifndef __MSHTML_LIBRARY_DEFINED__ #ifndef False const Boolean False = 0; #endif #ifndef True const Boolean True = 1; #endif #endif #endif In the past I have had this collide with libavcodec. Huh? Why are you compiling "libavcodec" code with our header files? So I end up modifying this file every time I upgrade. If you modifiy the supplied code, you can expect *no* support on this mailing list! Is the problem a tough one to fix for live555? As I noted above, the current "Boolean.hh" has been there for almost 9 months. Noone else has complained in that time; this (IMHO) calls into question the legitimacy of your complaint. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 11 08:04:47 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Mar 2013 11:04:47 -0400 Subject: [Live-devel] Breaking change In-Reply-To: <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0E@s-giant.herent.quadrox.be> References: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0E@s-giant.herent.quadrox.be> Message-ID: <8F0C76CF-D34F-4F2F-903C-2A6F2CDE1EE7@live555.com> > may be the easiest solution for such issue is to wrap all Live555 functionality in a namespace? And place "using namespace Live555;" somewhere in it's header. Yes, that's certainly a possibility for the future. To date, however, I've avoided using C++ namespaces, because I don't want to risk breaking older compilers that might not support them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvanbrederode at gmail.com Mon Mar 11 08:14:49 2013 From: cvanbrederode at gmail.com (Chris Van Brederode) Date: Mon, 11 Mar 2013 11:14:49 -0400 Subject: [Live-devel] Breaking change In-Reply-To: <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0F@s-giant.herent.quadrox.be> References: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> <6154227A-59A1-402C-AD17-1C51B568F14D@live555.com> <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0F@s-giant.herent.quadrox.be> Message-ID: On Mon, Mar 11, 2013 at 11:02 AM, Nikolai Vorontsov < nikolai.vorontsov at quadrox.be> wrote: <--snip--> ** > Also, if some of supported compilers doesn't use namespaces (well, may be > some embedded one) - then you might need to use conditional compilation as > you did over 9000 times before ;-) > > Nikolai > > I don't see how a compiler can get away with not using namespaces and still be C++ compliant, since they're part of the standard. Chris V -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolai.vorontsov at quadrox.be Mon Mar 11 08:51:37 2013 From: nikolai.vorontsov at quadrox.be (Nikolai Vorontsov) Date: Mon, 11 Mar 2013 16:51:37 +0100 Subject: [Live-devel] Breaking change In-Reply-To: References: <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0F@s-giant.herent.quadrox.be> Message-ID: <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A11@s-giant.herent.quadrox.be> Hi Chris, have you ever seen C++ compiler for embedded systems? They are far away from full c++ 2003 compliance (mostly as not so many C++ features are used in embedded development - RTTI, exceptions, namespaces, templates - just a few samples). Nikolai ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Chris Van Brederode Sent: Monday, March 11, 2013 4:15 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Breaking change On Mon, Mar 11, 2013 at 11:02 AM, Nikolai Vorontsov wrote: <--snip--> Also, if some of supported compilers doesn't use namespaces (well, may be some embedded one) - then you might need to use conditional compilation as you did over 9000 times before ;-) Nikolai I don't see how a compiler can get away with not using namespaces and still be C++ compliant, since they're part of the standard. Chris V -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Mon Mar 11 08:41:17 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Mon, 11 Mar 2013 15:41:17 +0000 Subject: [Live-devel] Breaking change In-Reply-To: <8F0C76CF-D34F-4F2F-903C-2A6F2CDE1EE7@live555.com> References: <615FD77639372542BF647F5EBAA2DBC2252621B6@IL-BOL-EXCH01.smartwire.com> <6D82EC1FD7BDB04EA79ED1CA69EE26ED2A0E@s-giant.herent.quadrox.be> <8F0C76CF-D34F-4F2F-903C-2A6F2CDE1EE7@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC22526226B@IL-BOL-EXCH01.smartwire.com> The namespace would allow us to get away from the define which is a text substitution and is what causes the clash. However. What about something like #if Defined(USE_LIVE555_NAMESPACES) # define OPENLIVENS namespace { # define CLOSELIVENS } // close namespace LIVE555 # define LIVENS LIVE555:: #else # define OPENLIVENS # define CLOSELIVENS } # define LIVENS #endif Then they do not exist unless you disable the #define USE_LIVE555_NAMESPACES in the main header This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, March 11, 2013 10:05 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Breaking change may be the easiest solution for such issue is to wrap all Live555 functionality in a namespace? And place "using namespace Live555;" somewhere in it's header. Yes, that's certainly a possibility for the future. To date, however, I've avoided using C++ namespaces, because I don't want to risk breaking older compilers that might not support them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvanbrederode at gmail.com Mon Mar 11 09:01:29 2013 From: cvanbrederode at gmail.com (Chris Van Brederode) Date: Mon, 11 Mar 2013 12:01:29 -0400 Subject: [Live-devel] Tracked down the problem with latency In-Reply-To: <9B8C3C6F-1103-4B9B-88C8-A27490CAA134@live555.com> References: <9B8C3C6F-1103-4B9B-88C8-A27490CAA134@live555.com> Message-ID: Thanks for the reply I went ahead and re-implemented MPEG4VideoFileServerMediaSubsession (as MPEG4VideoFileServerMediaSubsession2) using a preferredFrameSize of 200. I did this before you responded, and it turned out it works relatively well. VLC still has some hiccoughs here and there with the video, but the OCU software that is the actual client that we will use in production is relatively well behaved. (Turns out they use the live555 library also... :-) ) Latency is good and connections setup quickly. We're in somewhat of a time crunch here, so I'm going to put this under the "well-enough" category for now since I have to move on to getting 3DS Max imports working and creating the new UGV in software. But when I have the time to spend on it I'll come back and see if I can my on On demand subsession working. Hopefully it will let me put the encoder and streamer functions in one executable. Chris V. On Tue, Mar 5, 2013 at 7:08 PM, Ross Finlayson wrote: > What kind of problems can crop up if I set preferredFrameSize to something > on the order of 200 bytes? > > > This might not work, because you are reading/parsing a byte stream source. > Our stream parsing code might not be able to handle reads that small. > > But a much better solution would be to have your input source class > deliver *discrete* MPEG-4 video frames - one at a time - directly to the > server, instead of delivering an arbitrary-sized byte stream (via a pipe). > If you do this, your "OnDemandServerMediaSubsession" subclass will need to > use a "MPEG4VideoStreamDiscreteFramer" (instead of a > "MPEG4VideoStreamFramer"). But your latency should be lowered considerably > (and your code will be much more efficient). > > 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 Mar 11 12:31:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Mar 2013 15:31:30 -0400 Subject: [Live-devel] Tracked down the problem with latency In-Reply-To: References: <9B8C3C6F-1103-4B9B-88C8-A27490CAA134@live555.com> Message-ID: On Mar 11, 2013, at 12:01 PM, Chris Van Brederode wrote: > We're in somewhat of a time crunch here Do "we" not have our own domain name? :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Tue Mar 12 05:24:45 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 12 Mar 2013 12:24:45 +0000 Subject: [Live-devel] Access violation in ReorderingpacketBuffer::freepacket Message-ID: <615FD77639372542BF647F5EBAA2DBC22526267E@IL-BOL-EXCH01.smartwire.com> I am trying to solve a crash in my code that shows up at the line indicated in MyultiFramedRTPSource.cpp from the 2013.03.07 livee555 code. I had this same issue with the 2012.02.29, so I updated. When I inspected the packet before the update, it was always the fBuf value that was 0xddddddd but this time absolutely everything looks valid. class ReorderingPacketBuffer { public: ReorderingPacketBuffer(BufferedPacketFactory* packetFactory); virtual ~ReorderingPacketBuffer(); void reset(); BufferedPacket* getFreePacket(MultiFramedRTPSource* ourSource); Boolean storePacket(BufferedPacket* bPacket); BufferedPacket* getNextCompletedPacket(Boolean& packetLossPreceded); void releaseUsedPacket(BufferedPacket* packet); void freePacket(BufferedPacket* packet) { if (packet != fSavedPacket) { delete packet; <<<-------------Access violation here } else { fSavedPacketFree = True; } } The 0xdddddddd is a magic value placed in pointer locations by the debug runtime to signal that the memory the pointer points to has already been released. To make it easier to find. The only thing I can see is that the packet size is 20000 but the memory at that location is only 23 bytes and the rest is the cdcdcd... pattern which is "Clean memory" it means it is newly initialized and so even that looks ok. Any suggestions on how to track this down? This was after a few minutes of streaming video. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From jshanab at smartwire.com Tue Mar 12 06:15:54 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 12 Mar 2013 13:15:54 +0000 Subject: [Live-devel] Access Violation additional info Message-ID: <615FD77639372542BF647F5EBAA2DBC2252626B3@IL-BOL-EXCH01.smartwire.com> This is the case where I hit the MAX_PACKET_SIZE. It looks like the heap gets corrupted and therefore the freeing of the packet (in debug mode on Windows) throws an access violation. I am gonna test with a larger buffer size to see if I can avoid the issue, but is there something special that needs to be done to handle this case. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Tue Mar 12 06:54:22 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 12 Mar 2013 09:54:22 -0400 Subject: [Live-devel] Access violation in ReorderingpacketBuffer::freepacket In-Reply-To: <615FD77639372542BF647F5EBAA2DBC22526267E@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC22526267E@IL-BOL-EXCH01.smartwire.com> Message-ID: Unfortunately you're probably going to track this down yourself, unless you can get the crash to happen with the "testRTSPClient" demo application. However, you mentioned before that your crash happened after you introduced a "new brand of camera", so you might want to begin by investigating what might be different about this camera. In particular, I suggest starting by comparing the SDP description returned by this camera with that returned by your other cameras (that don't cause the crash). But apart from that, you're on your own. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Tue Mar 12 11:18:47 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 12 Mar 2013 18:18:47 +0000 Subject: [Live-devel] Access violation in ReorderingpacketBuffer::freepacket In-Reply-To: References: <615FD77639372542BF647F5EBAA2DBC22526267E@IL-BOL-EXCH01.smartwire.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC225262801@IL-BOL-EXCH01.smartwire.com> Thanks. I have gotten it to crash 4 or 5 times now and in all cases the Packet is in varying states of destruction. The previous observation about max packet size was not repeatable. This points to a race condition. The code is identical to all the other camera models but it is possible this is the first one calling into use packet-reordering. There is something different, for sure. But I am connected to 25 to 400 cameera streams so crashing the whole process because of double delete or heap corruption is a real problem. I will let you know if I find anything profound. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, March 12, 2013 8:54 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Access violation in ReorderingpacketBuffer::freepacket Unfortunately you're probably going to track this down yourself, unless you can get the crash to happen with the "testRTSPClient" demo application. However, you mentioned before that your crash happened after you introduced a "new brand of camera", so you might want to begin by investigating what might be different about this camera. In particular, I suggest starting by comparing the SDP description returned by this camera with that returned by your other cameras (that don't cause the crash). But apart from that, you're on your own. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 12 12:54:37 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 12 Mar 2013 15:54:37 -0400 Subject: [Live-devel] Access violation in ReorderingpacketBuffer::freepacket In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225262801@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC22526267E@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC225262801@IL-BOL-EXCH01.smartwire.com> Message-ID: > Thanks. I have gotten it to crash 4 or 5 times now and in all cases the Packet is in varying states of destruction. The previous observation about max packet size was not repeatable. This points to a race condition. Note that a 'race condition' is unlikely, because each "TaskScheduler" runs a single-threaded event loop. Essentially, the RTP receiving code is just a loop: while (1) { read a packet from the network; process the packet; } Also, in a properly designed application, each event loop thread (if there's more than one) never accesses a LIVE555 object that's used by another thread. But, because we (obviously) don't know how your application code works, we're probably not going to be able to help you if you can't repeat the problem using our simple "testRTSPClient" demo application. > I will let you know if I find anything profound. Please replace "if" with "if and only if" :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark_jj_mccormak at yahoo.co.uk Wed Mar 13 02:47:51 2013 From: mark_jj_mccormak at yahoo.co.uk (Mark McCormack) Date: Wed, 13 Mar 2013 09:47:51 +0000 (GMT) Subject: [Live-devel] Fw: using live555 as a client to receive 1920x1080 H264 over rtsp In-Reply-To: <1363167279.24028.YahooMailNeo@web172005.mail.ir2.yahoo.com> References: <1363167279.24028.YahooMailNeo@web172005.mail.ir2.yahoo.com> Message-ID: <1363168071.88431.YahooMailNeo@web172003.mail.ir2.yahoo.com> Firstly, I'm loving the live555 libraries, if you're reading Ross - a big thank you for making this open source!? I've learnt a lot about the technologies from running up and debugging through the source code :o) I've been using the RTSP client of live555 to receive a 'full-hd' stream of H264 encoded video over RTSP, sent by VLC (2.0.5).? I have been using the NAL units sent from live555 (via H264VideoRTPSource) and passing them directly (no packetizer or grouper e.g, just prefixing the start code) to a Media Foundation H264 decoder.? This worked perfectly, so then I changed decoder to avcodec (ffmpeg libraries) and the same video source has corrupted decoder output (sort of grey smudges with bits of the actual frames in). I've been reading through the live555 code and searching through posts on forums to try and see if this is a issue with live555 or the av decoder.? FYI, the same RTSP stream works in VLC as client, but *only* with the use of a H264 packetizer in between the RTSP and decoder modules.? What I see if I WireShark the RTP packets is what looks like several NAL units per timestamp, and when I debug VLC I notice these are "collected" by the packetizer before being presented to avcodec, but my code just passes these one by one to avcodec. Then I found this post, which seemed to indicate the person asking the question was seeing H264 over RTP with a similar nature: http://stackoverflow.com/questions/6756770/libavcodec-how-to-tell-end-of-access-unit-when-decoding-h-264-stream So as an experiment I have put some extra code in my RTPSink which collects these NAL units together based on the RTP timestamp and then I pass this collection to the decoder.? This appears to work perfectly with both avcodec and the media foundation h264 decoder. I've sent a lot of other H264 streams fine from VLC, but only the full-hd ones seem to need this "collection" method in my live555-based client.? These other streams play just fine using avcodec just passing the NAL units directly to the decoder. I'm not asking VLC to re-encode the footage just read the .mov file (H264/AAC) and serve it up as RTSP - which makes me wonder if the source file was encoded in a non-standard way, somehow fragmenting the NAL units or maybe splitting them down because the units are so large being for full hd? I'm happy enough leaving the collection method in my RTSP client, maybe perhaps just for H264, but I was wondering if this is masking a problem with something else, or maybe collecting by timestamp isn't a good idea for some reason? Thanks in advance for any suggestions, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Wed Mar 13 14:18:08 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Wed, 13 Mar 2013 21:18:08 +0000 Subject: [Live-devel] Memory management Question. Message-ID: <615FD77639372542BF647F5EBAA2DBC225282A70@IL-BOL-EXCH01.smartwire.com> My RTSPProxyServer c++ class has a RTSPServer* in it like the example proxy C style example program. Is there some background magic to destruct the instance created from when I called RTSPServer::createNew ? The destructor is protected. I am using a smartpointer and it cannot access the destructor. If I make it raw and my class destructs, how does this memory get reclaimed? Is this the static close function in the baseclass? (In general there will be only one instance, but this is a sub-service that I want to be able to destroy and recreate if there is an issue or a major topology/port change without restarting the whole application) Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Wed Mar 13 22:00:32 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Mar 2013 01:00:32 -0400 Subject: [Live-devel] using live555 as a client to receive 1920x1080 H264 over rtsp In-Reply-To: <1363168071.88431.YahooMailNeo@web172003.mail.ir2.yahoo.com> References: <1363167279.24028.YahooMailNeo@web172005.mail.ir2.yahoo.com> <1363168071.88431.YahooMailNeo@web172003.mail.ir2.yahoo.com> Message-ID: <6338A1EF-1448-4B29-8A6D-09D5C811847C@live555.com> > I've been using the RTSP client of live555 to receive a 'full-hd' stream of H264 encoded video over RTSP, sent by VLC (2.0.5). I have been using the NAL units sent from live555 (via H264VideoRTPSource) and passing them directly (no packetizer or grouper e.g, just prefixing the start code) to a Media Foundation H264 decoder. This worked perfectly, so then I changed decoder to avcodec (ffmpeg libraries) and the same video source has corrupted decoder output (sort of grey smudges with bits of the actual frames in). > > I've been reading through the live555 code and searching through posts on forums to try and see if this is a issue with live555 or the av decoder. Because you've demonstrated that your received H.264 NAL units render OK with one decoder, but not with the other, this suggests that the problem is with the decoder. (Logic 101 :-) One thing to keep in mind, though, is that because network packets have 'jitter' (i.e., are not received at a smooth, constant rate), received NAL units will need to be buffered before being rendered. (The rendering time should be based upon the 'presentation time' that you get with each NAL unit.) Some decoders might do buffering automatically; others might not (in which case you'll need to add some buffering yourself). > FYI, the same RTSP stream works in VLC as client, but *only* with the use of a H264 packetizer in between the RTSP and decoder modules. I don't understand what you mean by this, because VLC - when receiving RTSP streams - does so using the LIVE555 libraries, and so does so by receiving one NAL unit at a time, just as your own receiver application does. You should check whether the (original, unmodified) VLC media player application plays your stream OK. If it does, then you could use the VLC code as a model. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Mar 13 22:09:25 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Mar 2013 01:09:25 -0400 Subject: [Live-devel] Memory management Question. In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225282A70@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225282A70@IL-BOL-EXCH01.smartwire.com> Message-ID: > Is there some background magic to destruct the instance created from when I called RTSPServer::createNew ? Call "Medium::close(pointer-to-object)", just as with every other subclass of "Medium". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghav at fossilshale.com Thu Mar 14 00:02:39 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Thu, 14 Mar 2013 01:02:39 -0600 Subject: [Live-devel] RR report packet Send to Client Port Message-ID: <20130314010239.4811688v7cy1cpov@mail.fossilshale.com> Hi, LIVE555 Server working fine till 65 sec after that Server Stoping to send data. I found that its not receiving RR report from client. When i observed in wire shark Client sending RR report packets but the source and destination port are same. What could the reason for this. am using Live555 SERVER and Live555 client. Thanks, Raghav. From finlayson at live555.com Thu Mar 14 03:23:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Mar 2013 06:23:55 -0400 Subject: [Live-devel] RR report packet Send to Client Port In-Reply-To: <20130314010239.4811688v7cy1cpov@mail.fossilshale.com> References: <20130314010239.4811688v7cy1cpov@mail.fossilshale.com> Message-ID: <107A5FCD-90EB-40AB-96F6-EEEA0DB4F27B@live555.com> > LIVE555 Server working fine till 65 sec after that Server Stoping to send data. > I found that its not receiving RR report from client. > When i observed in wire shark Client sending RR report packets If the client is sending RTCP "RR" packets, but the server is not receiving them, then it must be because either 1/ There is a firewall somewhere between the client and server that is blocking these packets, or 2/ The client is sending the RTCP "RR" packets to the wrong port number. (RTCP packets should be sent to the odd port "n+1", where RTP packets are sent to the even port "n". If the client and server both use our software, then these port numbers will be correct.) > but the source and destination port are same Completely irrelevant. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark_jj_mccormak at yahoo.co.uk Thu Mar 14 06:58:54 2013 From: mark_jj_mccormak at yahoo.co.uk (Mark McCormack) Date: Thu, 14 Mar 2013 13:58:54 +0000 (GMT) Subject: [Live-devel] using live555 as a client to receive 1920x1080 H264 over rtsp In-Reply-To: References: Message-ID: <1363269534.31580.YahooMailNeo@web172001.mail.ir2.yahoo.com> Ross, >?I don't understand what you mean by this, because VLC - when receiving RTSP streams - does so using the LIVE555 libraries, and so does so by receiving one NAL unit at a time, just as your own receiver application does. Sorry, probably not explained myself. ?I am using the VLC code as reference as it also does receive one NAL unit at a time in it's live555 demuxer module, however these units pass through and get collected by a h264 packetizer module before getting to the avcodec module. ?VLC does play everything fine in this setup, unless I delete the h264 packetizer plugin .dll - which causes VLC to use the fall-back copy packetizer (which just copies each unit as is, no grouping). ?With no packetizer VLC as a client really struggles on most H264 RTSP sources, having similar issues as I was having, so it looks like the h264 packetizer in VLC gets it out of a lot of trouble. ?I was under the impression the packetizers in VLC were just for making sense from a bitstream but it seems they are used to 'help' other modules along as well - in this case the live555 demux module. > One thing to keep in mind, though, is that because network packets have 'jitter' (i.e., are not received at a smooth, constant rate), received NAL units will need to be buffered before being rendered. ? > (The rendering time should be based upon the 'presentation time' that you get with each NAL unit.) ?Some decoders might do buffering automatically; others might not (in which case you'll need to add some buffering yourself). I think you've pretty much hit the issue, I'm guessing (as the MF decoder is closed source) the MF decoder does this buffering whereas avcodec does not. ?I've now implemented the suggestion you have above where I base the rendering on the 'presentation time' from live555 - all works smoothly, both the troublesome feeds and the ones that previously worked without this. Thanks! Mark. ________________________________ From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Thursday, 14 March 2013, 5:00 Subject: Re: [Live-devel] using live555 as a client to receive 1920x1080 H264 over rtsp I've been using the RTSP client of live555 to receive a 'full-hd' stream of H264 encoded video over RTSP, sent by VLC (2.0.5).? I have been using the NAL units sent from live555 (via H264VideoRTPSource) and passing them directly (no packetizer or grouper e.g, just prefixing the start code) to a Media Foundation H264 decoder.? This worked perfectly, so then I changed decoder to avcodec (ffmpeg libraries) and the same video source has corrupted decoder output (sort of grey smudges with bits of the actual frames in). > >I've been reading through the live555 code and searching through posts on forums to try and see if this is a issue with live555 or the av decoder.? Because you've demonstrated that your received H.264 NAL units render OK with one decoder, but not with the other, this suggests that the problem is with the decoder. ?(Logic 101 :-) One thing to keep in mind, though, is that because network packets have 'jitter' (i.e., are not received at a smooth, constant rate), received NAL units will need to be buffered before being rendered. ?(The rendering time should be based upon the 'presentation time' that you get with each NAL unit.) ?Some decoders might do buffering automatically; others might not (in which case you'll need to add some buffering yourself). FYI, the same RTSP stream works in VLC as client, but *only* with the use of a H264 packetizer in between the RTSP and decoder modules. I don't understand what you mean by this, because VLC - when receiving RTSP streams - does so using the LIVE555 libraries, and so does so by receiving one NAL unit at a time, just as your own receiver application does. You should check whether the (original, unmodified) VLC media player application plays your stream OK. ?If it does, then you could use the VLC code as a model. 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 raghav at fossilshale.com Thu Mar 14 08:20:24 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Thu, 14 Mar 2013 09:20:24 -0600 Subject: [Live-devel] RR report packet Send to Client Message-ID: <20130314092024.48945d1x9rtptxa0@mail.fossilshale.com> Hi, LIVE555 Server receiving RR report to port number Which is exactly client rtcp port number but on server side.what could be problem? and Am using LIVE555 as client. Thnaks, Raghav. From finlayson at live555.com Thu Mar 14 08:34:50 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Mar 2013 11:34:50 -0400 Subject: [Live-devel] RR report packet Send to Client In-Reply-To: <20130314092024.48945d1x9rtptxa0@mail.fossilshale.com> References: <20130314092024.48945d1x9rtptxa0@mail.fossilshale.com> Message-ID: <6E58C4F9-D0F8-439A-8F07-1DCEB11D7BD8@live555.com> I'm sorry, but I'm not understanding your question at all. To help clarify things, please post the complete RTSP protocol exchange - between your client and your server. (I'm assuming here that you have made *no* modifications to our supplied library code. If you *have* modified our library code, then I'm not interested in your question.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Mar 14 20:11:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Mar 2013 23:11:06 -0400 Subject: [Live-devel] Reminder: A quick survey: How are you using the "LIVE555 Streaming Media" software? Message-ID: Thank you to the almost 100 people so far who have taken our survey: How are you using the "LIVE555 Streaming Media" software? It's good to have gotten 100 responses - except that there are almost 1900 people on this mailing list! Even excluding 'hobbyist' email addresses, we still have almost 1000 professional email addresses on the list. I presume most of you are actually using this software (otherwise why would you be on this mailing list? :-) So, if you haven't already done so, please take the following quick survey: http://www.surveymonkey.com/s/T5NNYY9 Once enough people have responded to this survey, there will be a new, follow-up survey, asking about possible new features, modifications, extensions, etc. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonygriffen at gmail.com Thu Mar 14 18:33:43 2013 From: tonygriffen at gmail.com (Tony Griffen) Date: Thu, 14 Mar 2013 18:33:43 -0700 Subject: [Live-devel] Looking for proven mpg test media Message-ID: I am using LIVE555 Media Server version 0.76 (LIVE555 Streaming Media library version 2013.01.03) on CentOS 6.3. It installed and runs fine, but I am having a hard time finding test media to verify rtsp. I've tried a variety of mpg files, always some kind of problem with it (like "StreamParser::parsePESPacket(): saw inconsistent PES_packet_length). Some of the file formats it supports, VLC client doesn't, and vice versa. Is there proven test media somewhere that both of those will like? I saw m4e and others in the FAQ, but VLC doesn't understand them. Any pointers will be appreciated. This is for testing rtsp going through internetworking devices, so media doesn't need to be fancy, just work safe. Any pointers will be appreciated. From finlayson at live555.com Thu Mar 14 20:40:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Mar 2013 23:40:09 -0400 Subject: [Live-devel] Looking for proven mpg test media In-Reply-To: References: Message-ID: > I am using LIVE555 Media Server version 0.76 (LIVE555 Streaming Media > library version 2013.01.03) on CentOS 6.3. It installed and runs fine, > but I am having a hard time finding test media to verify rtsp. I've > tried a variety of mpg files, always some kind of problem with it > (like "StreamParser::parsePESPacket(): saw inconsistent > PES_packet_length). Some of the file formats it supports, VLC client > doesn't, and vice versa. Is there proven test media somewhere that > both of those will like? I saw m4e and others in the FAQ, but VLC > doesn't understand them. When you say that VLC "doesn't understand" these files, I presume you mean that VLC can't play these files when you try to play them directly. (VLC should be able to play the RTSP/RTP stream - using the "rtsp://" URL from the "LIVE555 Media Server".) This is VLC's fault, not ours. VLC does not understand many of the filename extensions that our Media Server understands. However, you can try streaming one or more of the H.264 Elementary Stream files from http://www.live555.com/liveMedia/public/264/ These files should also be playable by VLC, if you rename them so that they have a ".h264" filename extension, rather than a ".264" filename extension. You can also download and stream this Transport Stream file: http://www.live555.com/liveMedia/public/h264-in-mp2t/bipbop-gear1-all.ts and that file should also be playable by VLC. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonygriffen at gmail.com Fri Mar 15 07:30:26 2013 From: tonygriffen at gmail.com (Tony Griffen) Date: Fri, 15 Mar 2013 07:30:26 -0700 Subject: [Live-devel] Looking for proven mpg test media In-Reply-To: References: Message-ID: > You can also download and stream this Transport Stream file: > http://www.live555.com/liveMedia/public/h264-in-mp2t/bipbop-gear1-all.ts That did the trick, thank you. I knew I had it set up right. That's a perfect file for my purposes, btw. Cheers, t. On Thu, Mar 14, 2013 at 8:40 PM, Ross Finlayson wrote: > I am using LIVE555 Media Server version 0.76 (LIVE555 Streaming Media > library version 2013.01.03) on CentOS 6.3. It installed and runs fine, > but I am having a hard time finding test media to verify rtsp. I've > tried a variety of mpg files, always some kind of problem with it > (like "StreamParser::parsePESPacket(): saw inconsistent > PES_packet_length). Some of the file formats it supports, VLC client > doesn't, and vice versa. Is there proven test media somewhere that > both of those will like? I saw m4e and others in the FAQ, but VLC > doesn't understand them. > > > When you say that VLC "doesn't understand" these files, I presume you mean > that VLC can't play these files when you try to play them directly. (VLC > should be able to play the RTSP/RTP stream - using the "rtsp://" URL from > the "LIVE555 Media Server".) This is VLC's fault, not ours. VLC does not > understand many of the filename extensions that our Media Server > understands. > > However, you can try streaming one or more of the H.264 Elementary Stream > files from > http://www.live555.com/liveMedia/public/264/ > These files should also be playable by VLC, if you rename them so that they > have a ".h264" filename extension, rather than a ".264" filename extension. > > You can also download and stream this Transport Stream file: > http://www.live555.com/liveMedia/public/h264-in-mp2t/bipbop-gear1-all.ts > and that file should also be playable by VLC. > > > 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 > From michel.promonet at thalesgroup.com Mon Mar 18 05:53:32 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Mon, 18 Mar 2013 13:53:32 +0100 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? Message-ID: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> Hi Ross, I was still thinking on my issue to send presentation time from an RTSP server to an RTSP client. I wondering if it could be a way that RTSP server answer to PLAY with an absolute Range (like Range: clock=xxxxTxxxxxZ-) and use this information and the rtpTime from the RTP-Info to initialize conversion between RTP time and NTP time. Do you think it's an acceptable way ? Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 18 06:04:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Mar 2013 09:04:46 -0400 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> References: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> Message-ID: <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> I'm not sure specifically what you're asking, but as I've said (many times) before, the presentation times that are delivered at the receiver end *will* be synchronized, when (and only when) the first RTCP "SR" is received. The "RTP-Info" information is different - it helps the receiver get the 'normal play time' (think: the time that would be shown on a VCR display) after the "PLAY". The client code is working just fine. There is nothing to 'fix'. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Mon Mar 18 08:24:11 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Mon, 18 Mar 2013 16:24:11 +0100 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> References: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> Message-ID: <11090_1363620255_5147319F_11090_872_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E672@THSONEA01CMS01P.one.grp> Hi Ross, I know you already answer to previous tries to find a way to have a presentation time in the client (before the RTCP report) that is based on RTSP server information and not on RTSP client current time. I 'm just looking for a way to initialize the presentation time (the NTP time) not the normal play time from information coming from the RTSP server. To clarify our context, we are using live555 to re-stream data that are recorded, then timestamps are not linked to current client time. So the estimation of presentation based on current time before receiving RTCP "SR" is really not accurate... What I was suggesting is this "missing" NTP information (before RTCP "SR") could perhaps be computed from RTSP PLAY answer. It is quite annoying to drop data waiting for RTCP "SR" because we cannot send the timestamp through RTSP/RTP/RTCP mechanism. As I told you, our actual hack is to use RTSP GET_PARAMETER to send this information in a non standard way. Ok perhaps I have to accept this ! Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 18 mars 2013 14:05 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? I'm not sure specifically what you're asking, but as I've said (many times) before, the presentation times that are delivered at the receiver end *will* be synchronized, when (and only when) the first RTCP "SR" is received. The "RTP-Info" information is different - it helps the receiver get the 'normal play time' (think: the time that would be shown on a VCR display) after the "PLAY". The client code is working just fine. There is nothing to 'fix'. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 18 13:57:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Mar 2013 16:57:13 -0400 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: <11090_1363620255_5147319F_11090_872_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E672@THSONEA01CMS01P.one.grp> References: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> <11090_1363620255_5147319F_11090_872_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E672@THSONEA01CMS01P.one.grp> Message-ID: <32C0C8B2-3237-4543-A259-B767C1D94E4A@live555.com> > What I was suggesting is this ?missing? NTP information (before RTCP ?SR?) could perhaps be computed from RTSP PLAY answer. > It is quite annoying to drop data waiting for RTCP ?SR? because we cannot send the timestamp through RTSP/RTP/RTCP mechanism. What I can probably do is upgrade our server code so that it sends a RTCP "SR" packet immediately upon handling a "PLAY" command (before the first RTP packet is sent). (I think this is actually prescribed in one of the IETF RFCs.) That won't be 100% reliable (because this first RTCP packet may get lost, but most of the time it will eliminate the delay before RTCP synchronization occurs. Yes, it would be nice if the "RTP-Info:" data included a NTP-format time (the same as in RTCP "SR"s), but unfortunately that's not in the standard. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Mon Mar 18 02:43:14 2013 From: kingaceck at 163.com (kingaceck) Date: Mon, 18 Mar 2013 17:43:14 +0800 Subject: [Live-devel] audio and vedio can not synchronization Message-ID: <201303181743135786718@163.com> Hi I am using live555 to support mp4 file that with h264 and aac.when vlc play the mp4 file automation the audio and vedio can synchronization .If I click the progress bar to jump to a special position the audio and vedio can not synchronization .What can I do to resolve the problem.Thank you. In the subsession I rewrite the seekStreamSource like this: void FfmpegH264ServerMediaSubsession ::seekStreamSource(FramedSource* inputSource, double& seekNPT, double /*streamDuration*/, u_int64_t& /*numBytes*/) { H264VideoStreamFramer* framer = (H264VideoStreamFramer*)inputSource; framer->flushInput(); // "inputSource" is a filter; its input source is the original elem stream source: FfmpegDemuxedElementaryStream* elemStreamSource = (FfmpegDemuxedElementaryStream*)(((FramedFilter*)inputSource)->inputSource()); // Next, get the original source demux: FfmpegDemux& sourceDemux = elemStreamSource->sourceDemux(); // and flush its input buffers: sourceDemux.FlushInput(); sourceDemux.seekStreamSource(seekNPT); } void FfmpegDemux::seekStreamSource(double seekNPT) { av_seek_frame(format_ctx_, -1, seekNPT * 1000 * 1000, AVSEEK_FLAG_BACKWARD); //timestamp is usec } 2013-03-18 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Mon Mar 18 14:48:02 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Mon, 18 Mar 2013 21:48:02 +0000 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: <32C0C8B2-3237-4543-A259-B767C1D94E4A@live555.com> References: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> <11090_1363620255_5147319F_11090_872_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E672@THSONEA01CMS01P.one.grp> <32C0C8B2-3237-4543-A259-B767C1D94E4A@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC225288889@IL-BOL-EXCH01.smartwire.com> I record video from a security camera. I do not want to throw away up to the first 2 seconds so I measure the offset and adjust my timestamps to the timebase of the machine. When I get the sync notification I adjust the adjustment. This adjustment is continually applied to all timestamps. It is not the ntp time of the server, but it is an exact offset from the beginning of the hour of a ntp syned machine, we split our video on the hour boundry. We let the camera independently sync to a ntp server and it all stays very close. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, March 18, 2013 3:57 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? What I was suggesting is this "missing" NTP information (before RTCP "SR") could perhaps be computed from RTSP PLAY answer. It is quite annoying to drop data waiting for RTCP "SR" because we cannot send the timestamp through RTSP/RTP/RTCP mechanism. What I can probably do is upgrade our server code so that it sends a RTCP "SR" packet immediately upon handling a "PLAY" command (before the first RTP packet is sent). (I think this is actually prescribed in one of the IETF RFCs.) That won't be 100% reliable (because this first RTCP packet may get lost, but most of the time it will eliminate the delay before RTCP synchronization occurs. Yes, it would be nice if the "RTP-Info:" data included a NTP-format time (the same as in RTCP "SR"s), but unfortunately that's not in the standard. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shilpa_Chandrappa at mindtree.com Tue Mar 19 01:06:34 2013 From: Shilpa_Chandrappa at mindtree.com (Shilpa Chandrappa) Date: Tue, 19 Mar 2013 08:06:34 +0000 Subject: [Live-devel] Regarding porting live555 to FreeRTOS Message-ID: <5A68633E3082EB4CA04473BFE94ECFD708630037@MTW02MBX05.mindtree.com> Hi All, Is it possible to port live555 to FreeRTOS ? Has anybody worked on it ? I am new to FreeRTOS. Your inputs will be of great help. Thanks, Shilpa Chandrappa ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 19 03:59:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Mar 2013 06:59:05 -0400 Subject: [Live-devel] Regarding porting live555 to FreeRTOS In-Reply-To: <5A68633E3082EB4CA04473BFE94ECFD708630037@MTW02MBX05.mindtree.com> References: <5A68633E3082EB4CA04473BFE94ECFD708630037@MTW02MBX05.mindtree.com> Message-ID: <3C043D0A-2C57-4123-A5EB-A17110E72B87@live555.com> > Is it possible to port live555 to FreeRTOS ? Until I read your email, I wasn't aware of "FreeRTOS"; I had to look it up. Does "FreeRTOS" support sockets - i.e., using the standard Unix socket API (in particular, "socket()" and "select()")? If so, then the "LIVE555 Streaming Media" code *may* be able to run on it. However, if anyone knows for sure, then please let us know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Tue Mar 19 08:42:05 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 19 Mar 2013 16:42:05 +0100 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: <32C0C8B2-3237-4543-A259-B767C1D94E4A@live555.com> References: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> <11090_1363620255_5147319F_11090_872_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E672@THSONEA01CMS01P.one.grp> <32C0C8B2-3237-4543-A259-B767C1D94E4A@live555.com> Message-ID: <4349_1363707727_5148874F_4349_3768_1_1BE8971B6CFF3A4F97AF4011882AA25501560DBC77E5@THSONEA01CMS01P.one.grp> Hi Ross, Thanks for your support and your patience. But as you said reducing SR period just reduce the risk. Perhaps a trade-off between the standard and what could do a live555 user could be to give a way to RTSPClient user to give the fSyncTime initialization. Through a non standard way to acquire the time reference (perhaps additional RTSP ), I guess it will then be possible through MediaSubSession -> RTPSource -> RTPReceptionStats to set the initial value. Do you think this could be an acceptable way ? Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 18 mars 2013 21:57 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? What I was suggesting is this "missing" NTP information (before RTCP "SR") could perhaps be computed from RTSP PLAY answer. It is quite annoying to drop data waiting for RTCP "SR" because we cannot send the timestamp through RTSP/RTP/RTCP mechanism. What I can probably do is upgrade our server code so that it sends a RTCP "SR" packet immediately upon handling a "PLAY" command (before the first RTP packet is sent). (I think this is actually prescribed in one of the IETF RFCs.) That won't be 100% reliable (because this first RTCP packet may get lost, but most of the time it will eliminate the delay before RTCP synchronization occurs. Yes, it would be nice if the "RTP-Info:" data included a NTP-format time (the same as in RTCP "SR"s), but unfortunately that's not in the standard. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Tue Mar 19 09:47:52 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Tue, 19 Mar 2013 16:47:52 +0000 Subject: [Live-devel] SOCKLEN_T type / AC3AudioStreamParser try-catch / AC3 stream header Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E8A32@postal.sonicfoundry.net> 1.) I compiled and ran live555 on Raspberry Pi but I changed the type of SOCKLEN_T: Groupsock/include/NetCommon.h #if defined(__WIN32__) || defined(_WIN32) || defined(_WIN32_WCE) #ifndef SOCKLEN_T #define SOCKLEN_T int #endif #else /* Unix */ #ifndef SOCKLEN_T #define SOCKLEN_T unsigned int #endif #endif Int works fine on windows but it's unsigned int on the PI. 2.) I noticed a try/catch block in liveMedia\AC3AudioStreamFramer.cpp is this intentional? 3.) Since my compiler stumbled over try/catch (exceptions turned off) I came across (liveMedia/AC3AudioStreamFramer.cpp) // We expect an AC3 audio header (first 2 bytes == 0x0B77) at the start: while (1) { unsigned next4Bytes = test4Bytes(); if (next4Bytes>>16 == 0x0B77) break; skipBytes(1); saveParserState(); } AC3 streams are WORD oriented and both endianness' are possible. So your sync WORD can be 0x0b77 or 0x770b. Depending on your host endianness you may have to swap the odd with the even bytes. Markus. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 19 10:01:00 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Mar 2013 13:01:00 -0400 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: <4349_1363707727_5148874F_4349_3768_1_1BE8971B6CFF3A4F97AF4011882AA25501560DBC77E5@THSONEA01CMS01P.one.grp> References: <19863_1363611216_51470E4F_19863_5022_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E20D@THSONEA01CMS01P.one.grp> <837A7375-4180-44AA-A73D-740BEFD10569@live555.com> <11090_1363620255_5147319F_11090_872_1_1BE8971B6CFF3A4F97AF4011882AA25501560DB6E672@THSONEA01CMS01P.one.grp> <32C0C8B2-3237-4543-A259-B767C1D94E4A@live555.com> <4349_1363707727_5148874F_4349_3768_1_1BE8971B6CFF3A4F97AF4011882AA25501560DBC77E5@THSONEA01CMS01P.one.grp> Message-ID: <53EDD62F-FE68-4562-92E0-2446A49BA785@live555.com> As I said before (and am, I hope, saying for the last time), I'm not going to be doing anything non-standard here. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 19 10:30:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Mar 2013 13:30:15 -0400 Subject: [Live-devel] SOCKLEN_T type / AC3AudioStreamParser try-catch / AC3 stream header In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010E8A32@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010E8A32@postal.sonicfoundry.net> Message-ID: > I compiled and ran live555 on Raspberry Pi but I changed the type of SOCKLEN_T For the bazillionth time: Please DO NOT change the supplied code! (I want to make it as easy as possible for you to comply with the LGPL :-) > Int works fine on windows but it?s unsigned int on the PI. Does your development environment for the 'Raspberry Pi' (Linux, right?) not already define "socklen_t"?? If it does, then you should be able to use the existing "config.linux" configuration file. But even if it doesn't, there's a very easy way to make this change, without having to modify the supplied code: Create a "config.linux-for-raspberry-pi" configuration file (perhaps just by copying "config.linux"), and, in the 'COMPILE_OPTS' line, set -DSOCKLEN_T="unsigned int" (I'm not sure about the quoting there; you might need to use single quotes instead?) (If you find that you need to create a separate "config.linux-for-raspberry-pi" configuration file, then please share it on the mailing list, so I can include it in future software releases.) > I noticed a try/catch block in liveMedia\AC3AudioStreamFramer.cpp is this intentional? Of course it's intentional; I wouldn't write that code for no reason :-) > Since my compiler stumbled over try/catch (exceptions turned off) Sorry, but that won't work. To compile our code, your C++ compiler needs to understand C++ language exceptions. (I wish this weren't true, but we use C++ exceptions for stream parsing; getting rid of them would be difficult.) > I came across (liveMedia/AC3AudioStreamFramer.cpp) > > // We expect an AC3 audio header (first 2 bytes == 0x0B77) at the start: > while (1) { > unsigned next4Bytes = test4Bytes(); > if (next4Bytes>>16 == 0x0B77) break; > skipBytes(1); > saveParserState(); > } > > AC3 streams are WORD oriented and both endianness? are possible. Are you saying that both orders are possible *in the stream*?? I don't think that's true. The AC-3 specification says, I think, that all values are sent in 'big endian' order (i.e., high-order byte first). Our "test4Bytes()" code reads the next 4 bytes - one at a time - from the stream, always returning a 'big endian' result (regardless of the byte order of the host computer). So the code of ours that you quoted is correct, I believe. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeller at miovision.com Tue Mar 19 07:41:30 2013 From: jkeller at miovision.com (Joel Keller) Date: Tue, 19 Mar 2013 10:41:30 -0400 Subject: [Live-devel] MP4 video trak samples: were do 'non-frame' NAL units belong? Message-ID: Greetings experts, Live555 is playing a key role in our industrial machine vision application - thank you for the library! I am experiencing a problem saving MP4 format video files using openRTSP. The RTSP/RTP stream is coming from a camera, and I can successfully save the 'raw/elementary' H264 NAL stream with openRTSP. However, when I save the video as MP4, with something like this: openRTSP -d 30 -b 1000000 -B 1000000 -4 -y -w 1536 -h 1536 -f 15 rtsp:// 10.0.3.11/live.sdp > myvideo.mp4 I find that the generated MP4 file contains NAL units in the 'mdat' box which do not correspond to video frames, specifically NAL units of type SPS, PPS, and SEI. These three NAL units are periodically interspersed with the frame data. This interspersion itself is of course not a problem as the media data area can contain non-frame data, and this meta data is of course needed to interpret the frame. However these NAL units are treated as 'MP4 samples' in the MP4 'Sample Table Boxes'. Specifically, in the stts (Decoding time to sample box), these samples have a "delta" of zero, implying that their presentation time is the same as the samples which precede them (this makes sense, because they are not frames of the video, but it violates ISO spec, which states that "The sample entries are ordered by decoding time stamps; therefore the deltas are all non-negative."). I find that this causes some (most?) video players to "stutter" when playing back the MP4 file (avidemux2 for example), because they determine the video's frame rate and then go sample-by-sample through the video. When the player gets to these non-frame samples, it appears to delay for the frame-duration, but it cannot decode the frame (because the sample is not a frame). This leads to a video with ~15 smooth frames, then 3 pause frames, then ~15 smooth frames. My questions are: 1) What is the correct thing to do with these NAL units in the MP4 file? 2) How can I make openRTSP/live555 create an MP4 file without this stuttering? Possible answers I have to #1 are: a. "non-frame" NAL units are appropriate samples in MP4 video traks. But then what to do with the stts deltas? b. "non-frame" NAL units should not show up as samples (see avcC box), and should be 'skipped over' based on MP4 'chunks'. But how do I get live555 to do this? c. "non-frame' NAL units should be "combined" their following "frame" NAL unit to be a single 'MP4 sample'. (ie a sample is not necessarily a single NAL unit). Again how would I get live555 to do this? Thank you for reading this long post. I am most grateful for any help. Thanks, Joel Keller -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 19 10:54:57 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Mar 2013 13:54:57 -0400 Subject: [Live-devel] MP4 video trak samples: were do 'non-frame' NAL units belong? In-Reply-To: References: Message-ID: > My questions are: > > 1) What is the correct thing to do with these NAL units in the MP4 file? > > 2) How can I make openRTSP/live555 create an MP4 file without this stuttering? Unfortunately I don't know the answers to these questions, because I'm not an expert on the "MP4" file format. What I do know, though, is that this file format is ill-suited for what we are trying to do here: Record a file that properly represents incoming audio and video frames that are time-stamped. But - in spite of this format's bad design - we try to do the best that we can... But if you're interested in trying to improve this, the code to look at is our implementation of the "QuickTimeFileSink" class - i.e., "liveMedia/QuickTimeFileSink.cpp". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hassan.nust at gmail.com Tue Mar 19 11:43:45 2013 From: hassan.nust at gmail.com (Muhammad Hassan) Date: Tue, 19 Mar 2013 23:43:45 +0500 Subject: [Live-devel] MP4 video trak samples: were do 'non-frame' NAL units belong? In-Reply-To: References: Message-ID: U can write your own source filter using live555 client side code and connect it to any muxer filter like matroska, mp4 or avi and then save it. Feel free to contact me at hassan.nust at gmail.com On Mar 19, 2013 10:48 PM, "Joel Keller" wrote: > Greetings experts, > > Live555 is playing a key role in our industrial machine vision application > - thank you for the library! I am experiencing a problem saving MP4 format > video files using openRTSP. The RTSP/RTP stream is coming from a camera, > and I can successfully save the 'raw/elementary' H264 NAL stream with > openRTSP. However, when I save the video as MP4, with something like this: > > openRTSP -d 30 -b 1000000 -B 1000000 -4 -y -w 1536 -h 1536 -f 15 rtsp:// > 10.0.3.11/live.sdp > myvideo.mp4 > > > I find that the generated MP4 file contains NAL units in the 'mdat' box > which do not correspond to video frames, specifically NAL units of type > SPS, PPS, and SEI. These three NAL units are periodically interspersed > with the frame data. This interspersion itself is of course not a problem > as the media data area can contain non-frame data, and this meta data is of > course needed to interpret the frame. However these NAL units are treated > as 'MP4 samples' in the MP4 'Sample Table Boxes'. Specifically, in the > stts (Decoding time to sample box), these samples have a "delta" of zero, > implying that their presentation time is the same as the samples > which precede them (this makes sense, because they are not frames of the > video, but it violates ISO spec, which states that "The sample entries are > ordered by decoding time stamps; therefore the deltas are all > non-negative."). I find that this causes some (most?) video players to > "stutter" when playing back the MP4 file (avidemux2 for example), because > they determine the video's frame rate and then go sample-by-sample through > the video. When the player gets to these non-frame samples, it appears to > delay for the frame-duration, but it cannot decode the frame (because the > sample is not a frame). This leads to a video with ~15 smooth frames, then > 3 pause frames, then ~15 smooth frames. > > My questions are: > > 1) What is the correct thing to do with these NAL units in the MP4 file? > > 2) How can I make openRTSP/live555 create an MP4 file without this > stuttering? > > > > Possible answers I have to #1 are: > > a. "non-frame" NAL units are appropriate samples in MP4 video traks. But > then what to do with the stts deltas? > > b. "non-frame" NAL units should not show up as samples (see avcC box), > and should be 'skipped over' based on MP4 'chunks'. But how do I get > live555 to do this? > > c. "non-frame' NAL units should be "combined" their following "frame" NAL > unit to be a single 'MP4 sample'. (ie a sample is not necessarily a single > NAL unit). Again how would I get live555 to do this? > > > > Thank you for reading this long post. I am most grateful for any help. > > > Thanks, > > Joel Keller > > > _______________________________________________ > 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 jshanab at smartwire.com Tue Mar 19 18:20:30 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Wed, 20 Mar 2013 01:20:30 +0000 Subject: [Live-devel] SOCKLEN_T type / AC3AudioStreamParser try-catch / AC3 stream header In-Reply-To: References: <1ED2F9A76678E0428E90FB2B6F93672D010E8A32@postal.sonicfoundry.net>, Message-ID: <615FD77639372542BF647F5EBAA2DBC225288CE2@IL-BOL-EXCH01.smartwire.com> I just built and ran live555 and the proxyRtsptest app on my raspberry PI and I didn't have to change a thing. ________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Tuesday, March 19, 2013 12:30 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] SOCKLEN_T type / AC3AudioStreamParser try-catch / AC3 stream header I compiled and ran live555 on Raspberry Pi but I changed the type of SOCKLEN_T For the bazillionth time: Please DO NOT change the supplied code! (I want to make it as easy as possible for you to comply with the LGPL :-) Int works fine on windows but it?s unsigned int on the PI. Does your development environment for the 'Raspberry Pi' (Linux, right?) not already define "socklen_t"?? If it does, then you should be able to use the existing "config.linux" configuration file. But even if it doesn't, there's a very easy way to make this change, without having to modify the supplied code: Create a "config.linux-for-raspberry-pi" configuration file (perhaps just by copying "config.linux"), and, in the 'COMPILE_OPTS' line, set -DSOCKLEN_T="unsigned int" (I'm not sure about the quoting there; you might need to use single quotes instead?) (If you find that you need to create a separate "config.linux-for-raspberry-pi" configuration file, then please share it on the mailing list, so I can include it in future software releases.) I noticed a try/catch block in liveMedia\AC3AudioStreamFramer.cpp is this intentional? Of course it's intentional; I wouldn't write that code for no reason :-) Since my compiler stumbled over try/catch (exceptions turned off) Sorry, but that won't work. To compile our code, your C++ compiler needs to understand C++ language exceptions. (I wish this weren't true, but we use C++ exceptions for stream parsing; getting rid of them would be difficult.) I came across (liveMedia/AC3AudioStreamFramer.cpp) // We expect an AC3 audio header (first 2 bytes == 0x0B77) at the start: while (1) { unsigned next4Bytes = test4Bytes(); if (next4Bytes>>16 == 0x0B77) break; skipBytes(1); saveParserState(); } AC3 streams are WORD oriented and both endianness? are possible. Are you saying that both orders are possible *in the stream*?? I don't think that's true. The AC-3 specification says, I think, that all values are sent in 'big endian' order (i.e., high-order byte first). Our "test4Bytes()" code reads the next 4 bytes - one at a time - from the stream, always returning a 'big endian' result (regardless of the byte order of the host computer). So the code of ours that you quoted is correct, I believe. Ross Finlayson Live Networks, Inc. http://www.live555.com/ This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Wed Mar 20 01:17:29 2013 From: rglobisch at csir.co.za (Ralf Globisch) Date: Wed, 20 Mar 2013 09:17:29 +0100 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? Message-ID: Michel, I think the probability of loosing the first SR is very minor, SR packets are relatively small in comparison to the video packets and are less likely to get dropped by routers. Or do you have any indication otherwise? Ross's fix should do the trick. However if you want to decrease that probability further RFC6051( http://tools.ietf.org/html/rfc6051 ) might be of use. I'm not sure if it applies here, but from what I recall it's basically an extension header for RTP that includes an NTP timestamp allowing one to do as the name says: rapid synchronisation. You could add this extension header to the first e.g. 5 RTP packets *if* you notice a problem with the first SR being lost. To be sure read the draft to make sure it applies to this use case. > As I said before (and am, I hope, saying for the last time), I'm not going to be doing anything non-standard here. @Ross I would say this is a standard-conformant way? Standard conformant RTP applications *should* ignore the header in any case if the don't understand it, so it shouldn't break other clients... @Michel If you do write the extension header and rapid sync code, you could consider contributing it back to the live555 codebase. Regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shilpa_Chandrappa at mindtree.com Wed Mar 20 04:44:07 2013 From: Shilpa_Chandrappa at mindtree.com (Shilpa Chandrappa) Date: Wed, 20 Mar 2013 11:44:07 +0000 Subject: [Live-devel] Regarding porting live555 to FreeRTOS In-Reply-To: <3C043D0A-2C57-4123-A5EB-A17110E72B87@live555.com> References: <5A68633E3082EB4CA04473BFE94ECFD708630037@MTW02MBX05.mindtree.com> <3C043D0A-2C57-4123-A5EB-A17110E72B87@live555.com> Message-ID: <5A68633E3082EB4CA04473BFE94ECFD708630268@MTW02MBX05.mindtree.com> Hi, We are using LWIP network stack in our product. It is not Unix/Posix standard; but it has socket and select API's etc. And what is the minimal size of binary(after optimizations etc) that would be build for LIVE 555 ? All we need is MP3 stream support. Regards, Shilpa Chandrappa From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, March 19, 2013 4:29 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Regarding porting live555 to FreeRTOS Is it possible to port live555 to FreeRTOS ? Until I read your email, I wasn't aware of "FreeRTOS"; I had to look it up. Does "FreeRTOS" support sockets - i.e., using the standard Unix socket API (in particular, "socket()" and "select()")? If so, then the "LIVE555 Streaming Media" code *may* be able to run on it. However, if anyone knows for sure, then please let us know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Mar 20 07:32:31 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Mar 2013 10:32:31 -0400 Subject: [Live-devel] Regarding porting live555 to FreeRTOS In-Reply-To: <5A68633E3082EB4CA04473BFE94ECFD708630268@MTW02MBX05.mindtree.com> References: <5A68633E3082EB4CA04473BFE94ECFD708630037@MTW02MBX05.mindtree.com> <3C043D0A-2C57-4123-A5EB-A17110E72B87@live555.com> <5A68633E3082EB4CA04473BFE94ECFD708630268@MTW02MBX05.mindtree.com> Message-ID: <5BBFF851-CA11-4DD2-A22F-98B25AA32698@live555.com> > We are using LWIP network stack in our product. It is not Unix/Posix standard; but it has socket and select API?s etc. > > And what is the minimal size of binary(after optimizations etc) that would be build for LIVE 555 ? All we need is MP3 stream support. Only you can answer this question - by building one of our demo applications - e.g., "testMP3Streamer" or "testMP3Receiver". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Wed Mar 20 12:03:55 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Wed, 20 Mar 2013 19:03:55 +0000 Subject: [Live-devel] Confirm absolute time playing position on startup Message-ID: In the following examples I'm writing about streams that are (in the code) referred to as indexed by 'absolute' time. For video storage and security I believe they're often referred to as archive streams. Seeking while already streaming When doing a "seek" while the stream is playing, i.e. calling rtspClient->sendPlayCommand() with a new position to jump to, you will in the response handler be able to verify the actual position you end up playing. scs.session->absStartTime() could e.g. be 20130318T180327Z. It's a great way to verify that you got what you asked for. This is of course very useful as video hiccups are not uncommon. Start new stream at specific position When starting a new stream, also by calling rtspClient->sendPlayCommand() with an absolute position, the behavior appears to be different; scs.session->absStartTime() then instead returns the timestamp of the beginning of the stream. That information could be useful, but I'd say the expected information is to be consistent with how it works when jumping in the stream while it's already playing. Is this intended, or is it somehow server dependent? btw. scs.session->absEndTime() contains the timestamp for the end of the stream in both cases. Is there a way to confirm what position is currently playing when starting up a stream? Is there a way to ask for the timestamp that's currently being played at any given time? /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Wed Mar 20 20:20:24 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Mar 2013 23:20:24 -0400 Subject: [Live-devel] Confirm absolute time playing position on startup In-Reply-To: References: Message-ID: > Is this intended, or is it somehow server dependent? I don't know. Please show the complete RTSP protocol exchange for each case, so I can try to figure out what's happening. > Is there a way to confirm what position is currently playing when starting up a stream? > > Is there a way to ask for the timestamp that's currently being played at any given time? The only way to do this is for you (the client) to measure how much time has elapsed since you issued the last "PLAY" command, and then add this to the absolute time that you specified in the "PLAY" command. (The reason for this is that our client code doesn't parse the absolute time strings at all.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cypher.w at gmail.com Tue Mar 19 21:12:41 2013 From: cypher.w at gmail.com (Cyberman Wu) Date: Wed, 20 Mar 2013 12:12:41 +0800 Subject: [Live-devel] Can I use single BasicUsageEnvironment to handle multiple RTSP connections? Message-ID: openRTSP create a new BasicUsageEnvironment to handle command line specified RTSP, but from source code, it seems that single BasicUsageEnvironment can handle multiple RTSP connections? Is there anyone have tried it? We want to use live555 for a environment to manage more that 100 video streams through RTSP on 4 CPU core, if we use one thread for a RTSP connection thread schedule will use too much CPU time; and the current implementation is to modified select() to no wait, and create our scheduler to scheduler multi-BasicUsageEnvironment, but from profiling, select() for single RTSP/RTP used two much CPU time, and if we wait for all the socket, then check every envir then it got more performance. But that change is just a test and very hard to merge into live555's structure. So, is there any better solution? -- Cyberman Wu From raghav at fossilshale.com Wed Mar 20 06:16:41 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Wed, 20 Mar 2013 07:16:41 -0600 Subject: [Live-devel] How to feed H264 Frame to H264VideoStreamDiscreteFramer Message-ID: <20130320071641.497742qox82u9ebd@mail.fossilshale.com> Hi, Am Getting H264 I-Frame buffer with SPS PPS and Frame(Video data) without any Separation like 0x000001. If i seperate it and send sps and pps in each packet my H264Framer class missing few frames and rtptimestamp diff between first frame and second Frame is very large.so client is Hanged after played first Frame.(vlc) Is there any way to Send I-frame without loss of frames or atleast not much difference between Timestamps. I Tried with H264VideoStreamDiscreteFramer but no much difference in rtp timestamps values. Thanks, Raghav. From finlayson at live555.com Wed Mar 20 21:44:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Mar 2013 00:44:55 -0400 Subject: [Live-devel] Can I use single BasicUsageEnvironment to handle multiple RTSP connections? In-Reply-To: References: Message-ID: > openRTSP create a new BasicUsageEnvironment to handle command line > specified RTSP, but from source code, > it seems that single BasicUsageEnvironment can handle multiple RTSP > connections? Is there anyone have tried it? Yes, the "testRTSPClient" demo application does this. You should use this - rather than "openRTSP" - as a model for your own RTSP client application(s). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caio.klein at gmail.com Wed Mar 20 18:56:53 2013 From: caio.klein at gmail.com (Caio Klein) Date: Wed, 20 Mar 2013 22:56:53 -0300 Subject: [Live-devel] Using the live555 as a "RTSP over HTTP" to "plain RTSP" converter Message-ID: Hi, I was just introduced to openRTSP and see that it works well to address one of my problems which is to initiate the RTSP over HTTP stream from an IP camera that is behind a firewall and can only be reached via HTTP. The second problem is to link this stream to another video server (Wowza) that only initiates plain RTSP sessions. So, this is what I want: IP CAMERA ---- (RTSP over HTTP) --- LIVE555 --- (RTSP) --- WOWZA Is there an easy way to accomplish this or some development is required? Comments are welcomed. Thanks, Caio -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Wed Mar 20 20:50:05 2013 From: kingaceck at 163.com (kingaceck) Date: Thu, 21 Mar 2013 11:50:05 +0800 Subject: [Live-devel] The bug about StreamState::fStartNPT Message-ID: <201303211150047187735@163.com> The function OnDemandServerMediaSubsession::getCurrentNPT() will return the value of the stream's NPT.But after first call this function the value of mostRecentPresentationTime and initialPresentationTime will be reset to zero.When the second call of the function It return the NPT that after first call,not the NPT that from the beginningof the stream.The fStartNPT should record the NPT that from the beginning to the first call. 2013-03-21 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunicoolin at gmail.com Thu Mar 21 10:59:02 2013 From: sunicoolin at gmail.com (sunitha g) Date: Thu, 21 Mar 2013 13:59:02 -0400 Subject: [Live-devel] RTSP streaming Message-ID: Hi, I am developing an applictaion to monitor a live call. I am using AudioStreamSource for streaming. I need some input in following scenario: Streaming the call for some time, after some time keeping the call is on hold at that time i don't receive any data from the source. But I receive some message saying the call is on hold, after receiving this message I am trying to transmit silence to vlc media player. Here before tranmitting silence doStopGettingNext frame is calling and it is closing the client connection. After that I am unable to stream the live call until I send new request. How can I stop closing the connection and how can I tranmit silence to framed source. Please help me. Thanks. From finlayson at live555.com Thu Mar 21 19:53:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Mar 2013 19:53:09 -0700 Subject: [Live-devel] Using the live555 as a "RTSP over HTTP" to "plain RTSP" converter In-Reply-To: References: Message-ID: > I was just introduced to openRTSP and see that it works well to address one of my problems which is to initiate the RTSP over HTTP stream from an IP camera that is behind a firewall and can only be reached via HTTP. > > The second problem is to link this stream to another video server (Wowza) that only initiates plain RTSP sessions. > > So, this is what I want: > > IP CAMERA ---- (RTSP over HTTP) --- LIVE555 --- (RTSP) --- WOWZA > > Is there an easy way to accomplish this Yes, you can use the "LIVE555 Proxy Server": http://www.live555.com/proxyServer/ Note the "-T " option. Note that our proxy sever is a full RTSP server that can handle multiple clients (and serve the proxied stream to each client). Therefore, if you use it, you should not need to use a 'Wowza' server at all. Instead, just use our proxy server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Mar 21 19:57:01 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Mar 2013 19:57:01 -0700 Subject: [Live-devel] The bug about StreamState::fStartNPT In-Reply-To: <201303211150047187735@163.com> References: <201303211150047187735@163.com> Message-ID: <4EDD4460-540A-47CC-9A63-9061E821A42C@live555.com> > But after first call this function the value of mostRecentPresentationTime and initialPresentationTime will be reset to zero. No you're wrong. Those values get set to zero only when the "RTPSink" object is created. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Mar 22 02:26:31 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 22 Mar 2013 10:26:31 +0100 Subject: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? In-Reply-To: References: Message-ID: <2657_1363944395_514C23CB_2657_1869_1_1BE8971B6CFF3A4F97AF4011882AA25501560DD3662D@THSONEA01CMS01P.one.grp> Hi Ralf, Ross, Thanks for the link to the RCF6501 that bring a solution to know the timestamp of the first RTP packet. I follow times to times the ONVIF specification http://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v210.pdf that also propose to insert a NTP timestamp (and other things to allow streaming backward) in the RTP header extension but using a different profile. In previous mail Ross told me that supporting RTP header extension in live555 is not in the roadmap. I will continue to try to find a way. Thanks, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ralf Globisch Envoy? : mercredi 20 mars 2013 09:17 ? : finlayson at live555.com; live-devel at ns.live555.com Objet : Re: [Live-devel] Synchronize the "RTCP" time using RTSP Range ? Michel, I think the probability of loosing the first SR is very minor, SR packets are relatively small in comparison to the video packets and are less likely to get dropped by routers. Or do you have any indication otherwise? Ross's fix should do the trick. However if you want to decrease that probability further RFC6051( http://tools.ietf.org/html/rfc6051 ) might be of use. I'm not sure if it applies here, but from what I recall it's basically an extension header for RTP that includes an NTP timestamp allowing one to do as the name says: rapid synchronisation. You could add this extension header to the first e.g. 5 RTP packets *if* you notice a problem with the first SR being lost. To be sure read the draft to make sure it applies to this use case. > As I said before (and am, I hope, saying for the last time), I'm not going to be doing anything non-standard here. @Ross I would say this is a standard-conformant way? Standard conformant RTP applications *should* ignore the header in any case if the don't understand it, so it shouldn't break other clients... @Michel If you do write the extension header and rapid sync code, you could consider contributing it back to the live555 codebase. Regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Mar 22 14:05:03 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 22 Mar 2013 21:05:03 +0000 Subject: [Live-devel] Confirm absolute time playing position on startup In-Reply-To: References: Message-ID: Is this intended, or is it somehow server dependent? I don't know. Please show the complete RTSP protocol exchange for each case, so I can try to figure out what's happening. I've attached the protocol exchange for the following example: 1. Start up an archive stream without any timestamp. PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0 2. Seek in that stream. Range: clock=20130322T200000.000Z- 3. And then, after teardown, start up the same stream with the same seek-time. PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0 Range: clock=20130322T200000.000Z- The response to #2: Range: clock=20130322T200000Z-20130322T204538Z The PLAY- response to #3: Range: clock=20130320T203757Z-20130322T204804Z So, if I interpret this correctly it's the Cisco server that is inconsistent. I don't see any specific examples of this in the RFC2326, but appears like an error to me. Please comment. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTSP-communication.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Fri Mar 22 17:51:24 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Mar 2013 17:51:24 -0700 Subject: [Live-devel] Confirm absolute time playing position on startup In-Reply-To: References: Message-ID: <534A3A74-AB0B-4435-B693-1491E566FC68@live555.com> > 2. Seek in that stream. > Range: clock=20130322T200000.000Z- > > The response to #2: > Range: clock=20130322T200000Z-20130322T204538Z > > 3. And then, after teardown, start up the same stream with the same seek-time. > PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0 > Range: clock=20130322T200000.000Z- > > The PLAY- response to #3: > Range: clock=20130320T203757Z-20130322T204804Z > > > So, if I interpret this correctly it's the Cisco server that is inconsistent. Yes, that looks like a bug in the server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Anthony at activu.com Fri Mar 22 11:36:31 2013 From: Kevin.Anthony at activu.com (Kevin Anthony) Date: Fri, 22 Mar 2013 14:36:31 -0400 Subject: [Live-devel] SRTP Message-ID: <43C887E316FB57408B046A7D2AFBBDC7AB7741BBDB@exchange> I was wondering what was the status of SRTP support? And what, if anything, I could do to help? Kevin Anthony Software Engineer Activu Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Mar 22 18:06:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Mar 2013 18:06:16 -0700 Subject: [Live-devel] SRTP In-Reply-To: <43C887E316FB57408B046A7D2AFBBDC7AB7741BBDB@exchange> References: <43C887E316FB57408B046A7D2AFBBDC7AB7741BBDB@exchange> Message-ID: <49B3167F-76AD-4B00-BED3-0E8CB9183CAA@live555.com> > I was wondering what was the status of SRTP support? It will happen. When it does, you (and others on this mailing list) will be the first to know :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Mar 22 19:15:05 2013 From: kingaceck at 163.com (kingaceck) Date: Sat, 23 Mar 2013 10:15:05 +0800 Subject: [Live-devel] The bug about StreamState::fStartNPT Message-ID: <201303231015030158125@163.com> > But after first call this function the value of mostRecentPresentationTime and initialPresentationTime will be reset to zero. >No you're wrong. Those values get set to zero only when the "RTPSink" object is created. But I see those values get set to zero when the "RTPSink" continue to play after the pause: OnDemandServerMediaSubsession::startStream(...){ ...... if (rtpSink != NULL) { rtpSink->resetPresentationTimes(); rtpSeqNum = rtpSink->currentSeqNo(); rtpTimestamp = rtpSink->presetNextTimestamp(); } } 2013-03-23 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Mar 22 22:00:26 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Mar 2013 22:00:26 -0700 Subject: [Live-devel] The bug about StreamState::fStartNPT In-Reply-To: <201303231015030158125@163.com> References: <201303231015030158125@163.com> Message-ID: OK, now I understand the problem that you're reporting. (I didn't pay much attention to it before, because you use an unprofessional email address, and many of your previous comments have been bogus.) Yes, the server did have a problem computing the 'current NPT' if it received more than one consecutive "PLAY" request without a "Range:" header. This will be fixed in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Mar 23 04:54:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 23 Mar 2013 04:54:16 -0700 Subject: [Live-devel] New "LIVE555 Streaming Media' code release: RTSP servers now send initial RTCP "SR" packets, for (likely) immediate RTCP synchronization Message-ID: As I noted a few days ago, I have now released a new version (2013.03.23) of the "LIVE555 Streaming Media" code that updates the RTSP server implementation so that an initial RTCP "SR" packet gets sent before the first RTP packet. This will make it likely that the receiver will immediately start getting RTCP-synchronized presentation times. (Note that client application code must still allow for the possibility of initial presentation times not being RTCP-synchronized, in case they don't receive this initial "SR" packet (or in case they are streaming from an older server, or from a server other than ours).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From howtofly at gmail.com Sat Mar 23 23:24:10 2013 From: howtofly at gmail.com (Peng Zheng) Date: Sun, 24 Mar 2013 14:24:10 +0800 Subject: [Live-devel] MP4 video trak samples: were do 'non-frame' NAL units belong? Message-ID: > My questions are: > > 1) What is the correct thing to do with these NAL units in the MP4 file? According to ISO 14496, SPS and PPS should ONLY appears in 'avcC' box. > 2) How can I make openRTSP/live555 create an MP4 file without this > stuttering? Collect NALUs with the same RTP timestamp and send them as a frame into any third party muxer that supporting ISO base media format, e.g. libavformat from FFmpeg. If you set avformat context correctly, it will produce what you want. Peng From caio.klein at gmail.com Sun Mar 24 11:32:05 2013 From: caio.klein at gmail.com (Caio Klein) Date: Sun, 24 Mar 2013 15:32:05 -0300 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" Message-ID: Hi, I've been hitting this error. The process gets into a loop displaying the referred message. The setup is this: AXIS-CAMERA<---(RTSP over HTTP)--->live555ProxyServer<---(RTSP)--->VLC The problem can be easily replicated when stopping the stream on the VLC, but may happen spontaneously while playing after a certain time (~30s). I've already changed the maxRTCPPacketSize on "RTCP.cpp:116" to 1500 with no change on the problem. Any guess on what is happening? Thanks, Caio -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Mar 24 21:10:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 24 Mar 2013 21:10:07 -0700 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: Message-ID: <954EF8C1-AE8E-47FB-93FF-CA1354CA046F@live555.com> > I've been hitting this error. The process gets into a loop displaying the referred message. > > The setup is this: > > AXIS-CAMERA<---(RTSP over HTTP)--->live555ProxyServer<---(RTSP)--->VLC > > The problem can be easily replicated when stopping the stream on the VLC, but may happen spontaneously while playing after a certain time (~30s). > > I've already changed the maxRTCPPacketSize on "RTCP.cpp:116" to 1500 with no change on the problem. > > Any guess on what is happening? Yes. One part of your chain is running an old, buggy version of our software. I assume that your "live555ProxyServer" was built using a recent version of our software. First, replace "VLC" with our "openRTSP" demo application (using the "-T " option). Do you still see the error message? If you don't, then the problem is that "VLC" is running an out-of-date version of our software, and needs to be upgraded. If you still see the error, even when you use "openRTSP" as the client, then the problem is that the 'Axis Camera' is (apparently) using an old version of our software, and *its* firmware will need to be upgraded. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeller at miovision.com Mon Mar 25 06:38:35 2013 From: jkeller at miovision.com (Joel Keller) Date: Mon, 25 Mar 2013 09:38:35 -0400 Subject: [Live-devel] MP4 video trak samples: were do 'non-frame' NAL units belong? In-Reply-To: References: Message-ID: >> My questions are: >> >> 1) What is the correct thing to do with these NAL units in the MP4 file? >According to ISO 14496, SPS and PPS should ONLY appears in 'avcC' box. Thanks for the confirmation. That makes sense to me. >> 2) How can I make openRTSP/live555 create an MP4 file without this >> stuttering? >Collect NALUs with the same RTP timestamp and send them as a frame >into any third >party muxer that supporting ISO base media format, e.g. libavformat >from FFmpeg. >If you set avformat context correctly, it will produce what you want. Just so I'm clear, you are suggesting using live555 for receiving the RTSP/RTP stream, and then passing the NALU stream to another library (ie. libavformat) to containerize the video, correct? I was hoping use only live555 (QuickTimeFileSink) to keep things simple, but using another library would be an option. Looks like I can either figure out how to properly patch the QuickTimeFileSink class to create proper MP4 files, or use another library for containerization. Thanks very much for your response Peng! -Joel On Sun, Mar 24, 2013 at 2:24 AM, Peng Zheng wrote: > > My questions are: > > > > 1) What is the correct thing to do with these NAL units in the MP4 file? > > According to ISO 14496, SPS and PPS should ONLY appears in 'avcC' box. > > > 2) How can I make openRTSP/live555 create an MP4 file without this > > stuttering? > > Collect NALUs with the same RTP timestamp and send them as a frame > into any third > party muxer that supporting ISO base media format, e.g. libavformat > from FFmpeg. > > If you set avformat context correctly, it will produce what you want. > > Peng > _______________________________________________ > 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 jshanab at smartwire.com Mon Mar 25 07:59:05 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Mon, 25 Mar 2013 14:59:05 +0000 Subject: [Live-devel] RTSPServer addServerMediaSession Message-ID: <615FD77639372542BF647F5EBAA2DBC2252DF613@IL-BOL-EXCH01.smartwire.com> In all the examples I have seen, media sessions are added to the server before the event loop is started. Is it safe to call addServerMediaSession while the server is already running? The comment for removeServerMediaSession seems to indicate that I can dynamically remove a session. Of course addServerMediaSession is necessarily called form a different thread than the one event loop. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Mon Mar 25 16:23:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Mar 2013 16:23:13 -0700 Subject: [Live-devel] RTSPServer addServerMediaSession In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252DF613@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC2252DF613@IL-BOL-EXCH01.smartwire.com> Message-ID: <7E03DFAC-7125-4B56-87DC-FBADF50C83F8@live555.com> > In all the examples I have seen, media sessions are added to the server before the event loop is started. > > Is it safe to call addServerMediaSession while the server is already running? Yes. > Of course addServerMediaSession is necessarily called form a different thread than the one event loop. No! You *cannot* call any LIVE555 library function (except "TaskScheduler::triggerEvent()") from a non-event-loop thread. I have explained this in the FAQ, and on this mailing list far many more times than I can count! You can call "addServerMediaSession()" - from the event loop thread - at any time, but if you do this after you've already called "doEventLoop()" - i..e., while you're running in the event loop - then (obviously) you must do this from an event handler. So, you'll need to set up an event handler function that calls "addServerMediaSession()", and set up an event that gets handled by this event handler. The best way to do this from a separate thread is to first (in the LIVE555 thread) create an event trigger using "TashScheduler::createEventTrigger()", and then (in the separate thread) call "TaskScheduler::triggerEvent()". For details, see "UsageEnvironment/include/UsageEnvironment.hh", and also the example in "liveMedia/DeviceSource.cpp". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caio.klein at gmail.com Mon Mar 25 18:31:17 2013 From: caio.klein at gmail.com (Caio Klein) Date: Mon, 25 Mar 2013 22:31:17 -0300 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: <954EF8C1-AE8E-47FB-93FF-CA1354CA046F@live555.com> References: <954EF8C1-AE8E-47FB-93FF-CA1354CA046F@live555.com> Message-ID: Ross, Thanks for the answer, but this sounds like a vulnerability. If any of the system clients (VLC) or sources (cameras) has a buggy code, they may bring the live555ProxyServer down. what is required to make the proxyserver code immune to this kind of external bugs? Thanks, Caio On Mon, Mar 25, 2013 at 1:10 AM, Ross Finlayson wrote: > I've been hitting this error. The process gets into a loop displaying the > referred message. > > The setup is this: > > AXIS-CAMERA<---(RTSP over HTTP)--->live555ProxyServer<---(RTSP)--->VLC > > The problem can be easily replicated when stopping the stream on the VLC, > but may happen spontaneously while playing after a certain time (~30s). > > I've already changed the maxRTCPPacketSize on "RTCP.cpp:116" to 1500 with > no change on the problem. > > Any guess on what is happening? > > > Yes. One part of your chain is running an old, buggy version of our > software. > > I assume that your "live555ProxyServer" was built using a recent version > of our software. > > First, replace "VLC" with our "openRTSP" demo application (using the "-T > " option). Do you still see the error message? If you > don't, then the problem is that "VLC" is running an out-of-date version of > our software, and needs to be upgraded. > > If you still see the error, even when you use "openRTSP" as the client, > then the problem is that the 'Axis Camera' is (apparently) using an old > version of our software, and *its* firmware will need to be upgraded. > > > 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 Mar 25 22:43:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Mar 2013 22:43:09 -0700 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: <954EF8C1-AE8E-47FB-93FF-CA1354CA046F@live555.com> Message-ID: <781DDCFA-49FB-4A76-B8BE-6104834949D2@live555.com> > Thanks for the answer, but this sounds like a vulnerability. If any of the system clients (VLC) or sources (cameras) has a buggy code, they may bring the live555ProxyServer down. They don't 'bring down' the server; they just cause the server to output some error messages about the stream. (Plus, of course, the stream from/to the buggy camera/client won't work well.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caio.klein at gmail.com Tue Mar 26 04:51:12 2013 From: caio.klein at gmail.com (Caio Klein) Date: Tue, 26 Mar 2013 08:51:12 -0300 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: <781DDCFA-49FB-4A76-B8BE-6104834949D2@live555.com> References: <954EF8C1-AE8E-47FB-93FF-CA1354CA046F@live555.com> <781DDCFA-49FB-4A76-B8BE-6104834949D2@live555.com> Message-ID: Hi Ross, I may have hit another problem since the symptom I see is slightly different. The process gets into a loop where the error message is displayed endlessly consuming all the available CPU. It has happened with the proxyserver running on a MACOSX 10.7.5 as well as on an AWS EC2 image. Any clue on what is happening is welcomed. I'm trying to get more details from the problem. Thanks, Caio On Tue, Mar 26, 2013 at 2:43 AM, Ross Finlayson wrote: > Thanks for the answer, but this sounds like a vulnerability. If any of the > system clients (VLC) or sources (cameras) has a buggy code, they may bring > the live555ProxyServer down. > > > They don't 'bring down' the server; they just cause the server to output > some error messages about the stream. (Plus, of course, the stream from/to > the buggy camera/client won't work well.) > > > 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 Tue Mar 26 13:19:28 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 26 Mar 2013 13:19:28 -0700 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: <954EF8C1-AE8E-47FB-93FF-CA1354CA046F@live555.com> <781DDCFA-49FB-4A76-B8BE-6104834949D2@live555.com> Message-ID: <2B866B1D-B4B8-4784-A366-2E128DB21D28@live555.com> > Any clue on what is happening is welcomed. I'm trying to get more details from the problem. I've already told you that your major problem is that your downstream server (camera?) is presumably using an old version of our software, and needs to be upgraded to use a recent version. Please don't bother us with this again until you've done that. (Alternatively, you can just get the back-end server to stream over UDP rather than TCP. Or reduce the server's bitrate, because it's likely approaching (or perhaps even exceeding) the capacity of your network.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghav at fossilshale.com Wed Mar 27 05:53:01 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Wed, 27 Mar 2013 06:53:01 -0600 Subject: [Live-devel] Scheduling Task After Tear Down Session Message-ID: <20130327065301.156053mtb68sxz1p@mail.fossilshale.com> Hi , I am developing an application using testOndemandServer. I have modified the code so that Server can have two schedulers one is default and other created in seperate thread.So,Server running with two doeventloop(). I also modified in MutiFramedRTPSink::sendPacketIfNecessary() function MyTask() = Myenv1->taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this); The problem is when teardown session application getting Segmentation Fault even am unscheduled Delayed task in MediaSink::stopPlaying() function still its trying to call sendNext Function. My Question is: What is the correct place to Call unscheduled Task function? Thanks in Advance, Raghav. From sskim at linkprice.com Thu Mar 28 22:42:11 2013 From: sskim at linkprice.com (Sungsoo Kim) Date: Fri, 29 Mar 2013 14:42:11 +0900 Subject: [Live-devel] RTSP client to send streams to the RTSP server Message-ID: I want to implement a RTSP client to send streams to the RTSP server. But testRTSPClient, openRTSP don't have upstreaming function. Can you show me a sample code to implement it? Thanks, Sungsoo Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Mar 29 01:59:02 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Mar 2013 01:59:02 -0700 Subject: [Live-devel] RTSP client to send streams to the RTSP server In-Reply-To: References: Message-ID: > I want to implement a RTSP client to send streams to the RTSP server. > But testRTSPClient, openRTSP don't have upstreaming function. > Can you show me a sample code to implement it? Sorry, but we don't support this (our servers only 'pull' data; they do not support data getting 'pushed' to them). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Mar 29 09:02:04 2013 From: warren at etr-usa.com (Warren Young) Date: Fri, 29 Mar 2013 10:02:04 -0600 Subject: [Live-devel] [PATCH] Hex decoding for RTSP URLs Message-ID: <5155BAFC.7090709@etr-usa.com> The attached patch adds unconditional URL decoding to the "urlSuffix" part of the URL only. I added this so I could have spaces in file names, though it has other benefits. For one thing, since RTSP specifies that header info is to be interpreted as UTF-8, it means we get Unicode file name support for free on UTF-8 based OSes. In anticipation of any argument as to whether we should do this unconditionally, I refer you to RFC 2616 (HTTP 1.1) section 5.1.2, which says hex decoding MUST be done. Since RTSP is specified as a kind of logical extension to HTTP and doesn't otherwise specify how URIs are to be processed, I suppose this means RTSP also must do URL hex decoding, even if the URL doesn't specify a file name. I further suppose that means we should be applying URL decoding to the other parts of the URL. I don't need it, but all it would take to fix that lack is to call urlDecode() on these other parts, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: live555-rtsp-url-decoding.patch Type: text/x-patch Size: 1159 bytes Desc: not available URL: From finlayson at live555.com Fri Mar 29 15:51:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Mar 2013 15:51:40 -0700 Subject: [Live-devel] [PATCH] Hex decoding for RTSP URLs In-Reply-To: <5155BAFC.7090709@etr-usa.com> References: <5155BAFC.7090709@etr-usa.com> Message-ID: <20E487D7-32AA-4593-A8CD-BBEB310A7C3A@live555.com> Yes, this seems like a reasonable addition, and will be included in the next version of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Fri Mar 29 14:42:16 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 29 Mar 2013 21:42:16 +0000 Subject: [Live-devel] Problems after recent update Message-ID: <615FD77639372542BF647F5EBAA2DBC2252E06E0@IL-BOL-EXCH01.smartwire.com> I updated to live555 with the 03072013 code because of the problems I was having with a new camera. My app still had trouble with a certain camera. I then started connecting to many cameras that had worked in the past with the openRTSP app. A few connect, but most go thru the whole conversation then claim the received a TEARDOWN request. My app sits forever waiting for data after a similar, what looks perfect, RTSP conversation. The ProxyStreamServer works perfectly on all cameras. Does this point to anything specific? I read the changelog and the 3.23.2013 version does not appear to have changes that effect this Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From hackeron at gmail.com Fri Mar 29 16:21:13 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Fri, 29 Mar 2013 23:21:13 +0000 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer Message-ID: Hi there, I have an IP camera that gives MJPEG over RTSP, I'm trying to proxy the stream with: $ live555ProxyServer rtsp://192.168.0.221/live2.sdp When I use the openRTSP client like so: $ ./openRTSP rtsp://127.0.0.1:10110/proxyStream The output looks like this: http://pastie.org/7167135 - live555ProxyServer is vanilla with the only change being I hardcoded it to use port 10110. When I look at the output files, I get valid audio but the video-JPEG-1 file is empty. When I try to play the proxy stream with ffplay, I get: [rtsp @ 0x7f8daa81ae00] Received packet without a start chunk; dropping frame. [rtsp @ 0x7f8daa81ae00] Unimplemented RTP/JPEG type 12 [rtsp @ 0x7f8daa81ae00] Unimplemented RTP/JPEG type 39 [rtsp @ 0x7f8daa81ae00] Unimplemented RTP/JPEG restart marker header. Last message repeated 8 times [rtsp @ 0x7f8daa81ae00] Unimplemented RTP/JPEG type 23 [rtsp @ 0x7f8daa81ae00] Unimplemented RTP/JPEG type 6 [rtsp @ 0x7f8daa81ae00] Unimplemented RTP/JPEG restart marker header. I am able to play the camera stream with ffplay rtsp:// 192.168.0.221/live2.sdp Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Fri Mar 29 16:32:12 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Fri, 29 Mar 2013 23:32:12 +0000 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: Message-ID: The debug output from live555ProxyServer looks like this: $ live555ProxyServer -V rtsp://192.168.0.221/live2.sdp LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.03.07) Opening connection to 192.168.0.221, port 554... RTSP stream, proxying the stream "rtsp://192.168.0.221/live2.sdp" Play this stream using the URL: rtsp://192.168.0.2:10101/proxyStream (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://192.168.0.221/live2.sdp RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.07) Accept: application/sdp Received 418 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, 21 Jun 1970 7:17:3 GMT Content-Base: rtsp://192.168.0.221/live2.sdp/ Content-Type: application/sdp Content-Length: 256 v=0 o=RTSP 1754223 197 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 26 a=control:trackID=2 m=audio 0 RTP/AVP 0 a=control:trackID=3 a=rtpmap:0 pcmu/8000 ProxyServerMediaSession["rtsp://192.168.0.221/live2.sdp/"] added new "ProxyServerMediaSubsession" for RTP/video/JPEG track ProxyServerMediaSession["rtsp://192.168.0.221/live2.sdp/"] added new "ProxyServerMediaSubsession" for RTP/audio/PCMU track ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["JPEG"] ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() ProxyServerMediaSubsession["JPEG"]::closeStreamSource() ProxyServerMediaSubsession["PCMU"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["PCMU"] ProxyServerMediaSubsession["PCMU"]::createNewRTPSink() ProxyServerMediaSubsession["PCMU"]::closeStreamSource() ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 4244287916) Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=2 RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.07) Transport: RTP/AVP;unicast;client_port=58106-58107 ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() ProxyServerMediaSubsession["PCMU"]::createNewStreamSource(session id 4244287916) ProxyServerMediaSubsession["PCMU"]::createNewRTPSink() Received 168 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, 21 Jun 1970 7:17:8 GMT Session: 175423604;timeout=80 Transport: RTP/AVP;unicast;client_port=58106-58107;server_port=5556-5557 ProxyRTSPClient["rtsp://192.168.0.221/live2.sdp/"]::continueAfterSETUP(): head codec: JPEG; numSubsessions 2 queue: JPEG PCMU Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=3 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.07) Transport: RTP/AVP;unicast;client_port=56070-56071 Session: 175423604 Received 168 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, 21 Jun 1970 7:17:8 GMT Session: 175423604;timeout=80 Transport: RTP/AVP;unicast;client_port=56070-56071;server_port=5558-5559 ProxyRTSPClient["rtsp://192.168.0.221/live2.sdp/"]::continueAfterSETUP(): head codec: PCMU; numSubsessions 2 queue: PCMU Sending request: PLAY rtsp://192.168.0.221/live2.sdp/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.07) Session: 175423604 Received 262 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, 21 Jun 1970 7:17:8 GMT Session: 175423604;timeout=80 RTP-Info: url=rtsp:// 192.168.0.221/live2.sdp/trackID=2;seq=0;rtptime=0,url=rtsp://192.168.0.221/live2.sdp/trackID=3;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Sending request: OPTIONS rtsp://192.168.0.221/live2.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.07) Received 144 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, 21 Jun 1970 7:17:33 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Mar 29 16:55:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Mar 2013 16:55:07 -0700 Subject: [Live-devel] Problems after recent update In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252E06E0@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC2252E06E0@IL-BOL-EXCH01.smartwire.com> Message-ID: <44037210-4BE5-4867-85F4-DFDD37EE45D7@live555.com> > I updated to live555 with the 03072013 code because of the problems I was having with a new camera. > > My app still had trouble with a certain camera. > > I then started connecting to many cameras that had worked in the past with the openRTSP app. It wasn't clear from your message whether: 1/ "openRTSP" works OK with this camera with the old version of the LIVE555 code, but not with the new version, or 2/ "openRTSP" works OK with this camera with both the old and new version of the LIVE555 code, but *your application* works only with the new version of the code. If it's 2/, then unfortunately I can't help you much (because obviously I don't know how your application works). But if it's 1/, then please post the complete RTSP protocol exchange from a non-working "openRTSP" command. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Mar 29 17:05:24 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Mar 2013 17:05:24 -0700 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: Message-ID: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> > I have an IP camera that gives MJPEG over RTSP, I'm trying to proxy the stream with: > > $ live555ProxyServer rtsp://192.168.0.221/live2.sdp > > When I use the openRTSP client like so: > > $ ./openRTSP rtsp://127.0.0.1:10110/proxyStream > > The output looks like this: http://pastie.org/7167135 What happens when you try running "openRTSP" directly on the IP camera stream (i.e., without using a proxy server in the middle)? What happens when you try viewing the stream using VLC - both directly from the IP camera, and indirectly, through the proxy? I suspect that your problem is network packet loss - which is often a problem when streaming a low-efficiency codec such as JPEG. JPEG frames are usually *huge*, and each JPEG frame gets packed into many (often dozens!) of RTP packets. If even one of these RTP packets gets lost, the entire JPEG frame will get discarded by the receiver. This situation is worse if you have a proxy server in the middle, because it means that - for a complete JPEG frame to make it end-to-end from the IP camera to your receiving client - there must be no packet loss either on the camera->proxy link, or in the proxy->client link. Your best solution (especially as appears to be just a hobby for you) is to use a better IP camera - one that streams using a better codec (such as H.264). (In 2013, nobody should be streaming MJPEG anymore.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sskim at linkprice.com Fri Mar 29 17:07:45 2013 From: sskim at linkprice.com (Sungsoo Kim) Date: Sat, 30 Mar 2013 09:07:45 +0900 Subject: [Live-devel] RTSP client to send streams to the RTSP server In-Reply-To: References: Message-ID: Thank you for your kind reply! I am sorry I didn't say which kind of media server I am using. I understand live555 server does not support clients to push stream. I am using a Wowza server which supports the function. I have to implement a RTSP client in a embedded system which will be installed in a car, it will use 3G or 4G not WiFi. As you know it will be moving and its IP address can be changed from time to time, that's why I need pushing stream from clients to the server. Basically I understand RTSP protocol, but I want to see a sample source code which includes ANNOUNCE and RECORD in the RTSP client. Thanks, Sungsoo Kim On Fri, Mar 29, 2013 at 5:59 PM, Ross Finlayson wrote: > I want to implement a RTSP client to send streams to the RTSP server. > But testRTSPClient, openRTSP don't have upstreaming function. > Can you show me a sample code to implement it? > > > Sorry, but we don't support this (our servers only 'pull' data; they do > not support data getting 'pushed' to them). > > 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 hackeron at gmail.com Fri Mar 29 17:41:22 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Sat, 30 Mar 2013 00:41:22 +0000 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: The MJPEG stream is only 3fps, there is no packet loss, it's a 1gbit network and nothing else is streaming on the network. Opening the camera RTSP stream with VLC works fine, no errors, opening the RTSPRoxy stream with VLC, I get audio only. Opening direct from the camera with openRTSP works just fine also and I get a playable video-JPEG-1 file without any errors: ./openRTSP rtsp://192.168.0.221/live2.sdp Opening connection to 192.168.0.221, port 554... ...remote connection opened Sending request: OPTIONS rtsp://192.168.0.221/live2.sdp RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.07) Received 144 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, 21 Jun 1970 8:25:17 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: DESCRIBE rtsp://192.168.0.221/live2.sdp RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.07) Accept: application/sdp Received 418 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, 21 Jun 1970 8:25:17 GMT Content-Base: rtsp://192.168.0.221/live2.sdp/ Content-Type: application/sdp Content-Length: 255 v=0 o=RTSP 1758317 90 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 26 a=control:trackID=2 m=audio 0 RTP/AVP 0 a=control:trackID=3 a=rtpmap:0 pcmu/8000 Opened URL "rtsp://192.168.0.221/live2.sdp", returning a SDP description: v=0 o=RTSP 1758317 90 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 26 a=control:trackID=2 m=audio 0 RTP/AVP 0 a=control:trackID=3 a=rtpmap:0 pcmu/8000 Created receiver for "video/JPEG" subsession (client ports 62178-62179) Created receiver for "audio/PCMU" subsession (client ports 54648-54649) Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=2 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.07) Transport: RTP/AVP;unicast;client_port=62178-62179 Received 169 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, 21 Jun 1970 8:25:17 GMT Session: 175832465;timeout=80 Transport: RTP/AVP;unicast;client_port=62178-62179;server_port=5556-5557 Setup "video/JPEG" subsession (client ports 62178-62179) Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=3 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.07) Transport: RTP/AVP;unicast;client_port=54648-54649 Session: 175832465 Received 169 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, 21 Jun 1970 8:25:17 GMT Session: 175832465;timeout=80 Transport: RTP/AVP;unicast;client_port=54648-54649;server_port=5558-5559 Setup "audio/PCMU" subsession (client ports 54648-54649) Created output file: "video-JPEG-1" Created output file: "audio-PCMU-2" Sending request: PLAY rtsp://192.168.0.221/live2.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.07) Session: 175832465 Range: npt=0.000- Received 263 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, 21 Jun 1970 8:25:17 GMT Session: 175832465;timeout=80 RTP-Info: url=rtsp:// 192.168.0.221/live2.sdp/trackID=2;seq=0;rtptime=0,url=rtsp://192.168.0.221/live2.sdp/trackID=3;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Started playing session Receiving streamed data (signal with "kill -HUP 14842" or "kill -USR1 14842" to terminate)... On 30 March 2013 00:05, Ross Finlayson wrote: > I have an IP camera that gives MJPEG over RTSP, I'm trying to proxy the > stream with: > > $ live555ProxyServer rtsp://192.168.0.221/live2.sdp > > When I use the openRTSP client like so: > > $ ./openRTSP rtsp://127.0.0.1:10110/proxyStream > > The output looks like this: http://pastie.org/7167135 > > > What happens when you try running "openRTSP" directly on the IP camera > stream (i.e., without using a proxy server in the middle)? > > What happens when you try viewing the stream using VLC - both directly > from the IP camera, and indirectly, through the proxy? > > I suspect that your problem is network packet loss - which is often a > problem when streaming a low-efficiency codec such as JPEG. JPEG frames > are usually *huge*, and each JPEG frame gets packed into many (often > dozens!) of RTP packets. If even one of these RTP packets gets lost, the > entire JPEG frame will get discarded by the receiver. > > This situation is worse if you have a proxy server in the middle, because > it means that - for a complete JPEG frame to make it end-to-end from the IP > camera to your receiving client - there must be no packet loss either on > the camera->proxy link, or in the proxy->client link. > > Your best solution (especially as appears to be just a hobby for you) is > to use a better IP camera - one that streams using a better codec (such as > H.264). (In 2013, nobody should be streaming MJPEG anymore.) > > > 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 Fri Mar 29 20:02:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Mar 2013 20:02:05 -0700 Subject: [Live-devel] RTSP client to send streams to the RTSP server In-Reply-To: References: Message-ID: <985D76D9-E4A3-4FE9-A7F6-7B5599EDC408@live555.com> > Basically I understand RTSP protocol, but I want to see a sample > source code which includes ANNOUNCE and RECORD in the > RTSP client. You may wish to look at the code for the "testMPEG1or2AudioVideoToDarwin" and "testMPEG4VideoToDarwin" demo applications - in the "testProgs" directory. These applications were used to 'inject' data streams into an Apple 'Darwin' streaming server. 'Wowza' may (or may not) use the same protocol. This code is no longer supported, so don't expect any help with it if you decide to use it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Mar 29 20:24:50 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Mar 2013 20:24:50 -0700 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: OK, I think what's happening here is that although your JPEG frame rate is low, your JPEG frame sizes are exceeding 60000 bytes - the default buffer size that's used by the proxy's "RTPSink"s. Try adding the following line to "live555ProxyServer.cpp" - at the start of "main()": OutPacketBuffer::maxSize = 100000; and recompile. If that doesn't work, try increasing to 200000, etc., depending on the size of your frames. Let us know what size works for you, and I'll update the proxy server code (in the next release of the code) to accommodate this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Sat Mar 30 06:30:57 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Sat, 30 Mar 2013 13:30:57 +0000 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: No change :( After recompiling with OutPacketBuffer::maxSize = 200000; at the start of main(), I get this: $ live555ProxyServer -V rtsp://192.168.0.221/live2.sdp LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.03.23) Opening connection to 192.168.0.221, port 554... RTSP stream, proxying the stream "rtsp://192.168.0.221/live2.sdp" Play this stream using the URL: rtsp://192.168.0.2:8554/proxyStream (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://192.168.0.221/live2.sdp RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Accept: application/sdp Received 420 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, 21 Jun 1970 21:15:13 GMT Content-Base: rtsp://192.168.0.221/live2.sdp/ Content-Type: application/sdp Content-Length: 256 v=0 o=RTSP 1804513 653 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 26 a=control:trackID=2 m=audio 0 RTP/AVP 0 a=control:trackID=3 a=rtpmap:0 pcmu/8000 ProxyServerMediaSession["rtsp://192.168.0.221/live2.sdp/"] added new "ProxyServerMediaSubsession" for RTP/video/JPEG track ProxyServerMediaSession["rtsp://192.168.0.221/live2.sdp/"] added new "ProxyServerMediaSubsession" for RTP/audio/PCMU track ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["JPEG"] ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() ProxyServerMediaSubsession["JPEG"]::closeStreamSource() ProxyServerMediaSubsession["PCMU"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["PCMU"] ProxyServerMediaSubsession["PCMU"]::createNewRTPSink() ProxyServerMediaSubsession["PCMU"]::closeStreamSource() ProxyServerMediaSubsession["JPEG"]::createNewStreamSource(session id 2935397515) Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=2 RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Transport: RTP/AVP;unicast;client_port=59232-59233 ProxyServerMediaSubsession["JPEG"]::createNewRTPSink() ProxyServerMediaSubsession["PCMU"]::createNewStreamSource(session id 2935397515) ProxyServerMediaSubsession["PCMU"]::createNewRTPSink() Received 170 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, 21 Jun 1970 21:15:15 GMT Session: 180452337;timeout=80 Transport: RTP/AVP;unicast;client_port=59232-59233;server_port=5556-5557 ProxyRTSPClient["rtsp://192.168.0.221/live2.sdp/"]::continueAfterSETUP(): head codec: JPEG; numSubsessions 2 queue: JPEG PCMU Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=3 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Transport: RTP/AVP;unicast;client_port=52400-52401 Session: 180452337 Received 170 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, 21 Jun 1970 21:15:15 GMT Session: 180452337;timeout=80 Transport: RTP/AVP;unicast;client_port=52400-52401;server_port=5558-5559 ProxyRTSPClient["rtsp://192.168.0.221/live2.sdp/"]::continueAfterSETUP(): head codec: PCMU; numSubsessions 2 queue: PCMU Sending request: PLAY rtsp://192.168.0.221/live2.sdp/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Session: 180452337 Received 264 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, 21 Jun 1970 21:15:15 GMT Session: 180452337;timeout=80 RTP-Info: url=rtsp:// 192.168.0.221/live2.sdp/trackID=2;seq=0;rtptime=0,url=rtsp://192.168.0.221/live2.sdp/trackID=3;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Sending request: OPTIONS rtsp://192.168.0.221/live2.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, 21 Jun 1970 21:15:43 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN ``` >From client: ``` $ ./openRTSP rtsp://192.168.0.2:8554/proxyStream Opening connection to 192.168.0.2, port 8554... ...remote connection opened Sending request: OPTIONS rtsp://192.168.0.2:8554/proxyStream RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Mar 30 2013 13:25:47 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://192.168.0.2:8554/proxyStream RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Accept: application/sdp Received 680 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Sat, Mar 30 2013 13:25:47 GMT Content-Base: rtsp://192.168.0.2:8554/proxyStream/ Content-Type: application/sdp Content-Length: 511 v=0 o=- 1364649945494663 1 IN IP4 192.168.0.2 s=LIVE555 Streaming Media v2013.03.23 i=LIVE555 Streaming Media v2013.03.23 t=0 0 a=tool:LIVE555 Streaming Media v2013.03.23 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.03.23 a=x-qt-text-inf:LIVE555 Streaming Media v2013.03.23 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:96 JPEG/90000 a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:97 PCMU/8000 a=control:track2 Opened URL "rtsp://192.168.0.2:8554/proxyStream", returning a SDP description: v=0 o=- 1364649945494663 1 IN IP4 192.168.0.2 s=LIVE555 Streaming Media v2013.03.23 i=LIVE555 Streaming Media v2013.03.23 t=0 0 a=tool:LIVE555 Streaming Media v2013.03.23 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.03.23 a=x-qt-text-inf:LIVE555 Streaming Media v2013.03.23 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:96 JPEG/90000 a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:97 PCMU/8000 a=control:track2 Created receiver for "video/JPEG" subsession (client ports 51252-51253) Created receiver for "audio/PCMU" subsession (client ports 60734-60735) Sending request: SETUP rtsp://192.168.0.2:8554/proxyStream/track1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Transport: RTP/AVP;unicast;client_port=51252-51253 Received 201 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Sat, Mar 30 2013 13:25:47 GMT Transport: RTP/AVP;unicast;destination=192.168.0.2;source=192.168.0.2;client_port=51252-51253;server_port=6970-6971 Session: AEF69C8B Setup "video/JPEG" subsession (client ports 51252-51253) Sending request: SETUP rtsp://192.168.0.2:8554/proxyStream/track2 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Transport: RTP/AVP;unicast;client_port=60734-60735 Session: AEF69C8B Received 201 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Sat, Mar 30 2013 13:25:47 GMT Transport: RTP/AVP;unicast;destination=192.168.0.2;source=192.168.0.2;client_port=60734-60735;server_port=6972-6973 Session: AEF69C8B Setup "audio/PCMU" subsession (client ports 60734-60735) Created output file: "video-JPEG-1" Created output file: "audio-PCMU-2" Sending request: PLAY rtsp://192.168.0.2:8554/proxyStream/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Session: AEF69C8B Range: npt=0.000- Received 264 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Sat, Mar 30 2013 13:25:47 GMT Range: npt=0.000- Session: AEF69C8B RTP-Info: url=rtsp:// 192.168.0.2:8554/proxyStream/track1;seq=749;rtptime=1881744642,url=rtsp://192.168.0.2:8554/proxyStream/track2;seq=31137;rtptime=3404576387 Started playing session Receiving streamed data (signal with "kill -HUP 80281" or "kill -USR1 80281" to terminate)... ``` When I kill the client, I see this: ``` $ ls -ltr | tail -n 2 -rw-r--r-- 1 hackeron staff 0 30 Mar 13:25 video-JPEG-1 -rw-r--r-- 1 hackeron staff 806400 30 Mar 13:27 audio-PCMU-2 ``` If on the other hand I open camera directly, I see: ``` ./openRTSP rtsp://192.168.0.221/live2.sdp Opening connection to 192.168.0.221, port 554... ...remote connection opened Sending request: OPTIONS rtsp://192.168.0.221/live2.sdp RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, 21 Jun 1970 21:17:37 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: DESCRIBE rtsp://192.168.0.221/live2.sdp RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Accept: application/sdp Received 419 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, 21 Jun 1970 21:17:37 GMT Content-Base: rtsp://192.168.0.221/live2.sdp/ Content-Type: application/sdp Content-Length: 255 v=0 o=RTSP 1804658 27 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 26 a=control:trackID=2 m=audio 0 RTP/AVP 0 a=control:trackID=3 a=rtpmap:0 pcmu/8000 Opened URL "rtsp://192.168.0.221/live2.sdp", returning a SDP description: v=0 o=RTSP 1804658 27 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 26 a=control:trackID=2 m=audio 0 RTP/AVP 0 a=control:trackID=3 a=rtpmap:0 pcmu/8000 Created receiver for "video/JPEG" subsession (client ports 54300-54301) Created receiver for "audio/PCMU" subsession (client ports 64828-64829) Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=2 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Transport: RTP/AVP;unicast;client_port=54300-54301 Received 170 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, 21 Jun 1970 21:17:38 GMT Session: 180466576;timeout=80 Transport: RTP/AVP;unicast;client_port=54300-54301;server_port=5556-5557 Setup "video/JPEG" subsession (client ports 54300-54301) Sending request: SETUP rtsp://192.168.0.221/live2.sdp/trackID=3 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Transport: RTP/AVP;unicast;client_port=64828-64829 Session: 180466576 Received 170 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, 21 Jun 1970 21:17:38 GMT Session: 180466576;timeout=80 Transport: RTP/AVP;unicast;client_port=64828-64829;server_port=5558-5559 Setup "audio/PCMU" subsession (client ports 64828-64829) Created output file: "video-JPEG-1" Created output file: "audio-PCMU-2" Sending request: PLAY rtsp://192.168.0.221/live2.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.03.23) Session: 180466576 Range: npt=0.000- Received 264 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, 21 Jun 1970 21:17:38 GMT Session: 180466576;timeout=80 RTP-Info: url=rtsp:// 192.168.0.221/live2.sdp/trackID=2;seq=0;rtptime=0,url=rtsp://192.168.0.221/live2.sdp/trackID=3;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Started playing session Receiving streamed data (signal with "kill -HUP 80566" or "kill -USR1 80566" to terminate)... MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 22323 bytes of trailing data will be dropped! FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 22323 bytes of trailing data was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 122323 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 22327 bytes of trailing data will be dropped! FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 22327 bytes of trailing data was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 122327 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 22259 bytes of trailing data will be dropped! FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 22259 bytes of trailing data was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 122259 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 22213 bytes of trailing data will be dropped! FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 22213 bytes of trailing data was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 122213 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 22068 bytes of trailing data will be dropped! FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 22068 bytes of trailing data was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 122068 ``` When I kill the client I see: ``` ls -ltr | tail -n 2 -rw-r--r-- 1 hackeron staff 500000 30 Mar 13:28 video-JPEG-1 -rw-r--r-- 1 hackeron staff 12800 30 Mar 13:28 audio-PCMU-2 ``` Any ideas? On 30 March 2013 03:24, Ross Finlayson wrote: > OK, I think what's happening here is that although your JPEG frame rate is > low, your JPEG frame sizes are exceeding 60000 bytes - the default buffer > size that's used by the proxy's "RTPSink"s. > > Try adding the following line to "live555ProxyServer.cpp" - at the start > of "main()": > OutPacketBuffer::maxSize = 100000; > > and recompile. If that doesn't work, try increasing to 200000, etc., > depending on the size of your frames. Let us know what size works for you, > and I'll update the proxy server code (in the next release of the code) to > accommodate this. > > > 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 Sat Mar 30 06:42:02 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 30 Mar 2013 06:42:02 -0700 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: <74CEDC73-6A47-4C7F-8BAE-D254841B3225@live555.com> > No change :( > > After recompiling with OutPacketBuffer::maxSize = 200000; at the start of main(), I get this: Are your JPEG frames less than 200000 bytes in size? If so, then I can't explain your problem. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nemec at atlas.cz Sat Mar 30 07:42:09 2013 From: a.nemec at atlas.cz (=?utf-8?q?Alexandr_N=C4=9Bmec?=) Date: Sat, 30 Mar 2013 15:42:09 +0100 Subject: [Live-devel] =?utf-8?q?Unable_to_proxy_mjpeg_with_live555ProxySer?= =?utf-8?q?ver?= In-Reply-To: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: <20130330154209.4B6A28DD@atlas.cz> Hi Ross, ? just as a side note (and because this is not the first time you are saying this), your last sentence about that nobody should be streaming MJPEG in 2013 is wrong. Well, despite my e-mail address, I am not a casual hobbyist :), but since there is a little to none protection in mail lists in general against spammers collecting addresses from such lists, we typically do not use our company's domain names for mail lists. ? Please understand that in our industry (video surveillance software solutions) MJPEG is still widely used, in fact there are numerous reasons for using MJPEG in security industry, such as ? - security operators often need to view a high number of cameras at once in their applications at higher frame rates, which can be done with much less CPU power when using MJPEG. Decoding H264 is much more CPU intensive and when security cameras are installed in local networks, where bandwidth is not an issue, MJPEG is the better choice here, ? - many video analytics applications often?prefer MJPEG over H264 video as the input, because?such applications?are CPU intensive and often reduce the load by not?decoding the entire stream but just some of the frames which can be done better?with MJPEG because of no interframe compression, ? - mobile platforms have certain limitations regarding H264 - even with the latest Android (Jelly Bean)?and the new Google's Media Codec API you cannot effectively display more H264 streams at once. To give the security operator a chance to view 4 or 9 cameras in his device (what he really needs to), MJPEG (with limited resolution)?is again?the better choice than H264. ? And there are other reasons. So please understand that the bandwidth (or frame size) is not the only factor making a given codec better than another one, as this is application specific. Of course, if there is a limited bandwidth and one needs full frame rate video, H264 will be the ideal choice with no chance for MJPEG to compete here because of the large frame sizes. ? Please note, that all technological leaders in the IP camera world (like Axis, Bosch, Sony, Samsung, Panasonic, Brickcom, Vivotek, IQinVision?and many others) are still adding (and will continue to add) MJPEG to their IP cameras (even in 2013 models :), so, as you can see, I am standing not alone here :). They are doing it for a reason. ? Last but not least, according to ONVIF for example, an IP camera MUST support MJPEG, a QVGA MJPEG stream is mandatory for every ONVIF compliant model for better interoperability and flexibility. So it seems that supporting MJPEG in Live555 is still a good idea, even in 2013 ;). ? Have a nice day. ? Alex ? ? ______________________________________________________________ > Od: "Ross Finlayson" > Komu: "LIVE555 Streaming Media - development & use" > Datum: 30.03.2013 01:25 > P?edm?t: Re: [Live-devel] Unable to proxy mjpeg with live555ProxyServer > I have an IP camera that gives MJPEG over RTSP, I'm trying to proxy the stream with:$ live555ProxyServer rtsp://192.168.0.221/live2.sdp When I use the openRTSP client like so:$ ./openRTSP rtsp://127.0.0.1:10110/proxyStream The output looks like this: http://pastie.org/7167135 What happens when you try running "openRTSP" directly on the IP camera stream (i.e., without using a proxy server in the middle)?What happens when you try viewing the stream using VLC - both directly from the IP camera, and indirectly, through the proxy?I suspect that your problem is network packet loss - which is often a problem when streaming a low-efficiency codec such as JPEG. ?JPEG frames are usually *huge*, and each JPEG frame gets packed into many (often dozens!) of RTP packets. ?If even one of these RTP packets gets lost, the entire JPEG frame will get discarded by the receiver.This situation is worse if you have a proxy server in the middle, because it means that - for a complete JPEG frame to make it end-to-end from the IP camera to your receiving client - there must be no packet loss either on the camera->proxy link, or in the proxy->client link.Your best solution (especially as appears to be just a hobby for you) is to use a better IP camera - one that streams using a better codec (such as H.264). ?(In 2013, nobody should be streaming MJPEG anymore.) 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 Sat Mar 30 14:42:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 30 Mar 2013 14:42:51 -0700 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: <20130330154209.4B6A28DD@atlas.cz> References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> <20130330154209.4B6A28DD@atlas.cz> Message-ID: <695FCEC2-99C3-4E2C-BB66-CB17BDD41235@live555.com> MJPEG streaming is tolerable if you're in a high-bandwidth environment with very little packet loss. It's when people try to use it outside such environments that they run into trouble. And 'ONVIF' is an industry consortium (that we do not belong to) - not a standards organizations. The relevant standards organization here (the one that we belong to, and whose specifications we try to adhere to) is the IETF. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Mar 30 19:26:56 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 30 Mar 2013 19:26:56 -0700 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: OK, I figured out the problem - and it's bad news. Our proxying code currently cannot handle the proxying of JPEG video (or, incidentally, AMR audio) streams. The basic problem with proxying MJPEG is that the output of the "RTPSource" object is a complete JPEG frame, which is not the data format that gets fed into the proxy's corresponding "RTPSink" object. I've just installed a new version of the code that outputs an error message (if in 'verbose' mode) if you try to proxy a JPEG video stream. With a bit of hackery, I think I should be able to update the code so that it can proxy JPEG video streams OK. (So Roman, please leave your test server running for now.) If/when I do this, I'll let you all know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Mar 31 20:55:28 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 31 Mar 2013 20:55:28 -0700 Subject: [Live-devel] Unable to proxy mjpeg with live555ProxyServer In-Reply-To: References: <3A4C6A4E-46C2-4769-AC0A-FD0AA665DF5E@live555.com> Message-ID: <312B0522-0F82-4578-B87F-BCB148DBEADC@live555.com> FYI, I've now installed a new version (2013.04.01) of the "LIVE555 Streaming Media" code that now (with a bit of hackery) supports proxying JPEG/RTP streams. (Roman, thanks again for making your test stream available.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Sun Mar 31 20:22:12 2013 From: kingaceck at 163.com (kingaceck) Date: Mon, 1 Apr 2013 11:22:12 +0800 Subject: [Live-devel] rtp synchronization Message-ID: <201304011122114372010@163.com> Hi I use live555 to transport h264 and aac stream from mp4 file.At the client when I play it automatic (don't clike the progress bar) the video and audio can synchronization. But when I clicked on the progress bar (can call seekStreamSource(...) ) the video and audio can not synchronization.The audio lag . I try to resolve it for many days,but I cant by now.Can you give me your suggestions .Tank you very very very much! void FfmpegDemux::seekStreamSource(double seekNPT) { //format_ctx_->streams[this->server_demux_->audio_stream_id_]->time_base int64_t pos = (int64_t)(seekNPT * AV_TIME_BASE); pos = av_rescale_q(pos, AV_TIME_BASE_Q,format_ctx_->streams[this->server_demux_->audio_stream_id_]->time_base); av_seek_frame(format_ctx_, this->server_demux_->audio_stream_id_, pos, AVSEEK_FLAG_ANY); //timestamp is usec AVSEEK_FLAG_ANY AVSEEK_FLAG_BACKWARD //av_seek_frame(format_ctx_, -1, seekNPT*1000*1000, AVSEEK_FLAG_BACKWARD); //timestamp is usec // if(seekNPT>0) // avcodec_flush_buffers(format_ctx_->streams[this->server_demux_->audio_stream_id_]->codec); } 2013-04-01 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: