From finlayson at live555.com Sun Apr 1 16:14:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 1 Apr 2012 16:14:50 -0700 Subject: [Live-devel] Frame loss In-Reply-To: References: Message-ID: > We seem to have occasional frame loss when connecting to an Aviglion camera, streaming H264 using RTP over RTSP. We occasionally see blurring in the video. After some inspection we see that sometimes a H264 key frame is missing. Taking a wireshark trace shows it's not a camera problem, the key frame is transmitted and complete ( all RTP timestamps are present up till the frame with the marker bit set ), so livemedia should not throw it away. I suspect that what's happening here is that the buffer that your client is using (i.e., the buffer used by the object that's receiving from the "RTPSource" object) is too small for some of your H.264 key frames. If this is the case, then even though the RTP reception code is receiving all of the frame data OK (because you're receiving RTP-over-RTSP), it has to truncate the frame (i.e., throw away some data at the end of the frame), because the buffer that it's reading into is too small. You can verify this by looking at the point in your client code where you call "getNextFrame()" on the "MediaSubsession" 'readSource()'. When you do this, you give "getNextFrame()" an 'after getting' callback function. When this function gets called, note the "numTruncatedBytes" parameter. If - as I suspect - your buffer size (i.e., the size of the buffer that you gave to "getNextFrame()") is too small, then the "numTruncatedBytes" parameter will be >0. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aviadr1 at gmail.com Mon Apr 2 06:14:49 2012 From: aviadr1 at gmail.com (aviad rozenhek) Date: Mon, 2 Apr 2012 16:14:49 +0300 Subject: [Live-devel] forcing a session to stop Message-ID: The android RTSP client library has many bugs and issues. sometimes it gets stuck during the prepare stage, and there's no way to stop it using its API. I'd like to stop the server session it is connected to, in order to 'convince' the RTSP client to go away. so essentially i'm lookling to do something like: RTSPServer::RTSPClientSession* client = get_the_stuck_client_session(); delete client; well that's the general idea, not the actual code. the problem is obviously, that RTSPServer::RTSPClientSession is sort-of an internal class, I didn't find a way to enumerate the currently running sessions, or tell them to stop. help appreciated, -- *Aviad Rozenhek *Media Technologies Architect RayV Technologies Mobile: *+972 54 9764671 *Tel: +972 3 7979200 Ext:216 www.rayv.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 3 00:45:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Apr 2012 00:45:38 -0700 Subject: [Live-devel] forcing a session to stop In-Reply-To: References: Message-ID: <1243A344-1019-4532-B8A0-CCB638B75172@live555.com> > The android RTSP client library has many bugs and issues. > sometimes it gets stuck during the prepare stage, and there's no way to stop it using its API. > > I'd like to stop the server session it is connected to, in order to 'convince' the RTSP client to go away. > so essentially i'm lookling to do something like: > RTSPServer::RTSPClientSession* client = get_the_stuck_client_session(); > delete client; Yes, deleting a "RTSPServer::RTSPClientSession" object is the right way to do this. > > well that's the general idea, not the actual code. > the problem is obviously, that RTSPServer::RTSPClientSession is sort-of an internal class, I didn't find a way to enumerate the currently running sessions, or tell them to stop. That's right, there's no mechanism built into the supplied code for doing this. However, this reply (to a similar question last year) should help you: http://lists.live555.com/pipermail/live-devel/2011-June/013446.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos.duran at justsync.com Tue Apr 3 07:41:12 2012 From: carlos.duran at justsync.com (Carlos Duran) Date: Tue, 3 Apr 2012 10:41:12 -0400 Subject: [Live-devel] iPhone iOS5.1 make error Message-ID: <760C7E8F-AA3C-4AD8-B655-EE5C688FF5B9@isaacdaniel.com> Hi, I am trying to generate iOS static libraries for use in iOS5.1 SDK, (latest and greatest). When I run this command in the terminal: make iphoneos I get the following error: make: *** No rule to make target `iphoneos'. Stop. Unfortunately, a config.log file is not generated, what could be the problem? Thanks in advance Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 3 07:46:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Apr 2012 07:46:42 -0700 Subject: [Live-devel] iPhone iOS5.1 make error In-Reply-To: <760C7E8F-AA3C-4AD8-B655-EE5C688FF5B9@isaacdaniel.com> References: <760C7E8F-AA3C-4AD8-B655-EE5C688FF5B9@isaacdaniel.com> Message-ID: > I am trying to generate iOS static libraries for use in iOS5.1 SDK, (latest and greatest). > > When I run this command in the terminal: > make iphoneos > > I get the following error: > make: *** No rule to make target `iphoneos'. Stop. > > Unfortunately, a config.log file is not generated, what could be the problem? The problem is that you didn't properly read the instructions. You should have run genMakefiles iphoneos and then make Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachit81 at gmail.com Tue Apr 3 10:01:40 2012 From: rachit81 at gmail.com (Rachit shah) Date: Tue, 3 Apr 2012 22:31:40 +0530 Subject: [Live-devel] segmentation fault on testRTSPClient Message-ID: Hi, I am developing application based on testRTSPClient. I have modified testRTSPClient.cpp file's shutdownStream routine as per below steps. commented -> exit(exitcode) Enable WatchVariable which is used when calling doEventloop(&WatchVariable) Uncomment following line TaskScheduler *scheduler = &(env.taskscheduler); env.reclaim(); delete scheduler; When I run testRTSPClient with two rtsp url argument,testRTSPClient application is giving segmetation fault at end of application. what would be reason of segmentation fault? Application isn't giving segmentation fault if i again comment the above uncommented lines. Thanks, Rachit -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 3 20:15:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Apr 2012 20:15:08 -0700 Subject: [Live-devel] segmentation fault on testRTSPClient In-Reply-To: References: Message-ID: <98AA7B82-3AAB-472E-9164-9569CC3E5088@live555.com> (First, please don't send the same question to the list multiple times. As noted in the FAQ, your messages are being moderated (delayed) because you're using an unprofessional email address. (A reminder once again to everyone: Your messages will be taken much more seriously if you use a professional email address.)) > Uncomment following line > > TaskScheduler *scheduler = &(env.taskscheduler); > env.reclaim(); > delete scheduler; > > When I run testRTSPClient with two rtsp url argument,testRTSPClient application is giving segmetation fault at end of application. The problem here is that I didn't make it clear enough that those three lines - that you uncommented - cannot remain in the same place. Instead, they can only be executed outside the event loop - i.e., after "doEventLoop()" has returned. (The reason for this is that the event loop uses the "TaskScheduler" object that you're deleting.) I have installed a new version (2012.04.04) of the "LIVE555 Streaming Media" code that modifies the comments in "testRTSPClient.cpp" to make this clearer. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb.dotnet at gmail.com Mon Apr 2 09:52:00 2012 From: tayeb.dotnet at gmail.com (Meftah Tayeb) Date: Mon, 2 Apr 2012 19:52:00 +0300 Subject: [Live-devel] Publishing RTSP Live Stream to Live555 RTSP Server Message-ID: <5AE803317A2F468CBE4CB3C3F02ED72C@work> hello folks, do it's pocible to publish a live stream to Live555 RTSP Server? if yes, please any knowne RTSP source for broadcasting the Stream ? thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6830 (20120126) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From finlayson at live555.com Wed Apr 4 20:17:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 4 Apr 2012 20:17:45 -0700 Subject: [Live-devel] Publishing RTSP Live Stream to Live555 RTSP Server In-Reply-To: <5AE803317A2F468CBE4CB3C3F02ED72C@work> References: <5AE803317A2F468CBE4CB3C3F02ED72C@work> Message-ID: > do it's pocible to publish a live stream to Live555 RTSP Server? I'm not sure what you mean by "publish", but I think the answer is no. To develop a LIVE555 RTSP server that takes input from a live source, see http://www.live555.com/liveMedia/faq.html#liveInput-unicast Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Guy.Bonneau at miranda.com Thu Apr 5 06:29:04 2012 From: Guy.Bonneau at miranda.com (BONNEAU Guy) Date: Thu, 5 Apr 2012 13:29:04 +0000 Subject: [Live-devel] Reordering packets issue. In-Reply-To: <24665DDC0D7CF047BD6471A56E615EA69E327811@CA-OPS-MAILBOX.miranda.com> References: <24665DDC0D7CF047BD6471A56E615EA69E327811@CA-OPS-MAILBOX.miranda.com> Message-ID: <24665DDC0D7CF047BD6471A56E615EA69E3278BE@CA-OPS-MAILBOX.miranda.com> Ross, In file MultiFramedRTPSource.cpp the sequence number checking: // Ignore this packet if its sequence number is less than the one // that we're looking for (in this case, it's been excessively delayed). if (seqNumLT(rtpSeqNo, fNextExpectedSeqNo)) return False; has an issue that can causes packets to be rejected and thus freezing of the streaming for a long time. We have observed that sometime a streaming server can reset the streaming and restart with a new random sequence number. It could be caused for example by a failover stream protection that doesn't use the same RTP Sequence number. Or unplugging the network link for some time... The client that uses the live555 library sees a freeze of the streaming process that can last from a few ms to hours. This because the reordering process might begin to reject the packets depending of the new random sequence number chosen by the server. If the new random sequence number makes the check negative then the packets could be rejected for a time lasting from a few ms up to a few hours depending of the bitrate. Some protection mechanism is needed to overcome this potential issue. On our side we have added code that detects this condition and reset the reordering process. Thanks Guy Bonneau -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 5 07:30:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Apr 2012 07:30:59 -0700 Subject: [Live-devel] Reordering packets issue. In-Reply-To: <24665DDC0D7CF047BD6471A56E615EA69E3278BE@CA-OPS-MAILBOX.miranda.com> References: <24665DDC0D7CF047BD6471A56E615EA69E327811@CA-OPS-MAILBOX.miranda.com> <24665DDC0D7CF047BD6471A56E615EA69E3278BE@CA-OPS-MAILBOX.miranda.com> Message-ID: <552FD8E1-95F0-43AC-BEAF-7DB522666E31@live555.com> First, the title of this thread is a bit misleading, because the issue has nothing to do with packet "reordering". The message would have been better titled "Receiving stream with bad RTP sequence numbers issue". > In file MultiFramedRTPSource.cpp the sequence number checking: > > // Ignore this packet if its sequence number is less than the one > // that we're looking for (in this case, it's been excessively delayed). > if (seqNumLT(rtpSeqNo, fNextExpectedSeqNo)) return False; > > has an issue that can causes packets to be rejected and thus freezing of the streaming for a long time. We have observed that sometime a streaming server can reset the streaming and restart with a new random sequence number. Then the server is broken. There's nothing in the RTP specification that allows for a sender to arbitrarily change the RTP sequence number. > It could be caused for example by a failover stream protection that doesn't use the same RTP Sequence number. Then it's a different stream, in which case the original receiver cannot expect to continue to be able to receive it. I presume that you're referring to multicast streaming here. (Because, if the streaming is unicast, there's absolutely no expectation that a server should be able to restart and continue streaming to the same unicast clients, without the clients noticing - and certainly not if the sequence number changes.) If you were receiving unicast streams, then a robust receiving client application would have some mechanism (at the application level; not in the LIVE555 RTP reception code) for detecting when no data has been received within a certain timeout period, and, if so, restarting the reception code, to receive a new stream. Your (presumed multicast) client application should do the same thing. I.e., add a timer to your client application. If no new data has been received within a certain time, then stop reception of the existing stream (by closing "Groupsock" objects, "RTPSource"s, etc.), and start again, receiving a new stream. > Some protection mechanism is needed to overcome this potential issue. Perhaps, but - as noted above - this "protection mechanism" is best done at the application level (because this would also allow it to recover from a wider range of problems than just "buggy server sends streams with broken RTP sequence numbers"). I won't be adding anything to the LIVE555 RTP reception code to attempt to accommodate buggy servers like this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sct678 at hotmail.com Wed Apr 4 01:20:35 2012 From: sct678 at hotmail.com (Harold_Tham tham yulun) Date: Wed, 4 Apr 2012 16:20:35 +0800 Subject: [Live-devel] Request RTSP Integration Help Message-ID: Hello developers, Here the following scenario i am stuck with, i have downloaded the source code for live55 media server. Currently my limit knowledge are confined withing the C++ programming environment. I've managed to compile live555 and get a simple RTSP to play mp3 with the livemedia server. I have very little knowledge on how RTSP flows. I would love to merge a few modules(others open source) under a win32 environment. Current working libraries i have created: 1) Gstreamer (currently written a pipeline to stream RTP packets) > My library parameters needed are "Client ip address", "RTP sink port", "RTCP sink port", "RTCP src port" - Example my calling function webcampipeline(string clientip, int rtpSinkPort, int rtcpSinkPort, int rtpSrcPort) ; - hopefully to plug this in somewhere in live555 code for easy extendability > this will create a pipeline on my hardware webcam on my device to be transmitted to a client PC. > Client PC > plays a *.sdp with matched rtp sink port, hence live footage is being played with the manual SDP 2) Compiled Live555 source code So my task now is to integrate this module with the live555 module as RTSP is much intelligent in socket port handling and no SDP files is needed on the Client PC Example client just need to rtsp://serverip/webcam (internally link the Gstreamer lib i wrote) without a manual *.SDP file. So i would love to work tightly with you to incorporate such a mechanism integration. Rational gstreamer is used as it more hardware oriented and Gstreamer has no current working RTSP server for a windows environment(Mainly Unix and Linux base). So I would love to integrate together. And i have notice the most friendly opensource RTSP working code is Live555. And currently would wish to know how the unit flow of RTSP is in Live555 code Thanks you very much, awaiting for some good news. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 5 20:28:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Apr 2012 20:28:33 -0700 Subject: [Live-devel] Request RTSP Integration Help In-Reply-To: References: Message-ID: > Rational gstreamer is used as it more hardware oriented and Gstreamer has no current working RTSP server for a windows environment(Mainly Unix and Linux base). So I would love to integrate together. And i have notice the most friendly opensource RTSP working code is Live555. And currently would wish to know how the unit flow of RTSP is in Live555 code Unfortunately I don't know much about how 'gstreamer' works. But, as noted in the FAQ: http://www.live555.com/liveMedia/faq.html#control-flow LIVE555 applications use a single thread of control, using an event loop. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.staubin at gmail.com Wed Apr 4 07:38:26 2012 From: albert.staubin at gmail.com (AJ) Date: Wed, 4 Apr 2012 10:38:26 -0400 Subject: [Live-devel] Video quality at the client Message-ID: Ross or anyone else who might be able to help, I have the RTSP server stood up and working pretty well, my only issue now is that the video that is being received by the client is pixelated pretty badly. It is worse when using RTSP over UDP, but it is still bad over TCP. I am using VLC as a client and when the server and client are run locally this issue does not seem to exist. I thought that switching to TCP (for more reliable delivery) this issue would be resolved, it cleaned up some not entirely. Any suggestions on fixing this issue? My video is a MPEG2-TS/H264 video. If anyone has any insight into this format and what may be wrong with the video data itself that could cause an issue like this. Thank you in advance for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 5 21:29:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Apr 2012 21:29:26 -0700 Subject: [Live-devel] Video quality at the client In-Reply-To: References: Message-ID: <01105ECA-D01F-49FC-B5B1-B1F0B9949765@live555.com> > I have the RTSP server stood up and working pretty well, my only issue now is that the video that is being received by the client is pixelated pretty badly. It is worse when using RTSP over UDP, but it is still bad over TCP. I am using VLC as a client and when the server and client are run locally this issue does not seem to exist. Because of this, the problem is probably due to insufficient network bandwidth between your server and client. > I thought that switching to TCP (for more reliable delivery) this issue would be resolved TCP gives you reliable delivery between the server's OS and the client's OS. However, the server *application* - i.e. the thing that is generating the video stream - is generating data at a certain rate. If this rate exceeds the capacity of the network, then you will still get data loss - at the point where the server application feeds the server OS. I.e., you will get data loss because the server's TCP buffer(s) will fill up, and then the server application's socket writes will start failing. This is how live media streaming differs from downloading a file (e.g., from a web server). When you're downloading a file, the file transfer takes place at the underlying speed of the network. That's not the case for live media streaming. In other words: It's important to understand that streaming RTP-over-TCP is not a panacea. If your media stream exceeds the capacity of the network, then you *will* get data loss, no matter what. Streaming RTP-over-TCP just moves that data loss from the network back to the server. > Any suggestions on fixing this issue? You either need a faster network, or else you need to reduce the bandwidth of your video stream (by reducing the frame rate, and/or the video resolution). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Thu Apr 5 23:00:28 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Fri, 6 Apr 2012 11:30:28 +0530 Subject: [Live-devel] Restarting RTP Session Issue Message-ID: <3921893EF26A40DA8D03E98855463BCC@iwns10> Hi Ross, I am using Live555 for an Intraoral camera streaming application over Wifi. The streaming session need to be started once the camera and the a client device is connected. But when camera is disconnected during streaming, I will get a event from the driver and I need to restart the whole session again (canceling the thread which are handling the streaming). When I am canceling and restarting the thread on camera events I am getting following error message and streaming is not started. Failed to create RTSP server: bind() error (port number: 8554): Address already in use I guess the socket is not being closed on thread cancellation. Please let me know the correct procedure to restart the streaming session and whether does Live555 supports starting/stopping sessions. Are there API?s available? Thanks in advance. Regards, Ashfaque -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 5 23:23:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Apr 2012 23:23:02 -0700 Subject: [Live-devel] Restarting RTP Session Issue In-Reply-To: <3921893EF26A40DA8D03E98855463BCC@iwns10> References: <3921893EF26A40DA8D03E98855463BCC@iwns10> Message-ID: > When I am canceling and restarting the thread on camera events I am getting following error message and streaming is not started. > > Failed to create RTSP server: bind() error (port number: 8554): Address already in use > > I guess the socket is not being closed on thread cancellation. Correct. Because the *process* (which owns the socket) still exists, the socket remains open, even though the *thread* that happens to be using the socket has closed. This is because (for most operating systems, at least) the operating system knows nothing about threads; it deals with processes. Why don't you instead simply restart the entire *process*, rather than trying to restart a thread within a still-running process? However, having said that, the following *might* work for you (although I can't say for sure): Add -D ALLOW_RTSP_SERVER_PORT_REUSE=1 to the "COMPILE_OPTS =" line of your "config." file. Then, recompile "RTSPServer.cpp". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Thu Apr 5 23:43:14 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Fri, 6 Apr 2012 12:13:14 +0530 Subject: [Live-devel] Restarting RTP Session Issue In-Reply-To: References: <3921893EF26A40DA8D03E98855463BCC@iwns10> Message-ID: Thanks Ross for the reply. But can you please explain me the procedure to restart the process (in connection with the Live555 streaming thread). The application will be running on an embedded device, hence it cannot be exited. How can I restart the whole process again. Thanks in advance. Regards, Ashfaque From: Ross Finlayson Sent: Friday, April 06, 2012 11:53 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Restarting RTP Session Issue When I am canceling and restarting the thread on camera events I am getting following error message and streaming is not started. Failed to create RTSP server: bind() error (port number: 8554): Address already in use I guess the socket is not being closed on thread cancellation. Correct. Because the *process* (which owns the socket) still exists, the socket remains open, even though the *thread* that happens to be using the socket has closed. This is because (for most operating systems, at least) the operating system knows nothing about threads; it deals with processes. Why don't you instead simply restart the entire *process*, rather than trying to restart a thread within a still-running process? However, having said that, the following *might* work for you (although I can't say for sure): Add -D ALLOW_RTSP_SERVER_PORT_REUSE=1 to the "COMPILE_OPTS =" line of your "config." file. Then, recompile "RTSPServer.cpp". 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 Thu Apr 5 23:57:25 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Apr 2012 23:57:25 -0700 Subject: [Live-devel] Restarting RTP Session Issue In-Reply-To: References: <3921893EF26A40DA8D03E98855463BCC@iwns10> Message-ID: > But can you please explain me the procedure to restart the process (in connection with the Live555 streaming thread). I can't answer that for sure, because it depends upon your OS. However, for most Unix or Unix-like OSs (including Linux), you can do this using the "exec()" system call (or something similar). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb.dotnet at gmail.com Wed Apr 4 08:44:30 2012 From: tayeb.dotnet at gmail.com (Meftah Tayeb) Date: Wed, 4 Apr 2012 18:44:30 +0300 Subject: [Live-devel] Windows Makefile Generation Message-ID: <4EFAEB376F3042DF94B6CA41E3C236FA@work> hey folks, i don't have any directory related to c:\program files\DevStudio is that VC++6? how can i generate using Visual Studio 2008 pro ? i'm not sure what directory i should put in Win32 config file thank you, Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6830 (20120126) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From hassaan.exe at hotmail.com Fri Apr 6 00:20:46 2012 From: hassaan.exe at hotmail.com (Hafiz Hassan) Date: Fri, 6 Apr 2012 12:20:46 +0500 Subject: [Live-devel] H264 Video Live Streaming from IP Camera Message-ID: Hello everyone I need to develop a H264 Video Streamer which must stream LIVE from IP Camera, not from a FILE like "testH264VideoStreamer" does.Any suggestions would be appreciated thank you very much in advance Regards____________________________________________________ Hafiz Muhammad Hassan Software Developer, TeReSol (www.teresol.com)+92-321-4538784hafiz.m.hassan at hotmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 7 00:27:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 7 Apr 2012 00:27:02 -0700 Subject: [Live-devel] H264 Video Live Streaming from IP Camera In-Reply-To: References: Message-ID: > I need to develop a H264 Video Streamer which must stream LIVE from IP Camera, not from a FILE like "testH264VideoStreamer" does. > Any suggestions would be appreciated Yes, my suggestion is to read the FAQ - as you were asked to do before posting to the mailing list! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.staubin at gmail.com Fri Apr 6 05:13:48 2012 From: albert.staubin at gmail.com (AJ) Date: Fri, 6 Apr 2012 08:13:48 -0400 Subject: [Live-devel] Windows Makefile Generation In-Reply-To: <4EFAEB376F3042DF94B6CA41E3C236FA@work> References: <4EFAEB376F3042DF94B6CA41E3C236FA@work> Message-ID: Take a look at this link: http://thompsonng.blogspot.com/2010/04/compile-live555-using-vs2005-part-2.html It was helpful for me in getting started with building live555 in VS2008. On Wed, Apr 4, 2012 at 11:44 AM, Meftah Tayeb wrote: > hey folks, > i don't have any directory related to c:\program files\DevStudio > is that VC++6? > how can i generate using Visual Studio 2008 pro ? > i'm not sure what directory i should put in Win32 config file > thank you, > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ phone: +21321656139 > Mobile: +213660347746 > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6830 (20120126) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.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 vijayendra.t.inbox at gmail.com Sat Apr 7 01:02:20 2012 From: vijayendra.t.inbox at gmail.com (Vijayendra Tripathi) Date: Sat, 7 Apr 2012 13:32:20 +0530 Subject: [Live-devel] Play youtube stream using openRTSP. Message-ID: Hello Everyone! I wish to play a RTSP stream using an open source media player based on ffmpeg. I have downloaded openRTSP code and compiled it in xcode on Mac OSX. I was able to run testRTSPClient.cpp to read streams from youtube. I believe I was receiving packets successfully from youtube server after looking at my console output. As I am not conversed with RTSP protocol, I was not sure as how should I use these received packets to play the video. I further reviewed the related code, but beyond some point it was difficult to understand and the task looked time consuming. I would really appreciate if someone can provide a detailed explanation on this subject. I am sure the explanation will also help others too. If such an explanation already exists, then please forward the link. Many open source communities also provide paid professional consultation to organizations and individuals for example to ffmpeg. Their developers are available for paid consultation. So, I am open to this idea too, but I am not sure if Live555 dev community provide such services. Let me know if there is any. Thanks for considering this message. Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Apr 8 21:46:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Apr 2012 21:46:54 -0700 Subject: [Live-devel] Play youtube stream using openRTSP. In-Reply-To: References: Message-ID: <65BF9628-1B69-4529-A0EE-64AB2F4A5992@live555.com> > I wish to play a RTSP stream using an open source media player based on ffmpeg. Then I suggest that you use VLC , because that media player is (1) open source, (2) uses "ffmpeg" for decoding, and (3) uses our "LIVE555 Streaming Media" code for its RTSP client implementation. > Many open source communities also provide paid professional consultation to organizations and individuals for example to ffmpeg. Their developers are available for paid consultation. So, I am open to this idea too, but I am not sure if Live555 dev community provide such services. Let me know if there is any. Yes there is, but I generally charge $US250/hour or $US2000/day) for personal consulting, so this is usually not a service that is used by hobbyists. To become familiar with the "LIVE555 Streaming Media" code, I suggest that you (1) familiarize yourself with the various demo applications (in the "testProgs" directory), and (2) read the FAQ. Unfortunately this code is not particularly suitable for people (or cultures :-) who feel they require lots of 'hand holding'. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiyong.zhang.cn at gmail.com Sat Apr 7 07:09:29 2012 From: shiyong.zhang.cn at gmail.com (=?GB2312?B?1cXKwNPC?=) Date: Sat, 7 Apr 2012 22:09:29 +0800 Subject: [Live-devel] whether is a bug in function RTPInterface::handleRead in RTP over RTSP scenario Message-ID: Hi In function RTPInterface::handleRead (version 2012/04/04), 225 if (fNextTCPReadStreamSocketNum < 0) { 226 // Normal case: read from the (datagram) 'groupsock': 227 readSuccess = fGS->handleRead(buffer, bufferMaxSize, bytesRead, fromAddress); 228 } else { ... 242 fNextTCPReadSize -= bytesRead; 243 if (curBytesRead == 0 && curBytesToRead > 0) { 244 packetReadWasIncomplete = True; 245 return True; 246 } else if (curBytesRead < 0) { 247 bytesRead = 0; 248 readSuccess = False; 249 } else { 250 readSuccess = True; 251 } 252 fNextTCPReadStreamSocketNum = -1; // default, for next time ... Pay attension to line 252, variable fNextTCPReadStreamSocketNum is reset to -1 when handRead succeed(readSuccess=True). But at this time it is possible for condition fNextTCPReadSize > 0. if there are still bytes in TCP, and fNextTCPReadStreamSocketNum was reset to -1, Next time function handRead would goto line 227, and fNextTCPReadStreamSocketNum would not be set again in function SocketDescriptor::tcpReadHandler1, case AWAITING_SIZE2. Once it happen, rtsp client would never receive packets via RTP over RTSP connection. It's very stranger why this scenarion dont' appear in example openRTSP. I just create a new MediaSink in my program, and it happened. too bad !!! :-( Shiyong Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Apr 8 22:31:40 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Apr 2012 22:31:40 -0700 Subject: [Live-devel] whether is a bug in function RTPInterface::handleRead in RTP over RTSP scenario In-Reply-To: References: Message-ID: <3158E2CF-CC6F-4CDD-91A3-C722117B5BF3@live555.com> > In function RTPInterface::handleRead (version 2012/04/04), > > 225 if (fNextTCPReadStreamSocketNum < 0) { > 226 // Normal case: read from the (datagram) 'groupsock': > 227 readSuccess = fGS->handleRead(buffer, bufferMaxSize, bytesRead, fromAddress); > 228 } else { > ... > 242 fNextTCPReadSize -= bytesRead; > 243 if (curBytesRead == 0 && curBytesToRead > 0) { > 244 packetReadWasIncomplete = True; > 245 return True; > 246 } else if (curBytesRead < 0) { > 247 bytesRead = 0; > 248 readSuccess = False; > 249 } else { > 250 readSuccess = True; > 251 } > 252 fNextTCPReadStreamSocketNum = -1; // default, for next time > ... > > Pay attension to line 252, variable fNextTCPReadStreamSocketNum is reset to -1 when handRead succeed(readSuccess=True). But at this time it is possible for condition fNextTCPReadSize > 0. if there are still bytes in TCP, and fNextTCPReadStreamSocketNum was reset to -1 Yes, you have discovered a bug. Thank you. Note, however, that the bug will show up only if the condition in the "if" statement on line 232: if (totBytesToRead > bufferMaxSize) totBytesToRead = bufferMaxSize; is true. I.e., the bug will show up only if "totBytesToRead > bufferMaxSize". (Because otherwise, upon exiting the "while" loop, the condition on line 243 will be true, and we'll return without getting to line 252.) But nonetheless, there is a bug. You should be able to fix it by replacing line 243 if (curBytesRead == 0 && curBytesToRead > 0) { with if (fNextTCPReadSize > 0) { If this doesn't fix the problem, then please let us know. Otherwise, this fix will be included in the next release of the software. Thank you again. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Mon Apr 9 00:55:34 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Mon, 9 Apr 2012 13:25:34 +0530 Subject: [Live-devel] Streaming Stops for larger frameBuff size Issue Message-ID: Hi Ross, I am facing a typical problem where the streaming stops after some time if the encoded frame buffer size is more. If I keep the buffer size less (ActualSize/8), streaming goes normal. I had implemented my own H264Source subclass of FramedSource (to read frames at 30fps from USB camera and encodes using VPU encoder). I am triggering the streaming thread at every 20ms and using testProgs/testRTSPClient for testing the reception of streams. below is the code: void H264Source::deliverFrame() { if (!isCurrentlyAwaitingData()) return; u32 EncFrameSize = 0; u32& newFrameSize = EncFrameSize; static int k = 0; printf("Reading Frames: k = %d\r\n", k++); /* Get the frames from the camera */ CameraDevice::getInstance()->GetFrame(m_pu8RawFrameBuff, m_u16RawBuffLen); /* encode the frames with hardware encoder */ m_pEncoder->EncodeFrameBuff(m_pu8RawFrameBuff, m_u16RawBuffLen, m_pu8EncFrameBuff, newFrameSize); // After encoding newFrameSize can be maximum of 640 * 480 = 307200 */ if (newFrameSize > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = newFrameSize - fMaxSize; } else { fFrameSize = newFrameSize; } gettimeofday(&fPresentationTime, NULL); memmove(fTo, m_pu8EncFrameBuff, fFrameSize); FramedSource::afterGetting(this); m_bProcessingDone = true; } Is the problem with newFrameSize being too large or any other reason? Is my way to getting the frames and processing is correct or Any other better way to accomplish this? What is the maximum size of frames that is supported ? I need to pass complete frames only for compatibility with the receiver application. Thanks in advance. Ashfaque -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 9 01:57:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2012 01:57:50 -0700 Subject: [Live-devel] Streaming Stops for larger frameBuff size Issue In-Reply-To: References: Message-ID: <7859C1E7-A659-4025-868D-5E4166DD3EBA@live555.com> > Is the problem with newFrameSize being too large Yes, quite possibly, especially if you are seeing error messages about the need to increase "OutPacketBuffer::maxSize". The buffer that's used by the "RTPSink" subclass - to store each frame of data that gets sent - is, by default, 60000 bytes. You can increase this (e.g., to 100000 bytes) by doing, for example OutPacketBuffer::maxSize = 100000; before you create your "RTSPServer". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From boys21century at gmail.com Sun Apr 8 05:59:42 2012 From: boys21century at gmail.com (Ramu Chakravadhanula) Date: Sun, 8 Apr 2012 08:59:42 -0400 Subject: [Live-devel] open svc Mplayer and live Message-ID: hi, I am trying to complie Mplayer with live. I could successfully configure the player and generate a make file. However, Its throwing an error when iam trying to install it. libmpdemux/demux_rtp_internal.h:33: fatal error: liveMedia.hh: No such file or directory compilation terminated. make: *** [libmpdemux/demux_rtp.o] Error 1 Before starting the installation, i have downloaded live from the website and extracted it. Later i place the live folder in usr/lib. then I used genMakefiles followed my 'make' command. after that i started mplayer installing, in the configure command, I specified ./configure --enable-svc --enable-gui --enable-live. Please help me regarding this issue, i have googled it and couldn't get it. Thanks in advance, Br, boys21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From timercrack at gmail.com Mon Apr 9 01:56:00 2012 From: timercrack at gmail.com (=?UTF-8?B?6ZmI6LeD6L6J?=) Date: Mon, 9 Apr 2012 16:56:00 +0800 Subject: [Live-devel] Converting H.264 RTP Video to MPEG-2 Transport Stream Message-ID: Hello Everyone! I have an application running on iPhone that generates an H.264 RTP video stream from camera. I wanna writing an application to convert the received H.264 stream to an MPEG-2 Transport Stream and then stream the live TS to another device. my first try is modified the example "testH264VideoToTransportStream" , use H264VideoRTPSource to receive H.264 RTP stream from VLC, then try to convert it to TS and send it to another port and I start another VLC player to play it. but as a matter of fact it won't work. VLC received the data but do not display anything. I tried the following setup of live555: 1. H264VideoRTPSource -> H264VideoStreamDiscreteFramer -> MPEG2TransportStreamFromESSource -> SimpleRTPSink 2. H264VideoRTPSource -> MPEG2TransportStreamFromESSource -> H264VideoStreamDiscreteFramer -> SimpleRTPSink 3. H264VideoRTPSource -> MPEG2TransportStreamFromESSource -> >MPEG2TransportStreamFramer -> SimpleRTPSink unfortunately neither of them could work :( I also try back to use FileSink instead of SimpleRTPSink to generate a Transport Stream file, then play it use VLC, but it has the same problem as above. I have little knowledge about H.264 and TS, my question is, what am I doing / not doing to cause VLC to only receive them but not show anything? Do you have any suggestions as to what I should check? Thanks for any suggestions you might have. Best Regards, JeffChen From finlayson at live555.com Mon Apr 9 17:20:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2012 17:20:00 -0700 Subject: [Live-devel] Converting H.264 RTP Video to MPEG-2 Transport Stream In-Reply-To: References: Message-ID: <8207FD1E-0771-4C89-9717-3F8EB6D71C11@live555.com> > I have an application running on iPhone that generates an H.264 RTP > video stream from camera. I wanna writing an application to convert > the received H.264 stream to an MPEG-2 Transport Stream and then > stream the live TS to another device. > > my first try is modified the example "testH264VideoToTransportStream" > , use H264VideoRTPSource to receive H.264 RTP stream from VLC, then > try to convert it to TS The problem here is that the output from "H264VideoRTPSource" is a sequence of raw H.264 NAL units - i.e., without 'start code's. > 3. H264VideoRTPSource -> MPEG2TransportStreamFromESSource -> MPEG2TransportStreamFramer -> SimpleRTPSink This *should* work, with one modification: You will need to add a 'start code' (i.e., 0x00 0x00 0x00 0x01) before each NAL unit that comes out of the "H264VideoRTPSource". You will need to do this - using a separate filter class (that you would write) - before you feed the output into a "MPEG2TransportStreamFromESSource". Before doing this, though, I suggest that you do H264VideoRTPSource -> H264VideoFileSink (*not* just a "FileSink") and then try running the (original, unmodified) "testH264VideoToTransportStream" application to generate a Transport Stream. (Note that "H264VideoFileSink" adds 'start codes' before each NAL unit.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailme_vinaytyagi at yahoo.com Mon Apr 9 04:21:03 2012 From: mailme_vinaytyagi at yahoo.com (Vinay Tyagi) Date: Mon, 9 Apr 2012 04:21:03 -0700 (PDT) Subject: [Live-devel] Live caster source code Message-ID: <1333970463.50831.YahooMailNeo@web113408.mail.gq1.yahoo.com> Hi, ? Can we downld and modify source code of Live caster applation as per our requirement?? If yes, please guide on download link. ? Regards, Vinay -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 9 18:57:09 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2012 18:57:09 -0700 Subject: [Live-devel] Live caster source code In-Reply-To: <1333970463.50831.YahooMailNeo@web113408.mail.gq1.yahoo.com> References: <1333970463.50831.YahooMailNeo@web113408.mail.gq1.yahoo.com> Message-ID: <60DF482C-927C-4E9A-83D5-37038CA5C6A3@live555.com> > Can we downld and modify source code of Live caster applation as per our requirement?? Sorry, but the "liveCaster" application is no longer supported (and its source code was not made available, because it used a lot of custom GUI code). Instead, you should use the "testMP3Streamer" demo application, whose code is available as part of the "LIVE555 Streaming Media" code: http://www.live555.com/liveMedia/ Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Mon Apr 9 05:35:24 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Mon, 9 Apr 2012 18:05:24 +0530 Subject: [Live-devel] is there any source code for h264 parser Message-ID: actually i want an application which takes h264 as an input file and tells the header size,I,B,P-frames.... if someone knows how to do it please let me know... -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 9 19:20:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2012 19:20:26 -0700 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: References: Message-ID: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> > actually i want an application which takes h264 as an input file and tells the header size,I,B,P-frames.... What you can do is add #define DEBUG 1 to the start of "liveMedia/H264VideoStreamFramer.cpp", then recompile the "liveMedia" library. Then rebuild the "testH264VideoStreamer" application. Then you'll get debugging output that will show information about each NAL unit in the file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From timercrack at gmail.com Mon Apr 9 22:40:47 2012 From: timercrack at gmail.com (=?UTF-8?B?6ZmI6LeD6L6J?=) Date: Tue, 10 Apr 2012 13:40:47 +0800 Subject: [Live-devel] Converting H.264 RTP Video to MPEG-2 Transport Stream In-Reply-To: <8207FD1E-0771-4C89-9717-3F8EB6D71C11@live555.com> References: <8207FD1E-0771-4C89-9717-3F8EB6D71C11@live555.com> Message-ID: Thanks very much for your assistance! I do the "H264VideoRTPSource -> H264VideoFileSink -> testH264VideoToTransportStream" test and yes, VLC can play the generated file successful. This *should* work, with one modification: You will need to add a 'start code' (i.e., 0x00 0x00 0x00 0x01) before each NAL unit that comes out of the "H264VideoRTPSource". You will need to do this - using a separate filter class (that you would write) - before you feed the output into a " MPEG2TransportStreamFromESSource". when I try to follow your suggestion, I found it's too hard for me to write such a filter class. I tried to implement a new subclass of "FramedFilter", but don't know what virtual functions should I overridden to insert the start code at each NALU's head just as "H264VideoFileSink::afterGettingFrame1()" does. Is there any example or test program I can refer to? Could you give me any suggestion on this matter? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 9 22:50:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2012 22:50:38 -0700 Subject: [Live-devel] Converting H.264 RTP Video to MPEG-2 Transport Stream In-Reply-To: References: <8207FD1E-0771-4C89-9717-3F8EB6D71C11@live555.com> Message-ID: > This *should* work, with one modification: You will need to add a 'start code' (i.e., 0x00 0x00 0x00 0x01) before each NAL unit that comes out of the "H264VideoRTPSource". You will need to do this - using a separate filter class (that you would write) - before you feed the output into a "MPEG2TransportStreamFromESSource". > > when I try to follow your suggestion, I found it's too hard for me to write such a filter class. I tried to implement a new subclass of "FramedFilter", but don't know what virtual functions should I overridden You need to implement the (pure) virtual function: virtual void doGetNextFrame(); The code has several examples of "FramedFilter" subclass that you could refer to. (I suggest "uLawAudioFilter.cpp".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiyong.zhang.cn at gmail.com Mon Apr 9 23:03:39 2012 From: shiyong.zhang.cn at gmail.com (=?GB2312?B?1cXKwNPC?=) Date: Tue, 10 Apr 2012 14:03:39 +0800 Subject: [Live-devel] whether is a bug in function RTPInterface::handleRead in RTP over RTSP scenario In-Reply-To: <3158E2CF-CC6F-4CDD-91A3-C722117B5BF3@live555.com> References: <3158E2CF-CC6F-4CDD-91A3-C722117B5BF3@live555.com> Message-ID: Hi I've correct as you said, it work. Thanks. Shiyong Zhang 2012/4/9 Ross Finlayson > In function RTPInterface::handleRead (version 2012/04/04), > > 225 if (fNextTCPReadStreamSocketNum < 0) { > 226 // Normal case: read from the (datagram) 'groupsock': > 227 readSuccess = fGS->handleRead(buffer, bufferMaxSize, bytesRead, > fromAddress); > 228 } else { > ... > 242 fNextTCPReadSize -= bytesRead; > 243 if (curBytesRead == 0 && curBytesToRead > 0) { > 244 packetReadWasIncomplete = True; > 245 return True; > 246 } else if (curBytesRead < 0) { > 247 bytesRead = 0; > 248 readSuccess = False; > 249 } else { > 250 readSuccess = True; > 251 } > 252 fNextTCPReadStreamSocketNum = -1; // default, for next time > ... > > Pay attension to line 252, variable fNextTCPReadStreamSocketNum is reset > to -1 when handRead succeed(readSuccess=True). But at this time it is > possible for condition fNextTCPReadSize > 0. if there are still bytes in > TCP, and fNextTCPReadStreamSocketNum was reset to -1 > > > Yes, you have discovered a bug. Thank you. > > Note, however, that the bug will show up only if the condition in the "if" > statement on line 232: > if (totBytesToRead > bufferMaxSize) totBytesToRead = bufferMaxSize; > is true. I.e., the bug will show up only if "totBytesToRead > > bufferMaxSize". (Because otherwise, upon exiting the "while" loop, the > condition on line 243 will be true, and we'll return without getting to > line 252.) > > But nonetheless, there is a bug. You should be able to fix it by > replacing line 243 > if (curBytesRead == 0 && curBytesToRead > 0) { > with > if (fNextTCPReadSize > 0) { > > If this doesn't fix the problem, then please let us know. Otherwise, this > fix will be included in the next release of the software. > > Thank you again. > > > 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 trn200190 at gmail.com Tue Apr 10 00:03:16 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Tue, 10 Apr 2012 12:33:16 +0530 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> References: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> Message-ID: On Tue, Apr 10, 2012 at 7:50 AM, Ross Finlayson wrote: > actually i want an application which takes h264 as an input file and tells > the header size,I,B,P-frames.... > > > What you can do is add > > #define DEBUG 1 > > to the start of "liveMedia/H264VideoStreamFramer.cpp", then recompile the > "liveMedia" library. Then rebuild the "testH264VideoStreamer" application. > Then you'll get debugging output that will show information about each NAL > unit in the file. > > > 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 > i have done all u said but while running the program testH264VideoStreamer > i am getting errors > i have downloaded .264 source files from the link" http://www.live555.com/liveMedia/public/264/" Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 10 00:13:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2012 00:13:38 -0700 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: References: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> Message-ID: Oh for heaven's sake! This is why I discriminate against noobs who use @gmail.com addresses. The "testH264VideoStreamer" application reads a (H.264 Video Elementary Stream) file named "test.264". Your input file needs to have that name. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Tue Apr 10 00:46:01 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Tue, 10 Apr 2012 13:16:01 +0530 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: References: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> Message-ID: sir i have renamed the file as "test.264". -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 10 00:56:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2012 00:56:03 -0700 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: References: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> Message-ID: > sir i have renamed the file as "test.264". The file "test.264" needs to be in the "testProgs" directory (or in the directory from which you launched the "testH264VideoStreamer" application, if that's different). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Tue Apr 10 02:37:24 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Tue, 10 Apr 2012 15:07:24 +0530 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: References: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> Message-ID: Sir i did that the program start running but the output window does not stop... i run continuously.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwright3 at slb.com Tue Apr 10 08:01:45 2012 From: mwright3 at slb.com (Martin Wright) Date: Tue, 10 Apr 2012 15:01:45 +0000 Subject: [Live-devel] testOnDemandRTSPServer plays mp3 silently In-Reply-To: References: Message-ID: Hi all It seems using the testOnDemandRTSPServer example program somehow causes the QuickTime app to play an mp3 silently. I have run live/testProgs/testOnDemandRTSPServer on a machine that is also running Apache from a directory that contains various wav and mp3 files. I have an index.html file that contains a variety of ways to reference these files including: 27 mins which invokes the QuickTime plug-in to play the downloaded file and via testOnDemandRTSPServer which invokes the QuickTime app externally to the browser. The direct URL, played through the plug-in, works fine which proves there is no fault with the actual mp3 file or the speakers or volume setting on the client. The rtsp stream plays in QuickTime for the right amount of time but without any sound at all. I get the same symptoms if I enter urls via the QuickTime app's OpenURL menu option, i.e. opening the file with http via the web server is fine but using rtsp via the 8554 port causes it to appear to play but be completely silent. Has anyone else had this problem or could hint at where to look in this particular source code? Thanks, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.armstrong at st.com Tue Apr 10 08:42:00 2012 From: marc.armstrong at st.com (Marc ARMSTRONG) Date: Tue, 10 Apr 2012 17:42:00 +0200 Subject: [Live-devel] Live H264 Streaming Timing Problem Message-ID: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> Hi, I'm having difficulty streaming live H264 video captured from a PCI Express board. It appears that the data acquisition is too slow for the Live555 streaming application and hence the displayed video (in VLC) is sticky. For the time being I am assuming that the hardware is okay and would like to investigate the possibility that the Live555 application is attempting to grab the data too quickly for the hardware. Could you tell me how Live555 calculates the time period between calls to ByteStreamFileSource::doReadFromFile() and also where this is implemented in the code. Also, if Live555 was asking for the data too quickly, would it be possible to slow it down? Thanks in advance for your help. Regards, Marc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 10 10:46:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2012 10:46:02 -0700 Subject: [Live-devel] testOnDemandRTSPServer plays mp3 silently In-Reply-To: References: Message-ID: <744A844E-3286-4FCF-A6DC-3C308B60080D@live555.com> Yes, this is Apple's problem, not ours; See: http://www.live555.com/liveMedia/faq.html#quicktime-player-mp3-bug Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 10 11:35:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2012 11:35:51 -0700 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> Message-ID: <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> > I?m having difficulty streaming live H264 video captured from a PCI Express board. It appears that the data acquisition is too slow for the Live555 streaming application and hence the displayed video (in VLC) is sticky. For the time being I am assuming that the hardware is okay and would like to investigate the possibility that the Live555 application is attempting to grab the data too quickly for the hardware. > > Could you tell me how Live555 calculates the time period between calls to ByteStreamFileSource::doReadFromFile() and also where this is implemented in the code. You haven't said exactly how you're reading H.264 data from your video capture device, but because you mentioned "ByteStreamFileSource", I'm assuming that you're treating the device as a file (a byte stream), and feeding the output from a "ByteStreamFileSource" (i.e., your video capture device) into a "H264VideoStreamFramer" (which parses the byte stream into a sequence of H.264 NAL units). In this case, the code (in "H264VideoStreamFramer") figures out the frame rate (and thus, how long to delay between frames) from the "time_scale" parameter in "Sequence Parameter Set" (i.e., SPS) NAL units. If this parameter is not present, then the code can't figure out the frame rate, so it uses a default frame rate of 25 fps. If, however, your video capture device delivers 'discrete' H.264 NAL units - i.e., one at a time - rather than an unstructured byte stream, then you should *not* attempt to read it as a file. Instead, you should write your own subclass of "FramedSource" (perhaps, based on the "DeviceSource" model) that delivers the NAL units, and feed these into a "H264VideoStreamDiscreteFramer" - *not* a "H264VideoStreamFramer". If you do this, then your 'input device' class - i.e., the subclass of "FramedSource" that you'll write - *must* set "fDurationInMicroseconds" for each NAL unit, before it delivers it to its downstream object (a "H264VideoStreamDiscreteFramer"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Tue Apr 10 11:46:48 2012 From: warren at etr-usa.com (Warren Young) Date: Tue, 10 Apr 2012 12:46:48 -0600 Subject: [Live-devel] is there any source code for h264 parser In-Reply-To: References: <0FBD8B65-553D-4C6A-8031-E1DD0DBBF2EF@live555.com> Message-ID: <4F848018.3030808@etr-usa.com> On 4/10/2012 3:37 AM, i m what i m ~~~~ wrote: > > Sir i did that the program start running but the output window does not > stop... > i run continuously.... It's doubtless just putting out more information than you expected to see. You do realize that you've asked for information on 1,800 frames per minute of 30 fps video, right? A quick glance at that file Ross pointed you to tells me there's 6 different debug prints per parse() operation, plus or minus a few. Assuming parse() gets called once per frame (I have no idea if that's true) you're going to get about ten thousand lines of output per minute of 30 fps input video. If it gets called more than once per frame, as I suspect, then you multiply the number of output lines still further. If you were expecting something more high level, maybe you should look at ffprobe. It won't give you stats on every packet in the file, but maybe you were more interested in aggregate statistics? Or, maybe the trick play indexing code in Live555 will guide you to a more suitable output form. From marc.armstrong at st.com Wed Apr 11 02:20:00 2012 From: marc.armstrong at st.com (Marc ARMSTRONG) Date: Wed, 11 Apr 2012 11:20:00 +0200 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> Message-ID: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> Thanks very much for the info, and your quick response. I am reading in H.264 data from a named pipe (which is essentially a file) and feeding into a H264VideoStreamFramer. I basically copied ByteStreamFileSource and read from a pipe rather than a file. Incidentally, I used pipes because I am using visual studio and couldn't find a way to pipe the encoder output to stdin of the test streamer application. I am confident that the streamer application is receiving the frame count and of the integrity of the video input to the streamer application. I think the issue may lie with the speed of the capture from the hardware. Before I focus on this, can I ask a further question? I am capturing H.264 data with low compression from a video encoder in 2Mb chunks and from the Live555 application to play in VLC player. Is this type of application well tested with the Live555 software? i.e. high data content streaming in real time. When I capture to file and stream from the file the application works perfectly. Thanks again. Marc. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 10 April 2012 19:36 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live H264 Streaming Timing Problem I'm having difficulty streaming live H264 video captured from a PCI Express board. It appears that the data acquisition is too slow for the Live555 streaming application and hence the displayed video (in VLC) is sticky. For the time being I am assuming that the hardware is okay and would like to investigate the possibility that the Live555 application is attempting to grab the data too quickly for the hardware. Could you tell me how Live555 calculates the time period between calls to ByteStreamFileSource::doReadFromFile() and also where this is implemented in the code. You haven't said exactly how you're reading H.264 data from your video capture device, but because you mentioned "ByteStreamFileSource", I'm assuming that you're treating the device as a file (a byte stream), and feeding the output from a "ByteStreamFileSource" (i.e., your video capture device) into a "H264VideoStreamFramer" (which parses the byte stream into a sequence of H.264 NAL units). In this case, the code (in "H264VideoStreamFramer") figures out the frame rate (and thus, how long to delay between frames) from the "time_scale" parameter in "Sequence Parameter Set" (i.e., SPS) NAL units. If this parameter is not present, then the code can't figure out the frame rate, so it uses a default frame rate of 25 fps. If, however, your video capture device delivers 'discrete' H.264 NAL units - i.e., one at a time - rather than an unstructured byte stream, then you should *not* attempt to read it as a file. Instead, you should write your own subclass of "FramedSource" (perhaps, based on the "DeviceSource" model) that delivers the NAL units, and feed these into a "H264VideoStreamDiscreteFramer" - *not* a "H264VideoStreamFramer". If you do this, then your 'input device' class - i.e., the subclass of "FramedSource" that you'll write - *must* set "fDurationInMicroseconds" for each NAL unit, before it delivers it to its downstream object (a "H264VideoStreamDiscreteFramer"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 11 12:38:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2012 12:38:00 -0700 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> Message-ID: <5E052A83-00DF-4576-A4F6-BFC056789D22@live555.com> > I am reading in H.264 data from a named pipe (which is essentially a file) and feeding into a H264VideoStreamFramer. I basically copied ByteStreamFileSource and read from a pipe rather than a file. You shouldn't need to 'copy' the "ByteStreamFileSource" code. Because your pipe appears - to the application - just like a named file, you should be able to use the "ByteStreamFileSource" class directly, without modification. > Incidentally, I used pipes because I am using visual studio Oh god, you're using Windows. I suspect that that's the cause of your problem (see below). > I am confident that the streamer application is receiving the frame count and of the integrity of the video input to the streamer application. I think the issue may lie with the speed of the capture from the hardware. Before I focus on this, can I ask a further question? > > I am capturing H.264 data with low compression from a video encoder in 2Mb chunks and from the Live555 application to play in VLC player. Is this type of application well tested with the Live555 software? Yes, I believe so. > i.e. high data content streaming in real time. When I capture to file and stream from the file the application works perfectly. In other words, if you capture H.264 video to a file named "test.264", and then use "testH264VideoStreamer" or "testOnDemandRTSPServer" to stream it, then VLC (acting as a RTSP client) plays the stream OK?? If so, then I suspect that your problem is that the "ByteStreamFileSource" code - when run on Windows - reads from files (including pipes) synchronously - i.e., blocking if there's no data currently in the pipe. Unfortunately there's no easy way to fix this, other than using a real operating system (one that treats open files as sockets). I suspect that - if you want to stick with Windows - you will need to write your own "FramedSource" subclass to encapsulate your video capture device, and use that instead of "ByteStreamFileSource". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 11 12:38:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2012 12:38:59 -0700 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> Message-ID: > I am reading in H.264 data from a named pipe (which is essentially a file) and feeding into a H264VideoStreamFramer. I basically copied ByteStreamFileSource and read from a pipe rather than a file. You shouldn't need to 'copy' the "ByteStreamFileSource" code. Because your pipe appears - to the application - just like a named file, you should be able to use the "ByteStreamFileSource" class directly, without modification. > Incidentally, I used pipes because I am using visual studio Oh god, you're using Windows. I suspect that that's the cause of your problem (see below). > I am confident that the streamer application is receiving the frame count and of the integrity of the video input to the streamer application. I think the issue may lie with the speed of the capture from the hardware. Before I focus on this, can I ask a further question? > > I am capturing H.264 data with low compression from a video encoder in 2Mb chunks and from the Live555 application to play in VLC player. Is this type of application well tested with the Live555 software? Yes, I believe so. > i.e. high data content streaming in real time. When I capture to file and stream from the file the application works perfectly. In other words, if you capture H.264 video to a file named "test.264", and then use "testH264VideoStreamer" or "testOnDemandRTSPServer" to stream it, then VLC (acting as a RTSP client) plays the stream OK?? If so, then I suspect that your problem is that the "ByteStreamFileSource" code - when run on Windows - reads from files (including pipes) synchronously - i.e., blocking if there's no data currently in the pipe. Unfortunately there's no easy way to fix this, other than using a real operating system (one that treats open files as sockets). I suspect that - if you want to stick with Windows - you will need to write your own "FramedSource" subclass to encapsulate your video capture device, and use that instead of "ByteStreamFileSource". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatomauro at libero.it Wed Apr 11 16:19:51 2012 From: renatomauro at libero.it (Renato MAURO (Libero)) Date: Thu, 12 Apr 2012 01:19:51 +0200 Subject: [Live-devel] Live H264 Streaming Timing Problem References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com><1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com><62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> <5E052A83-00DF-4576-A4F6-BFC056789D22@live555.com> Message-ID: <0F7503B3621248458F6A84C6AFB41DC2@CSystemDev> Hello Marc. In Windows the ReadFile function reads asynchronously: 1) from a pipe, setting PIPE_NOWAIT via the SetNamedPipeHandleState function (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365787(v=vs.85).aspx); 2) from a file, setting FILE_FLAG_OVERLAPPED via the CreateFile function (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx); anyway, see http://support.microsoft.com/kb/156932/en-us for some problems you have to deal with when using this feature (but at the end everything always worked fine for me from disks and serial or USB ports); 3) from a socket, using the usual ReadFile function on a socket handle (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx); but it sounds new for Windows, at least for me: I'll try it one day (please, let me know if it worked for you). Hope this helps. Renato MAURO -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailme_vinaytyagi at yahoo.com Tue Apr 10 22:33:08 2012 From: mailme_vinaytyagi at yahoo.com (Vinay Tyagi) Date: Tue, 10 Apr 2012 22:33:08 -0700 (PDT) Subject: [Live-devel] TestMP3Streamer.cpp In-Reply-To: <1333970463.50831.YahooMailNeo@web113408.mail.gq1.yahoo.com> References: <1333970463.50831.YahooMailNeo@web113408.mail.gq1.yahoo.com> Message-ID: <1334122388.94963.YahooMailNeo@web113403.mail.gq1.yahoo.com> Hi, ? while?I am trying to execute TestMP3Streamer.exe it doesn't find any RTSP Server and goes into following condition and display the message "Failed to create RTSP ...." ? if (rtspServer == NULL) { ??? *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n"; ??? exit(1); ? } RTSP server parameter is defined in TestMP3Streamer.cpp as follows - #ifdef IMPLEMENT_RTSP_SERVER RTSPServer* rtspServer; #endif Please help how to provide RTSP server reference into this file. Regards, Vinay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Prashant.Tiwary at infotech-enterprises.com Wed Apr 11 21:13:59 2012 From: Prashant.Tiwary at infotech-enterprises.com (Prashant Tiwary) Date: Thu, 12 Apr 2012 04:13:59 +0000 Subject: [Live-devel] video streaming over wifi Message-ID: <323E1E683AA19646BCA8F280D4E53FE5035EBCD5@INFHYDEX10MB2.corp.infotech-enterprises.com> hi, can we use live555 to stream a video file over wifi ________________________________ DISCLAIMER: This email may contain confidential information and is intended only for the use of the specific individual(s) to which it is addressed. If you are not the intended recipient of this email, you are hereby notified that any unauthorized use, dissemination or copying of this email or the information contained in it or attached to it is strictly prohibited. If you received this message in error, please immediately notify the sender at Infotech or Mail.Admin at infotech-enterprises.com and delete the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 12 00:48:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Apr 2012 19:48:47 +1200 Subject: [Live-devel] TestMP3Streamer.cpp In-Reply-To: <1334122388.94963.YahooMailNeo@web113403.mail.gq1.yahoo.com> References: <1333970463.50831.YahooMailNeo@web113408.mail.gq1.yahoo.com> <1334122388.94963.YahooMailNeo@web113403.mail.gq1.yahoo.com> Message-ID: > while I am trying to execute TestMP3Streamer.exe it doesn't find any RTSP Server and goes into following condition and display the message "Failed to create RTSP ...." > > if (rtspServer == NULL) { > *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n"; > exit(1); > } The problem here is probably that you do not have permission to start up the server using the default RTSP port number of 554 (because on Unix systems (including Linux), you need to be "root" to do that). To overcome this, either run the server as "root", or else make it use a different port number - e.g., the 'alternative' RTSP port number: 8554 - by doing: rtspServer = RTSPServer::createNew(*env, 8554); instead of just rtspServer = RTSPServer::createNew(*env); Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 12 00:49:40 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Apr 2012 19:49:40 +1200 Subject: [Live-devel] video streaming over wifi In-Reply-To: <323E1E683AA19646BCA8F280D4E53FE5035EBCD5@INFHYDEX10MB2.corp.infotech-enterprises.com> References: <323E1E683AA19646BCA8F280D4E53FE5035EBCD5@INFHYDEX10MB2.corp.infotech-enterprises.com> Message-ID: <1E0F819F-2A11-4363-A455-F98AC1A2B06A@live555.com> > can we use live555 to stream a video file over wifi Of course - provided, of course, that you have IP running on that network. Just use an appropriate demo application (in "testProgs") as a model. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.armstrong at st.com Thu Apr 12 02:45:25 2012 From: marc.armstrong at st.com (Marc ARMSTRONG) Date: Thu, 12 Apr 2012 11:45:25 +0200 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> Message-ID: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC1251376@SAFEX1MAIL1.st.com> Thanks again for the feedback. Yes, I am using windows and have no option but to carry on until I get this working. Yes, I can rename my captured video to 'test.264', stream this and play it in VLC player. Hopefully this means that I'm not too far away from a solution. Windows pipes can be implemented asynchronously and there is also a 'peek' function provided to check for data before attempting to read. I tried this briefly but it didn't improve things - I probably implemented it incorrectly. So currently I do block when reading from the pipe. Could you advise how best to use a 'peek' function within the Live555 model? Naturally I'll spend some time investigating the task scheduler background reading from file etc, but if you could point me in the right direction it would be very helpful. Also, to improve my understanding of the live555 model could you tell me the impact of blocking. i.e. if there is no data currently available to stream, what other tasks will be going on? From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 11 April 2012 20:39 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live H264 Streaming Timing Problem I am reading in H.264 data from a named pipe (which is essentially a file) and feeding into a H264VideoStreamFramer. I basically copied ByteStreamFileSource and read from a pipe rather than a file. You shouldn't need to 'copy' the "ByteStreamFileSource" code. Because your pipe appears - to the application - just like a named file, you should be able to use the "ByteStreamFileSource" class directly, without modification. Incidentally, I used pipes because I am using visual studio Oh god, you're using Windows. I suspect that that's the cause of your problem (see below). I am confident that the streamer application is receiving the frame count and of the integrity of the video input to the streamer application. I think the issue may lie with the speed of the capture from the hardware. Before I focus on this, can I ask a further question? I am capturing H.264 data with low compression from a video encoder in 2Mb chunks and from the Live555 application to play in VLC player. Is this type of application well tested with the Live555 software? Yes, I believe so. i.e. high data content streaming in real time. When I capture to file and stream from the file the application works perfectly. In other words, if you capture H.264 video to a file named "test.264", and then use "testH264VideoStreamer" or "testOnDemandRTSPServer" to stream it, then VLC (acting as a RTSP client) plays the stream OK?? If so, then I suspect that your problem is that the "ByteStreamFileSource" code - when run on Windows - reads from files (including pipes) synchronously - i.e., blocking if there's no data currently in the pipe. Unfortunately there's no easy way to fix this, other than using a real operating system (one that treats open files as sockets). I suspect that - if you want to stick with Windows - you will need to write your own "FramedSource" subclass to encapsulate your video capture device, and use that instead of "ByteStreamFileSource". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 12 02:56:16 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Apr 2012 21:56:16 +1200 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC1251376@SAFEX1MAIL1.st.com> References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC1251376@SAFEX1MAIL1.st.com> Message-ID: > Also, to improve my understanding of the live555 model could you tell me the impact of blocking. i.e. if there is no data currently available to stream, what other tasks will be going on? Because LIVE555 applications run in a single-threaded event loop, I/O operations should not block, whenever possible. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.armstrong at st.com Thu Apr 12 03:38:45 2012 From: marc.armstrong at st.com (Marc ARMSTRONG) Date: Thu, 12 Apr 2012 12:38:45 +0200 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com> <1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> <62C5DEBD7ECE854CBFFB46E6E51AB351DBC1251376@SAFEX1MAIL1.st.com> Message-ID: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC1251387@SAFEX1MAIL1.st.com> Thanks Ross, I'm currently familiarising myself with the TaskScheduler, with a view to implementing background reading of windows named pipes, implemented asynchronously. Hopefully this will work. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 12 April 2012 10:56 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live H264 Streaming Timing Problem Also, to improve my understanding of the live555 model could you tell me the impact of blocking. i.e. if there is no data currently available to stream, what other tasks will be going on? Because LIVE555 applications run in a single-threaded event loop, I/O operations should not block, whenever possible. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.armstrong at st.com Thu Apr 12 03:41:06 2012 From: marc.armstrong at st.com (Marc ARMSTRONG) Date: Thu, 12 Apr 2012 12:41:06 +0200 Subject: [Live-devel] Live H264 Streaming Timing Problem In-Reply-To: <0F7503B3621248458F6A84C6AFB41DC2@CSystemDev> References: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC120BD8F@SAFEX1MAIL1.st.com><1FD49DA0-9D40-43D1-BA01-FBDB1B1DC621@live555.com><62C5DEBD7ECE854CBFFB46E6E51AB351DBC120C28D@SAFEX1MAIL1.st.com> <5E052A83-00DF-4576-A4F6-BFC056789D22@live555.com> <0F7503B3621248458F6A84C6AFB41DC2@CSystemDev> Message-ID: <62C5DEBD7ECE854CBFFB46E6E51AB351DBC1251389@SAFEX1MAIL1.st.com> Thanks Renato, I'm currently looking into Asynchronous pipes. Hopefully this will fit into the Live555 model. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Renato MAURO (Libero) Sent: 12 April 2012 00:20 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live H264 Streaming Timing Problem Hello Marc. In Windows the ReadFile function reads asynchronously: 1) from a pipe, setting PIPE_NOWAIT via the SetNamedPipeHandleState function (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365787(v=vs.85).aspx); 2) from a file, setting FILE_FLAG_OVERLAPPED via the CreateFile function (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx); anyway, see http://support.microsoft.com/kb/156932/en-us for some problems you have to deal with when using this feature (but at the end everything always worked fine for me from disks and serial or USB ports); 3) from a socket, using the usual ReadFile function on a socket handle (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx); but it sounds new for Windows, at least for me: I'll try it one day (please, let me know if it worked for you). Hope this helps. Renato MAURO -------------- next part -------------- An HTML attachment was scrubbed... URL: From aviadr1 at gmail.com Wed Apr 11 07:40:18 2012 From: aviadr1 at gmail.com (aviad rozenhek) Date: Wed, 11 Apr 2012 17:40:18 +0300 Subject: [Live-devel] patch for compiling on android Message-ID: attached is a patch for compiling live555 on android, it adds an Application.mk file, and fixes compilation in Groupsockhelper.cpp android compilation can be tested by downloading the android NDK from http://www.crystax.net/en/android/ndk/7. it doesn't require an actual android device. -- Aviad Rozenhek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: android.diff Type: application/octet-stream Size: 8519 bytes Desc: not available URL: From finlayson at live555.com Thu Apr 12 05:28:49 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2012 00:28:49 +1200 Subject: [Live-devel] patch for compiling on android In-Reply-To: References: Message-ID: <2596FD48-A02F-48B9-9C54-2511DA9E8C4B@live555.com> Thanks. I'll add the "GroupsockHelper.cpp" change in the next release of the software. (The Makefile (.mk) won't be included though; people should instead be generating Makefiles from an appropriate "config.*" file, using the usual "genMakefiles" mechanism.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aviadr1 at gmail.com Wed Apr 11 07:42:39 2012 From: aviadr1 at gmail.com (aviad rozenhek) Date: Wed, 11 Apr 2012 17:42:39 +0300 Subject: [Live-devel] vs2010 project file patch Message-ID: the attached patch adds a project file for compiling live555 under vs2010 -- Aviad Rozenhek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vs2010_project.diff Type: application/octet-stream Size: 42977 bytes Desc: not available URL: From aviadr1 at gmail.com Wed Apr 11 07:44:42 2012 From: aviadr1 at gmail.com (aviad rozenhek) Date: Wed, 11 Apr 2012 17:44:42 +0300 Subject: [Live-devel] patch for fixing compilation under vs2010 Message-ID: the attached patch fixes compilation under vs2010, by using winsock2 instead of winsock1 when compiling in visual studio -- Aviad Rozenhek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vs2010_compilation_fix.diff Type: application/octet-stream Size: 981 bytes Desc: not available URL: From finlayson at live555.com Thu Apr 12 11:01:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2012 06:01:45 +1200 Subject: [Live-devel] patch for fixing compilation under vs2010 In-Reply-To: References: Message-ID: <036C1C85-D773-41F7-92E1-6EFC6B58F374@live555.com> > the attached patch fixes compilation under vs2010, by using winsock2 instead of winsock1 when compiling in visual studio OK, I'll include this 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 bstump at codemass.com Thu Apr 12 12:50:44 2012 From: bstump at codemass.com (Barry Stump) Date: Thu, 12 Apr 2012 12:50:44 -0700 Subject: [Live-devel] Patch for Boolean typedef conflict on OS X Message-ID: This patch resolves a typedef conflict for Boolean between UsageEnvironment/include/Boolean.hh and the system provided MacTypes.h on OS X when using Xcode to compile Live555. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osx_boolean.patch Type: application/octet-stream Size: 391 bytes Desc: not available URL: From finlayson at live555.com Thu Apr 12 14:03:28 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2012 09:03:28 +1200 Subject: [Live-devel] Patch for Boolean typedef conflict on OS X In-Reply-To: References: Message-ID: <480AE068-CB3D-4F88-8E33-3C838C2F9EF9@live555.com> OK, in the next release of the system, I'll change the definition of "Boolean" so that it's "unsigned char" for all systems (not just for Mac OS X). (Having it be "unsigned" was an unnecessary waste of space.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From timercrack at gmail.com Thu Apr 12 00:28:34 2012 From: timercrack at gmail.com (JeffChen) Date: Thu, 12 Apr 2012 15:28:34 +0800 Subject: [Live-devel] Converting H.264 RTP Video to MPEG-2 Transport Stream In-Reply-To: References: <8207FD1E-0771-4C89-9717-3F8EB6D71C11@live555.com> Message-ID: I add this code in doGetNextFrame(): if (fMaxSize > fInputBufferSize) { fInputBufferSize = fMaxSize; delete[] fInputBuffer; fInputBuffer = new unsigned char[fInputBufferSize]; *( reinterpret_cast(fInputBuffer) ) = htonl(0x01); } // Arrange to read data directly into the client's buffer: fInputSource->getNextFrame ( fInputBuffer + 4, fMaxSize - 4,afterGettingFrame, this,FramedSource::handleClosure, this ); and this in afterGettingFrame1(): fFrameSize = frameSize + 4; memmove(fTo, fInputBuffer, fFrameSize); (...omitted code...) Although it works fine, but noticed that there is a memory copy which I think is redundant. I have tried to let fTo point directly to fInputBuffer, but that caused the generated data full of garbage. I don't known why. who will use fTo later and where is fTo's initialization? Thanks again for your help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 12 17:45:53 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2012 12:45:53 +1200 Subject: [Live-devel] Converting H.264 RTP Video to MPEG-2 Transport Stream In-Reply-To: References: <8207FD1E-0771-4C89-9717-3F8EB6D71C11@live555.com> Message-ID: <97BB4A58-8824-4644-8225-AD29F81234B6@live555.com> > Although it works fine, but noticed that there is a memory copy which I think is redundant. I have tried to let fTo point directly to fInputBuffer, but that caused the generated data full of garbage. I don't known why. who will use fTo later and where is fTo's initialization? "fTo" is a pointer to the buffer that is provided to you by the downstream object (i.e., the object that you're delivering the data to). You *must* copy the data into this location (and also set "fFrameSize" appropriately). You don't change the value of "fTo"; instead, you copy data to this pointer. (This is explained more in "liveMedia/DeviceSource.cpp".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hh3.kim at samsung.com Fri Apr 13 02:28:49 2012 From: hh3.kim at samsung.com (=?utf-8?B?6rmA7ZiE7Zi4?=) Date: Fri, 13 Apr 2012 09:28:49 +0000 (GMT) Subject: [Live-devel] ONVIF RTSP extension : Audio Backchannel Handling Message-ID: <0M2E008DFVO13CC0@mailout3.samsung.com> An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 14 01:53:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 14 Apr 2012 18:53:58 +1000 Subject: [Live-devel] ONVIF RTSP extension : Audio Backchannel Handling In-Reply-To: <0M2E008DFVO13CC0@mailout3.samsung.com> References: <0M2E008DFVO13CC0@mailout3.samsung.com> Message-ID: Because - as you noted - these extensions are not part of the RTSP standard, we don't support them. Also, unfortunately, it would not be possible to support them without modifying (not just subclassing) the existing LIVE555 library code. In particular, you would need to reimplement the "MediaSubsession::initiate()" function. For 'backchannel' subsessions, you would need to create an appropriate "RTPSink" subclass, rather than a "RTPSource" subclass that the existing code always does. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Thu Apr 12 05:03:23 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Thu, 12 Apr 2012 17:33:23 +0530 Subject: [Live-devel] How can i detect the size of nal unit? Message-ID: 1.>How can i detect the size of nal unit? 2/>How can i detect the end of nal unit? 3.>How can i detect the I-Frame in an packet? 4.>How can i detect theB,P-Frame in an packet? Thank You -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 14 18:07:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 15 Apr 2012 11:07:15 +1000 Subject: [Live-devel] How can i detect the size of nal unit? In-Reply-To: References: Message-ID: > 1.>How can i detect the size of nal unit? > 2/>How can i detect the end of nal unit? > 3.>How can i detect the I-Frame in an packet? > 4.>How can i detect theB,P-Frame in an packet? For this you need a H.264 decoder - which we don't provide. (Therefore, your question is off-topic for this mailing list.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sazalihisham at gmail.com Sun Apr 15 01:06:36 2012 From: sazalihisham at gmail.com (Sazali Hisham) Date: Sun, 15 Apr 2012 16:06:36 +0800 Subject: [Live-devel] RTSPclient cross-mixing Message-ID: Hi, I am new too rtspclient development. Currently i am working on VLC custom development on RTSP client. Since I'm struggling to get the job done so I think this is one of the best medium for me to get some guides or ideas. Actually I would like to do "cross-mixing" on RTSPclient. The use case is something like this: Given currently, client is connected to RTSPserver A, who streams a video file. Then, an RTSP server B will establish connection to server A to also get the content (like as client) and re-stream it. So basically server A and server B is streaming the same content except the stream from server B may has delay. After sometimes, there is a condition where the client has to be redirect from server A to server B and the video should be continuously playing (seamless/almost seamless redirection). In order to achieve this, my strategy is if redirection required, open another socket, but in the same RTSPclient object, and use the same network buffer as connection to server A. So the data will be queued in the same buffer, so the upper level of video processing will continuously read the data. Once connection to server B established, disconnect from server A. Theoretically, it seems possible. But I would like to know whether it is possible practically (of course modification on live555 source). I really appreciate any guide and idea regarding this as I already spent fruitless 2 month on this part. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aviadr1 at gmail.com Sun Apr 15 04:25:08 2012 From: aviadr1 at gmail.com (aviad rozenhek) Date: Sun, 15 Apr 2012 14:25:08 +0300 Subject: [Live-devel] patch for compiling on android In-Reply-To: <2596FD48-A02F-48B9-9C54-2511DA9E8C4B@live555.com> References: <2596FD48-A02F-48B9-9C54-2511DA9E8C4B@live555.com> Message-ID: Thanks, however I'm not sure one can generate android makefiles using the *configure *, as android makefiles are different in some ways to traditional makefiles On Thu, Apr 12, 2012 at 15:28, Ross Finlayson wrote: > Thanks. I'll add the "GroupsockHelper.cpp" change in the next release of > the software. > > (The Makefile (.mk) won't be included though; people should instead be > generating Makefiles from an appropriate "config.*" file, using the usual > "genMakefiles" mechanism.) > > > 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 > > -- Aviad Rozenhek -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Apr 15 17:21:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Apr 2012 10:21:51 +1000 Subject: [Live-devel] patch for compiling on android In-Reply-To: References: <2596FD48-A02F-48B9-9C54-2511DA9E8C4B@live555.com> Message-ID: <8BAD8341-4CE3-4B08-AD15-04AD401E6B15@live555.com> > however I'm not sure one can generate android makefiles using the configure, as android makefiles are different in some ways to traditional makefiles I doubt there's any fundamental difference. 'Android' is basically just a Linux distribution. People have had no problem writing a "config.*" file for other Linux distributions that generate a working Makefile (using the "genMakefiles" script). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aviadr1 at gmail.com Sun Apr 15 04:28:56 2012 From: aviadr1 at gmail.com (aviad rozenhek) Date: Sun, 15 Apr 2012 14:28:56 +0300 Subject: [Live-devel] How can i detect the size of nal unit? In-Reply-To: References: Message-ID: try this extern "C" int find_nal_unit(const unsigned char* buf, int size, int* nal_start, int* nal_end) { int i; // find start *nal_start = 0; *nal_end = 0; i = 0; while ( //( next_bits( 24 ) != 0x000001 && next_bits( 32 ) != 0x00000001 ) (buf[i] != 0 || buf[i+1] != 0 || buf[i+2] != 0x01) && (buf[i] != 0 || buf[i+1] != 0 || buf[i+2] != 0 || buf[i+3] != 0x01) ) { i++; // skip leading zero if (i+4 >= size) { return 0; } // did not find nal start } if (buf[i] != 0 || buf[i+1] != 0 || buf[i+2] != 0x01) // ( next_bits( 24 ) != 0x000001 ) { i++; } if (buf[i] != 0 || buf[i+1] != 0 || buf[i+2] != 0x01) { /* error, should never happen */ return 0; } i+= 3; *nal_start = i; while ( //( next_bits( 24 ) != 0x000000 && next_bits( 24 ) != 0x000001 ) (buf[i] != 0 || buf[i+1] != 0 || buf[i+2] != 0) && (buf[i] != 0 || buf[i+1] != 0 || buf[i+2] != 0x01) ) { i++; // FIXME the next line fails when reading a nal that ends exactly at the end of the data if (i+3 >= size) { *nal_end = size; return size - *nal_start; } // did not find nal end, stream ended first } *nal_end = i; return (*nal_end - *nal_start); } /** * test method showing how to use find_nal_unit * for the first frame in inglorious bastards, it prints out: * NAL: type=6, size=678, start=4, end=682 * NAL: type=7, size=33, start=686, end=719 * NAL: type=8, size=5, start=723, end=728 * NAL: type=5, size=96, start=731, end=824 */ /*void test(MediaSample* pSample) { int s = pSample->GetActualDataLength(); uint8_t* p = pSample->GetPointer(); int nal_start, nal_end, nal_offset = 0; while(s > 0) { int nal_size = find_nal_unit(p, s, &nal_start, &nal_end); int unit_type = p[nal_start] & 0x1f; std::cout << "NAL: type=" << unit_type << ", size=" << nal_size << ", start=" << nal_offset + nal_start << ", end=" << nal_offset + nal_end << std::endl; p += nal_end; s -= nal_end; nal_offset += nal_end; } }*/ On Sun, Apr 15, 2012 at 04:07, Ross Finlayson wrote: > 1.>How can i detect the size of nal unit? > 2/>How can i detect the end of nal unit? > 3.>How can i detect the I-Frame in an packet? > 4.>How can i detect theB,P-Frame in an packet? > > > For this you need a H.264 decoder - which we don't provide. (Therefore, > your question is off-topic for this mailing list.) > > > 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 > > -- Aviad Rozenhek -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Mon Apr 16 02:32:00 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Mon, 16 Apr 2012 15:02:00 +0530 Subject: [Live-devel] Receive data from live server Message-ID: Hello Sir i made a c++ code(using sockets) to receive *.264 streaming from the RTSP server(RTSP server.cpp) but it doesnot receive anything but when i used the same code to receive streaming from the vlc player it works well?? Can u suggest me where am i wrong or any pseudo code? Thank YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 16 16:16:34 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Apr 2012 09:16:34 +1000 Subject: [Live-devel] Receive data from live server In-Reply-To: References: Message-ID: <1C13A0FB-925A-4053-959F-621434EC528B@live555.com> > i made a c++ code(using sockets) to receive *.264 streaming from the RTSP server(RTSP server.cpp) but it doesnot receive anything but when i used the same code to receive streaming from the vlc player it works well?? > > Can u suggest me where am i wrong or any pseudo code? Look at the "testRTSPClient" demo application. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.timenkov at itv.ru Tue Apr 17 01:25:17 2012 From: yuri.timenkov at itv.ru (Yuri Timenkov) Date: Tue, 17 Apr 2012 12:25:17 +0400 Subject: [Live-devel] ONVIF RTSP extension : Audio Backchannel Handling In-Reply-To: References: <0M2E008DFVO13CC0@mailout3.samsung.com> Message-ID: <4F8D28ED.6090204@itv.ru> Hi Ross, Actually the "extension" is implemented in terms of RFC 2326 by using "Require" header (12.32 Require). So the question is how to get these "Require" headers from OPTIONS request and respond with 200 OK or 551 Option not supported. The second part of question is how to make a track with "a:sendonly" attribute and accept data. The reverse media transport is part of RTP standard and used in SIP protocol. I suppose the only implication is when backchannel interleaved over TCP, but liveMedia should handle it to process RTCP feedback. Best wishes, Yuri On 14.04.2012 12:53, Ross Finlayson wrote: > Because - as you noted - these extensions are not part of the RTSP > standard, we don't support them. Also, unfortunately, it would not be > possible to support them without modifying (not just subclassing) the > existing LIVE555 library code. In particular, you would need to > reimplement the "MediaSubsession::initiate()" function. For > 'backchannel' subsessions, you would need to create an appropriate > "RTPSink" subclass, rather than a "RTPSource" subclass that the > existing code always does. > > 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 trn200190 at gmail.com Tue Apr 17 00:11:41 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Tue, 17 Apr 2012 12:41:41 +0530 Subject: [Live-devel] Receive data from live server In-Reply-To: <1C13A0FB-925A-4053-959F-621434EC528B@live555.com> References: <1C13A0FB-925A-4053-959F-621434EC528B@live555.com> Message-ID: Sir i don't want to use the live media library rather want to receive the data through sockets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordu at dvr2010.com Tue Apr 17 05:42:03 2012 From: gordu at dvr2010.com (Gord Umphrey) Date: Tue, 17 Apr 2012 08:42:03 -0400 Subject: [Live-devel] testRTSPClient heap corruption Message-ID: Hi; If you attempt to receive a stream from an invalid source, (i.e. rtsp://non-existing_IP:554/main) then the testRTSPClient application will crash. It seems that calling Medium::close() is the culprit. Medium::close() works fine when connected to a valid stream, but will cause heap corruption when not streaming. Steps to reproduce: Two modifications are required in testRTSPClient.cpp to show the problem: 1.) In main(), follow the comments at the end of the procedure, I.e. comment out the ?return 0?, and uncomment the last two lines 2.) At the end of the shutdown() procedure, comment out the exit(), and replace with ?eventLoopWatchVariable = 1;? Then just stream to a non-existing source. The reason this is not showing up more frequently is because the exit() routine by-passes the run-time memory checks and just exits. A quick work-around would be greatly appreciated!! Regards, Gord. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 17 21:45:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Apr 2012 14:45:42 +1000 Subject: [Live-devel] Receive data from live server In-Reply-To: References: <1C13A0FB-925A-4053-959F-621434EC528B@live555.com> Message-ID: <3B37A4AA-CC27-4154-B1DD-F54440763C77@live555.com> > Sir i don't want to use the live media library rather want to receive the data through sockets. Well, if you don't want to use our software, then your question is off-topic for this mailing list. You'll need to ask somewhere else. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 17 22:15:32 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Apr 2012 15:15:32 +1000 Subject: [Live-devel] testRTSPClient heap corruption In-Reply-To: References: Message-ID: <526F6D4B-7B7E-45CD-881B-6E8AD3115F7D@live555.com> > If you attempt to receive a stream from an invalid source, (i.e. rtsp://non-existing_IP:554/main) > then the testRTSPClient application will crash. > > It seems that calling Medium::close() is the culprit. Medium::close() works fine when connected to a valid stream, but will cause heap corruption when not streaming. > > Steps to reproduce: > > Two modifications are required in testRTSPClient.cpp to show the problem: > > 1.) In main(), follow the comments at the end of the procedure, I.e. comment out the ?return 0?, and uncomment the last two lines > 2.) At the end of the shutdown() procedure, comment out the exit(), and replace with ?eventLoopWatchVariable = 1;? > > Then just stream to a non-existing source. Sorry, but I can't reproduce this. However, I think you may be misunderstanding the purpose of the two lines: env->reclaim(); env = NULL; delete scheduler; scheduler = NULL; You should execute those lines only if you're *complete done* with the "UsageEnvironment" and "TaskScheduler" objects; i.e. if you don't plan to execute any more "LIVE555 Streaming Media" library code. In particular, you should not be calling "Medium::close()" at all after this point (and that function won't get called from the event loop anymore - because you're no longer in the event loop). So where exactly is this erroneous call to "Medium::close()" happening? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 18 01:23:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Apr 2012 18:23:00 +1000 Subject: [Live-devel] ONVIF RTSP extension : Audio Backchannel Handling In-Reply-To: <4F8D28ED.6090204@itv.ru> References: <0M2E008DFVO13CC0@mailout3.samsung.com> <4F8D28ED.6090204@itv.ru> Message-ID: > Actually the "extension" is implemented in terms of RFC 2326 by using "Require" header (12.32 Require). > So the question is how to get these "Require" headers from OPTIONS request and respond with 200 OK or 551 Option not supported. Yes, you're correct - the server needs to be fixed so that it notices the "Require:" header, and returns an "551 Option not supported" error in this case. > The second part of question is how to make a track with "a:sendonly" attribute and accept data. I outlined this in my previous reply. > The reverse media transport is part of RTP standard and used in SIP protocol. Yes, but RTSP is not SIP. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Wed Apr 18 02:52:22 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Wed, 18 Apr 2012 15:22:22 +0530 Subject: [Live-devel] mplayer not playing stream Message-ID: <15174A684AED4CED8AAE46F2026A2955@iwns10> Hi Ross, I am currently testing Live555 based application on Freescale?s i.MX51 platform, the camera frames are encoded by Hardware encoder (H.264 format). The encoded frames are sent to deliverFarme without any modifications. After this I am streaming over UDP. With reference is taken from DeviceSource.cpp, I am able to stream but following warnings are displayed continuously. .... Warning: Invalid 'nal_unit_type': 0. Does the NAL unit begin with a MPEG 'start code' by mistake? Warning: Invalid 'nal_unit_type': 0. Does the NAL unit begin with a MPEG 'start code' by mistake? .... My understanding is that it is expecting some NAL units in the encoded frames. I am running mplayer as the client in the linux machine which displays following messages without displaying the video frames. non-existing PPS referenced% 0.0% 0 0 [h264 @ 0x3879bc0]non-existing PPS referenced [h264 @ 0x3879bc0]decode_slice_header error [h264 @ 0x3879bc0]no frame! Error while decoding frame! non-existing PPS referenced% 0.0% 0 0 [h264 @ 0x3879bc0]non-existing PPS referenced [h264 @ 0x3879bc0]decode_slice_header error [h264 @ 0x3879bc0]no frame! Error while decoding frame! Gone through the H264VideoStreamDiscreteFramer ::afterGettingFrame1 method but not able to catch what exactly being done there. Please let me know the reason behind this and the way to solve it. Thanks & Regards, Ashfaque -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordu at dvr2010.com Wed Apr 18 04:56:35 2012 From: gordu at dvr2010.com (Gord Umphrey) Date: Wed, 18 Apr 2012 07:56:35 -0400 Subject: [Live-devel] live-devel Digest, Vol 102, Issue 17 In-Reply-To: References: Message-ID: <19A6CE734AA042D0950C3E09CC0FCC2B@SmokeyPC> Thanks Ross; Attached is the testRTSPClient.cpp that will crash. If you use this as a source: rtsp://192.168.1.1:8554/main, then you will see heap corruption. If you comment out the Medium::close(rtspClient); on line 398, then it will no longer crash, but you would be leaking a lot of resources. Unfortunately, "exit()" is hiding a lot of memory leaks and other problems. PS, I am running this on a Windows machine. Regards, Gord. -----Original Message----- From: live-devel-request at ns.live555.com Sent: Wednesday, April 18, 2012 1:15 AM To: live-devel at ns.live555.com Subject: live-devel Digest, Vol 102, Issue 17 Send live-devel mailing list submissions to live-devel at lists.live555.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.live555.com/mailman/listinfo/live-devel or, via email, send a message with subject or body 'help' to live-devel-request at lists.live555.com You can reach the person managing the list at live-devel-owner at lists.live555.com When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..." Today's Topics: 1. Receive data from live server (i m what i m ~~~~) 2. Re: Receive data from live server (Ross Finlayson) 3. Re: ONVIF RTSP extension : Audio Backchannel Handling (Yuri Timenkov) 4. Re: Receive data from live server (i m what i m ~~~~) 5. testRTSPClient heap corruption (Gord Umphrey) 6. Re: Receive data from live server (Ross Finlayson) 7. Re: testRTSPClient heap corruption (Ross Finlayson) ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Apr 2012 15:02:00 +0530 From: "i m what i m ~~~~" To: live-devel at ns.live555.com, "LIVE555 Streaming Media - development & use" Subject: [Live-devel] Receive data from live server Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hello Sir i made a c++ code(using sockets) to receive *.264 streaming from the RTSP server(RTSP server.cpp) but it doesnot receive anything but when i used the same code to receive streaming from the vlc player it works well?? Can u suggest me where am i wrong or any pseudo code? Thank YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 17 Apr 2012 09:16:34 +1000 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Receive data from live server Message-ID: <1C13A0FB-925A-4053-959F-621434EC528B at live555.com> Content-Type: text/plain; charset="iso-8859-1" > i made a c++ code(using sockets) to receive *.264 streaming from the RTSP > server(RTSP server.cpp) but it doesnot receive anything but when i used > the same code to receive streaming from the vlc player it works well?? > > Can u suggest me where am i wrong or any pseudo code? Look at the "testRTSPClient" demo application. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 17 Apr 2012 12:25:17 +0400 From: Yuri Timenkov To: LIVE555 Streaming Media - development & use Cc: Ross Finlayson Subject: Re: [Live-devel] ONVIF RTSP extension : Audio Backchannel Handling Message-ID: <4F8D28ED.6090204 at itv.ru> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi Ross, Actually the "extension" is implemented in terms of RFC 2326 by using "Require" header (12.32 Require). So the question is how to get these "Require" headers from OPTIONS request and respond with 200 OK or 551 Option not supported. The second part of question is how to make a track with "a:sendonly" attribute and accept data. The reverse media transport is part of RTP standard and used in SIP protocol. I suppose the only implication is when backchannel interleaved over TCP, but liveMedia should handle it to process RTCP feedback. Best wishes, Yuri On 14.04.2012 12:53, Ross Finlayson wrote: > Because - as you noted - these extensions are not part of the RTSP > standard, we don't support them. Also, unfortunately, it would not be > possible to support them without modifying (not just subclassing) the > existing LIVE555 library code. In particular, you would need to > reimplement the "MediaSubsession::initiate()" function. For > 'backchannel' subsessions, you would need to create an appropriate > "RTPSink" subclass, rather than a "RTPSource" subclass that the > existing code always does. > > 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: ------------------------------ Message: 4 Date: Tue, 17 Apr 2012 12:41:41 +0530 From: "i m what i m ~~~~" To: "LIVE555 Streaming Media - development & use" Subject: Re: [Live-devel] Receive data from live server Message-ID: Content-Type: text/plain; charset="iso-8859-1" Sir i don't want to use the live media library rather want to receive the data through sockets. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 17 Apr 2012 08:42:03 -0400 From: "Gord Umphrey" To: Subject: [Live-devel] testRTSPClient heap corruption Message-ID: Content-Type: text/plain; charset="utf-8" Hi; If you attempt to receive a stream from an invalid source, (i.e. rtsp://non-existing_IP:554/main) then the testRTSPClient application will crash. It seems that calling Medium::close() is the culprit. Medium::close() works fine when connected to a valid stream, but will cause heap corruption when not streaming. Steps to reproduce: Two modifications are required in testRTSPClient.cpp to show the problem: 1.) In main(), follow the comments at the end of the procedure, I.e. comment out the ?return 0?, and uncomment the last two lines 2.) At the end of the shutdown() procedure, comment out the exit(), and replace with ?eventLoopWatchVariable = 1;? Then just stream to a non-existing source. The reason this is not showing up more frequently is because the exit() routine by-passes the run-time memory checks and just exits. A quick work-around would be greatly appreciated!! Regards, Gord. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Wed, 18 Apr 2012 14:45:42 +1000 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Receive data from live server Message-ID: <3B37A4AA-CC27-4154-B1DD-F54440763C77 at live555.com> Content-Type: text/plain; charset="iso-8859-1" > Sir i don't want to use the live media library rather want to receive the > data through sockets. Well, if you don't want to use our software, then your question is off-topic for this mailing list. You'll need to ask somewhere else. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 7 Date: Wed, 18 Apr 2012 15:15:32 +1000 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient heap corruption Message-ID: <526F6D4B-7B7E-45CD-881B-6E8AD3115F7D at live555.com> Content-Type: text/plain; charset="windows-1252" > If you attempt to receive a stream from an invalid source, (i.e. > rtsp://non-existing_IP:554/main) > then the testRTSPClient application will crash. > > It seems that calling Medium::close() is the culprit. Medium::close() > works fine when connected to a valid stream, but will cause heap > corruption when not streaming. > > Steps to reproduce: > > Two modifications are required in testRTSPClient.cpp to show the problem: > > 1.) In main(), follow the comments at the end of the procedure, I.e. > comment out the ?return 0?, and uncomment the last two lines > 2.) At the end of the shutdown() procedure, comment out the exit(), and > replace with ?eventLoopWatchVariable = 1;? > > Then just stream to a non-existing source. Sorry, but I can't reproduce this. However, I think you may be misunderstanding the purpose of the two lines: env->reclaim(); env = NULL; delete scheduler; scheduler = NULL; You should execute those lines only if you're *complete done* with the "UsageEnvironment" and "TaskScheduler" objects; i.e. if you don't plan to execute any more "LIVE555 Streaming Media" library code. In particular, you should not be calling "Medium::close()" at all after this point (and that function won't get called from the event loop anymore - because you're no longer in the event loop). So where exactly is this erroneous call to "Medium::close()" happening? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 102, Issue 17 ******************************************* -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testRTSPClient.cpp URL: From Shaheed at scansoft.co.za Wed Apr 18 06:04:40 2012 From: Shaheed at scansoft.co.za (Shaheed Abdol) Date: Wed, 18 Apr 2012 15:04:40 +0200 Subject: [Live-devel] DeviceSource using elementary stream framer with discrete frames Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8D18@SSTSVR1.sst.local> Good afternoon Ross, I am having a bit of trouble supplying live data to live555. I have encapsulated my live source using the DeviceSource code as a base. I know you can't help with modified code, and that's fine. I just have a simple theoretical question: When using the delayed EventTrigger functionality of DeviceSource (TaskScheduler->signalDataWaiting(eventTriggerId, ...) I seem to be unable to send a complete frame. I am using an MPEG4ESStreamFramer which allows me to supply frame chunks when my live source is updated and data becomes available, however live555 fills an internal buffer with as many chunks as it can before sending the chunks off in a single sendto call. All of the behaviour described so far is great, but my deliverFrame function is not called for the last chunk of my frame. I have tried triggering the TaskScheduler event from within deliverFrame, but that results in undefined behaviour (access violation). Could there be another method of making sure that the last frame chunk is not discarded? I understand that there is the option to use a MPEG4DiscreteStreamFramer which allows for passing entire frame chunks at a time, but that approach fails miserably because of a socket send buffer limit. Is there any way I can send off parts of the complete frame I have using a stream framer, while still being signalled from an external class that data is available? In other words - using an elementary stream framer with discrete frames. Thank you Regards ___________________________________ Shaheed Abdol Web: www.scansoft.co.za Tel: +27 21 913 8664 Cell: +27 79 835 8771 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32497 bytes Desc: SST Email.png URL: From finlayson at live555.com Wed Apr 18 15:06:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2012 08:06:24 +1000 Subject: [Live-devel] mplayer not playing stream In-Reply-To: <15174A684AED4CED8AAE46F2026A2955@iwns10> References: <15174A684AED4CED8AAE46F2026A2955@iwns10> Message-ID: <6CFEFF44-0B4D-4269-BAE2-2DA65974B2C2@live555.com> > I am currently testing Live555 based application on Freescale?s i.MX51 platform, the camera frames are encoded by Hardware encoder (H.264 format). The encoded frames are sent to deliverFarme without any modifications. After this I am streaming over UDP. > > With reference is taken from DeviceSource.cpp, I am able to stream but following warnings are displayed continuously. > > .... > Warning: Invalid 'nal_unit_type': 0. Does the NAL unit begin with a MPEG 'start code' by mistake? The problem here is (probably) that you are feeding your "H264VideoStreamDiscreteFramer" object with NAL units that begin with MPEG start codes (i.e., 0x00 0x00 0x00 0x01). You must not do this. Instead, if (as appears to be the case) your encoder delivers NAL units that begin with MPEG start codes, you must make sure that you don't copy those when your "FramedSource" subclass does its delivery. (Don't forget to adjust "fFrameSize" accordingly.) (Also, your version of the "LIVE555 Streaming Media" code is a little out of date. I recommend upgrading. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 18 15:36:22 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2012 08:36:22 +1000 Subject: [Live-devel] testRTSPClient heap corruption In-Reply-To: <19A6CE734AA042D0950C3E09CC0FCC2B@SmokeyPC> References: <19A6CE734AA042D0950C3E09CC0FCC2B@SmokeyPC> Message-ID: First, everyone who receives this mailing list as a 'Digest' should heed this advice: > When replying, please edit your Subject line so it is more specific > than "Re: Contents of live-devel digest..." > Attached is the testRTSPClient.cpp that will crash. > > If you use this as a source: rtsp://192.168.1.1:8554/main, > then you will see heap corruption. No, sorry, I didn't. > If you comment out the Medium::close(rtspClient); on line 398, then it will no longer crash, but you would be leaking a lot of resources. There should be no problem with that call to "Medium::close(rtspClient)", because - at that point in the code - "rtspClient" should be a valid pointer, to a still-valid "RTSPClient" object. (Also, the call to "Medium::close(rtspClient)" is done only once, so (as far as I can tell) there's no attempt to delete an already-deleted object.) So, I don't understand why that call to "Medium::close(rtspClient)" is failing for you. I'm not ruling out the possibility of a bug in the code, but - if so - it seems to be something that only you are tripping over. So you're going to have to track down the problem yourself. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Wed Apr 18 05:53:30 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Wed, 18 Apr 2012 18:23:30 +0530 Subject: [Live-devel] how can i convert transport stream file to h264 file Message-ID: is there any sample by which i can convert *.ts file to *.264 file? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 18 16:08:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2012 09:08:08 +1000 Subject: [Live-devel] how can i convert transport stream file to h264 file In-Reply-To: References: Message-ID: <98CDE8F3-A2E4-4E1C-B137-8A490F22A610@live555.com> > is there any sample by which i can convert *.ts file to *.264 file? No. We do not include any 'Transport Stream demultiplexing' code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Wed Apr 18 22:09:10 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Thu, 19 Apr 2012 10:39:10 +0530 Subject: [Live-devel] mplayer not playing stream In-Reply-To: <6CFEFF44-0B4D-4269-BAE2-2DA65974B2C2@live555.com> References: <15174A684AED4CED8AAE46F2026A2955@iwns10> <6CFEFF44-0B4D-4269-BAE2-2DA65974B2C2@live555.com> Message-ID: <830765AA9CFD47C9BE0246C995D6DDA6@iwns10> Thanks Ross. I had tried to neglect the first 4 bytes from the encoded buffer, but it did not helped, I had adjusted the fFrameSize accordingly. Can you please provide me with the pseudo code for handling this. Regards, Ashfaque From: Ross Finlayson Sent: Thursday, April 19, 2012 3:36 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] mplayer not playing stream I am currently testing Live555 based application on Freescale?s i.MX51 platform, the camera frames are encoded by Hardware encoder (H.264 format). The encoded frames are sent to deliverFarme without any modifications. After this I am streaming over UDP. With reference is taken from DeviceSource.cpp, I am able to stream but following warnings are displayed continuously. .... Warning: Invalid 'nal_unit_type': 0. Does the NAL unit begin with a MPEG 'start code' by mistake? The problem here is (probably) that you are feeding your "H264VideoStreamDiscreteFramer" object with NAL units that begin with MPEG start codes (i.e., 0x00 0x00 0x00 0x01). You must not do this. Instead, if (as appears to be the case) your encoder delivers NAL units that begin with MPEG start codes, you must make sure that you don't copy those when your "FramedSource" subclass does its delivery. (Don't forget to adjust "fFrameSize" accordingly.) (Also, your version of the "LIVE555 Streaming Media" code is a little out of date. I recommend upgrading. 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 Thu Apr 19 17:39:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2012 10:39:17 +1000 Subject: [Live-devel] mplayer not playing stream In-Reply-To: <830765AA9CFD47C9BE0246C995D6DDA6@iwns10> References: <15174A684AED4CED8AAE46F2026A2955@iwns10> <6CFEFF44-0B4D-4269-BAE2-2DA65974B2C2@live555.com> <830765AA9CFD47C9BE0246C995D6DDA6@iwns10> Message-ID: <030E5653-E70F-49E0-90C6-506C71EB34DF@live555.com> > I had tried to neglect the first 4 bytes from the encoded buffer, but it did not helped, I had adjusted the fFrameSize accordingly. > > Can you please provide me with the pseudo code for handling this. Oh for heaven's sake... In your 'data source' class (i.e., your subclass of "FramedSource"), you will currently be doing something like: fFrameSize = size_of_nal_unit; memmove(fTo, ptr_to_start_of_nal_unit, fFrameSize); Change this to: fFrameSize = size_of_nal_unit - 4; memmove(fTo, ptr_to_start_of_nal_unit + 4, fFrameSize); Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe at rabbit.tv Wed Apr 18 17:09:07 2012 From: philippe at rabbit.tv (Philippe Clavel) Date: Wed, 18 Apr 2012 17:09:07 -0700 Subject: [Live-devel] Ignoring SIGPIPE Message-ID: Hi, I have an issue on Mac OSX where the RTSPClient was throwing SIG_PIPE whenever the TCP connection from the server was terminated (server timeout or crash). Trying to USE_SIGNALS as below did not work and we were still crashing when the connection was dropping: #ifdef USE_SIGNALS // Ignore the SIGPIPE signal, so that clients on the same host that are killed // don't also kill us: signal(SIGPIPE, SIG_IGN); #endif The only way we found to fix ti was to set SO_NOSIGPIPE on the socket itself when created. if (newSocket > 0) { int set_option = 1; if (0 == setsockopt(newSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof(set_option))) { } else { socketErr(env,"failed to set socket signal option"); } } I have attached the source code with the change in GroupsockHelper.cpp . Will it be possible to include that change in an upcoming release? Let me know, Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GroupsockHelper.cpp Type: application/octet-stream Size: 23809 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix at embedded-sol.com Thu Apr 19 09:16:48 2012 From: felix at embedded-sol.com (Felix Radensky) Date: Thu, 19 Apr 2012 19:16:48 +0300 Subject: [Live-devel] Questions on MPEG2 Transport Stream Message-ID: <4F903A70.6090707@embedded-sol.com> Hi, I have a requirement to stream H.264 video coming from hardware encoder, audio (unknown format at the moment) and metadata (unknown format) all wrapped as MPEG-2 TS. Video and audio streams should be converted to PES before streaming. By looking at live555 code and documentation I can see that converting PES to TS and streaming of TS are supported, and multiplexing video and audio in TS is supported as well. What I'm missing is the code to convert ES to PES and streaming of metadata as part of TS. Is that supported as well ? If not can you please explain how can I add missing features. Thanks a lot. Felix. From finlayson at live555.com Thu Apr 19 18:14:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2012 11:14:39 +1000 Subject: [Live-devel] Ignoring SIGPIPE In-Reply-To: References: Message-ID: <1C55F47E-B68E-48D8-8643-F55C70AF49F4@live555.com> > I have an issue on Mac OSX where the RTSPClient was throwing SIG_PIPE whenever the TCP connection from the server was terminated (server timeout or crash). > Trying to USE_SIGNALS as below did not work and we were still crashing when the connection was dropping: > #ifdef USE_SIGNALS > // Ignore the SIGPIPE signal, so that clients on the same host that are killed > // don't also kill us: > signal(SIGPIPE, SIG_IGN); > #endif > > The only way we found to fix ti was to set SO_NOSIGPIPE on the socket itself when created. > > > if (newSocket > 0) { > int set_option = 1; > if (0 == setsockopt(newSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof(set_option))) { > } else { > socketErr(env,"failed to set socket signal option"); > } > } > > I have attached the source code with the change in GroupsockHelper.cpp . > Will it be possible to include that change in an upcoming release? No, because I don't want this behavior (ignoring SIGPIPE signals) to happen all the time. Instead, it should happen only when the developer specifically wants it. In this case, what we want is for the RTSP server to ignore SIGPIPE signals that might get sent when clients (running on the same host) die. So the right place to do this is in the "RTSPServer" code, in the same place where we currently do: #ifdef USE_SIGNALS // Ignore the SIGPIPE signal, so that clients on the same host that are killed // don't also kill us: signal(SIGPIPE, SIG_IGN); #endif What I might end up doing, therefore, is replace this code with: #ifdef USE_SIGNALS // Ignore the SIGPIPE signal, so that clients on the same host that are killed // don't also kill us: #ifdef SO_NOSIGPIPE int set_option = 1; setsockopt(ourSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof set_option); #else signal(SIGPIPE, SIG_IGN); #endif #endif I hope this will work for you... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 19 18:22:18 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2012 11:22:18 +1000 Subject: [Live-devel] Questions on MPEG2 Transport Stream In-Reply-To: <4F903A70.6090707@embedded-sol.com> References: <4F903A70.6090707@embedded-sol.com> Message-ID: <53928BC7-D1B8-43C6-9470-19334D8614CB@live555.com> > By looking at live555 code and documentation I can see that converting PES to > TS and streaming of TS are supported, and multiplexing video and audio in TS > is supported as well. What I'm missing is the code to convert ES to PES and > streaming of metadata as part of TS. Is that supported as well ? We also have code that will convert (video or audio) Elementary Streams to Transport Streams: the "MPEG2TransportStreamFromESSource" class. However, we don't have code for converting 'metadata' to Transport Streams. However, you should be able to do this yourself, by implementing your own subclass of "MPEG2TransportStreamMultiplexor". (Note that the two existing classes - "MPEG2TransportStreamFromESSource" and "MPEG2TransportStreamFromPESSource" - are also subclasses of "MPEG2TransportStreamMultiplexor".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishnaks at iwavesystems.com Thu Apr 19 22:17:01 2012 From: krishnaks at iwavesystems.com (krishnaks at iwavesystems.com) Date: Fri, 20 Apr 2012 10:47:01 +0530 Subject: [Live-devel] Live555 Library build for IOS 5.1 In-Reply-To: <001301cd1f1c$4019cb30$2a02a8c0@iwdtp219> References: <001301cd1f1c$4019cb30$2a02a8c0@iwdtp219> Message-ID: <029cd7f97da275403f918c9d0ed7f340.squirrel@124.124.219.233> Hi, I m trying to build Live 555 for IOS 5.1 I have updated config.iphoneos file for IOS 5.1.(config.iphoneos attached) But I am getting following make error /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-g++-4.2 -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch armv7 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk -Wall Media.cpp cc1plus: error: unrecognized command line option "-arch" make[1]: *** [Media.o] Error 1 make: *** [all] Error 2 What may be the issue? Thanks in advance -------------- next part -------------- A non-text attachment was scrubbed... Name: config.iphoneos Type: application/octet-stream Size: 1229 bytes Desc: not available URL: From mapedd at gmail.com Thu Apr 19 02:39:26 2012 From: mapedd at gmail.com (=?utf-8?Q?Tomasz_Ku=C5=BAma?=) Date: Thu, 19 Apr 2012 11:39:26 +0200 Subject: [Live-devel] MJPEG -> MKV Message-ID: <683FF2B4-3B62-45E9-AD3F-468E6BE00808@gmail.com> Hi i've just started my journey with Live555 library and my first task is quite hard :) I've got RSTP incoming stream with video in MJPEG format in it. My job is to save this stream to disk as a mkv file. As far as i know to save some video file to MKV container i can use mkvmerge tool from mkvtoolnix. But the problem here is how to save MJPEG video stream to something compatible with matroska ... Does live555 have built in support to do such a thing? Does saving it as a MPEG4 will do the job? Does any of the testPrograms from live555 source can do that? Thanks for any help guys! Pozdrawiam Tomek Ku?ma From finlayson at live555.com Thu Apr 19 23:35:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2012 16:35:55 +1000 Subject: [Live-devel] MJPEG -> MKV In-Reply-To: <683FF2B4-3B62-45E9-AD3F-468E6BE00808@gmail.com> References: <683FF2B4-3B62-45E9-AD3F-468E6BE00808@gmail.com> Message-ID: > My job is to save this stream to disk as a mkv file. As far as i know to save some video file to MKV container i can use mkvmerge tool from mkvtoolnix. But the problem here is how to save MJPEG video stream to something compatible with matroska ... > > Does live555 have built in support to do such a thing? Sorry, no. There's currently no support in the library for writing a Matroska file (only for streaming from (i.e., reading from) such files). > Does saving it as a MPEG4 will do the job? No (because a "MPEG4" file is not a Matroska file). > Does any of the testPrograms from live555 source can do that? No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vad at vad.pp.ru Fri Apr 20 02:05:15 2012 From: vad at vad.pp.ru (Vadim Kosarev) Date: Fri, 20 Apr 2012 15:05:15 +0600 Subject: [Live-devel] Two possible problems in RTSPServer class Message-ID: Hello Ross! 1. I have seen possible ServerMediaSession object leak in RTSPServer::RTSPClientSession::handleCmd_SETUP method. This method changes client session object member variable fOurServerMediaSession (pointer to ServerMediaSession) and calls fOurServerMediaSession->incrementReferenceCount() if this ServerMediaSession is really changed. But this method does not call decrementReferenceCount() on previously stored ServerMediaSession (if any). So if an RTSP client will send two SETUP commands referring different streams then ServerMediaSession object of stream of first SETUP command will have excess reference counter increment that will prevent this ServerMediaSession object from being deleted. Maybe there are no such RTSP client but I think any protection against harmful behaviour of other software is welcome. 2. Also I have seen possible ServerMediaSession object relations bug in RTSPServer::addServerMediaSession/RTSPServer::removeServerMediaSession methods. Method addServerMediaSession adds a ServerMediaSession object to hashmap fServerMediaSessions and call removeServerMediaSession on ServerMediaSession object previously set in the hashmap (if both objects have same stream name). Method removeServerMediaSession removes from the hashmap new ServerMediaSession object just added by addServerMediaSession. This breaks objects relations. I think removeServerMediaSession must check if specified ServerMediaSession object still in the hashmap before call fServerMediaSessions->Remove. I have found these bugs when I start code ServerMediaSession objects replacing on live source properties changing. From felix at embedded-sol.com Fri Apr 20 08:51:47 2012 From: felix at embedded-sol.com (Felix Radensky) Date: Fri, 20 Apr 2012 18:51:47 +0300 Subject: [Live-devel] Questions on MPEG2 Transport Stream In-Reply-To: <53928BC7-D1B8-43C6-9470-19334D8614CB@live555.com> References: <4F903A70.6090707@embedded-sol.com> <53928BC7-D1B8-43C6-9470-19334D8614CB@live555.com> Message-ID: <4F918613.60108@embedded-sol.com> Hi Ross, Thanks a lot for replying. On 04/20/2012 04:22 AM, Ross Finlayson wrote: >> By looking at live555 code and documentation I can see that >> converting PES to >> TS and streaming of TS are supported, and multiplexing video and >> audio in TS >> is supported as well. What I'm missing is the code to convert ES >> to PES and >> streaming of metadata as part of TS. Is that supported as well ? > > We also have code that will convert (video or audio) Elementary > Streams to Transport Streams: the "MPEG2TransportStreamFromESSource" > class. Does it mean that converting ES to PES is not necessary if ES can be converted to TS directly ? Thanks. Felix. From philippe at rabbit.tv Fri Apr 20 08:53:38 2012 From: philippe at rabbit.tv (Philippe Clavel) Date: Fri, 20 Apr 2012 08:53:38 -0700 Subject: [Live-devel] Ignoring SIGPIPE In-Reply-To: References: Message-ID: <-6571625502045365506@unknownmsgid> Hi, First I am not sure the right way to reply only to my message... Let me know how to do it right for next time ;) Regarding the proposed change it work for me. Just one comment you may want to do something like that only > #ifdef USE_SIGNALS > // Ignore the SIGPIPE signal, so that clients on the same host that are killed > // don't also kill us: > #ifdef SO_NOSIGPIPE > int set_option = 1; > setsockopt(ourSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof set_option); > #endif > #endif As the other portion of the code should be needed to be done only ounce at start of the app (and not everytime we create a socket). But that work just fine ;) Thanks! Philippe On Apr 20, 2012, at 12:08 AM, "live-devel-request at ns.live555.com" wrote: > Send live-devel mailing list submissions to > live-devel at lists.live555.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.live555.com/mailman/listinfo/live-devel > or, via email, send a message with subject or body 'help' to > live-devel-request at lists.live555.com > > You can reach the person managing the list at > live-devel-owner at lists.live555.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of live-devel digest..." > > > Today's Topics: > > 1. Questions on MPEG2 Transport Stream (Felix Radensky) > 2. Re: Ignoring SIGPIPE (Ross Finlayson) > 3. Re: Questions on MPEG2 Transport Stream (Ross Finlayson) > 4. Live555 Library build for IOS 5.1 (krishnaks at iwavesystems.com) > 5. MJPEG -> MKV (Tomasz Ku?ma) > 6. Re: MJPEG -> MKV (Ross Finlayson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Apr 2012 19:16:48 +0300 > From: Felix Radensky > To: live-devel at ns.live555.com > Subject: [Live-devel] Questions on MPEG2 Transport Stream > Message-ID: <4F903A70.6090707 at embedded-sol.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > I have a requirement to stream H.264 video coming from hardware encoder, > audio (unknown format at the moment) and metadata (unknown format) all > wrapped as MPEG-2 TS. Video and audio streams should be converted to PES > before streaming. > > By looking at live555 code and documentation I can see that converting > PES to > TS and streaming of TS are supported, and multiplexing video and audio > in TS > is supported as well. What I'm missing is the code to convert ES to > PES and > streaming of metadata as part of TS. Is that supported as well ? If > not can you > please explain how can I add missing features. > > Thanks a lot. > > Felix. > > > ------------------------------ > > Message: 2 > Date: Fri, 20 Apr 2012 11:14:39 +1000 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] Ignoring SIGPIPE > Message-ID: <1C55F47E-B68E-48D8-8643-F55C70AF49F4 at live555.com> > Content-Type: text/plain; charset="us-ascii" > >> I have an issue on Mac OSX where the RTSPClient was throwing SIG_PIPE whenever the TCP connection from the server was terminated (server timeout or crash). >> Trying to USE_SIGNALS as below did not work and we were still crashing when the connection was dropping: >> #ifdef USE_SIGNALS >> // Ignore the SIGPIPE signal, so that clients on the same host that are killed >> // don't also kill us: >> signal(SIGPIPE, SIG_IGN); >> #endif >> >> The only way we found to fix ti was to set SO_NOSIGPIPE on the socket itself when created. >> >> >> if (newSocket > 0) { >> int set_option = 1; >> if (0 == setsockopt(newSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof(set_option))) { >> } else { >> socketErr(env,"failed to set socket signal option"); >> } >> } >> >> I have attached the source code with the change in GroupsockHelper.cpp . >> Will it be possible to include that change in an upcoming release? > > No, because I don't want this behavior (ignoring SIGPIPE signals) to happen all the time. Instead, it should happen only when the developer specifically wants it. > > In this case, what we want is for the RTSP server to ignore SIGPIPE signals that might get sent when clients (running on the same host) die. So the right place to do this is in the "RTSPServer" code, in the same place where we currently do: > #ifdef USE_SIGNALS > // Ignore the SIGPIPE signal, so that clients on the same host that are killed > // don't also kill us: > signal(SIGPIPE, SIG_IGN); > #endif > > What I might end up doing, therefore, is replace this code with: > #ifdef USE_SIGNALS > // Ignore the SIGPIPE signal, so that clients on the same host that are killed > // don't also kill us: > #ifdef SO_NOSIGPIPE > int set_option = 1; > setsockopt(ourSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof set_option); > #else > signal(SIGPIPE, SIG_IGN); > #endif > #endif > > I hope this will work for you... > > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Fri, 20 Apr 2012 11:22:18 +1000 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] Questions on MPEG2 Transport Stream > Message-ID: <53928BC7-D1B8-43C6-9470-19334D8614CB at live555.com> > Content-Type: text/plain; charset="us-ascii" > >> By looking at live555 code and documentation I can see that converting PES to >> TS and streaming of TS are supported, and multiplexing video and audio in TS >> is supported as well. What I'm missing is the code to convert ES to PES and >> streaming of metadata as part of TS. Is that supported as well ? > > We also have code that will convert (video or audio) Elementary Streams to Transport Streams: the "MPEG2TransportStreamFromESSource" class. > > However, we don't have code for converting 'metadata' to Transport Streams. However, you should be able to do this yourself, by implementing your own subclass of "MPEG2TransportStreamMultiplexor". (Note that the two existing classes - "MPEG2TransportStreamFromESSource" and "MPEG2TransportStreamFromPESSource" - are also subclasses of "MPEG2TransportStreamMultiplexor".) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 4 > Date: Fri, 20 Apr 2012 10:47:01 +0530 > From: krishnaks at iwavesystems.com > To: live-devel at ns.live555.com > Subject: [Live-devel] Live555 Library build for IOS 5.1 > Message-ID: > <029cd7f97da275403f918c9d0ed7f340.squirrel at 124.124.219.233> > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Hi, > > I m trying to build Live 555 for IOS 5.1 > I have updated config.iphoneos file for IOS 5.1.(config.iphoneos attached) > But I am getting following make error > > > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-g++-4.2 > -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. > -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 > -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch armv7 > --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk > -Wall Media.cpp > cc1plus: error: unrecognized command line option "-arch" > make[1]: *** [Media.o] Error 1 > make: *** [all] Error 2 > > > What may be the issue? > > Thanks in advance > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: config.iphoneos > Type: application/octet-stream > Size: 1229 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 5 > Date: Thu, 19 Apr 2012 11:39:26 +0200 > From: Tomasz Ku?ma > To: "live-devel at ns.live555.com" > Subject: [Live-devel] MJPEG -> MKV > Message-ID: <683FF2B4-3B62-45E9-AD3F-468E6BE00808 at gmail.com> > Content-Type: text/plain; charset=utf-8 > > Hi > > > > i've just started my journey with Live555 library and my first task is quite hard :) > > I've got RSTP incoming stream with video in MJPEG format in it. > > My job is to save this stream to disk as a mkv file. As far as i know to save some video file to MKV container i can use mkvmerge tool from mkvtoolnix. But the problem here is how to save MJPEG video stream to something compatible with matroska ... > > Does live555 have built in support to do such a thing? Does saving it as a MPEG4 will do the job? Does any of the testPrograms from live555 source can do that? > > Thanks for any help guys! > > Pozdrawiam > Tomek Ku?ma > > > ------------------------------ > > Message: 6 > Date: Fri, 20 Apr 2012 16:35:55 +1000 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] MJPEG -> MKV > Message-ID: > Content-Type: text/plain; charset="us-ascii" > >> My job is to save this stream to disk as a mkv file. As far as i know to save some video file to MKV container i can use mkvmerge tool from mkvtoolnix. But the problem here is how to save MJPEG video stream to something compatible with matroska ... >> >> Does live555 have built in support to do such a thing? > > Sorry, no. There's currently no support in the library for writing a Matroska file (only for streaming from (i.e., reading from) such files). > > >> Does saving it as a MPEG4 will do the job? > > No (because a "MPEG4" file is not a Matroska file). > > >> Does any of the testPrograms from live555 source can do that? > > No. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > End of live-devel Digest, Vol 102, Issue 22 > ******************************************* From finlayson at live555.com Fri Apr 20 17:35:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Apr 2012 10:35:07 +1000 Subject: [Live-devel] Ignoring SIGPIPE In-Reply-To: <-6571625502045365506@unknownmsgid> References: <-6571625502045365506@unknownmsgid> Message-ID: <7E5DC7C5-8258-4B00-A909-B8B0E96264F4@live555.com> > Regarding the proposed change it work for me. > Just one comment you may want to do something like that only >> #ifdef USE_SIGNALS >> // Ignore the SIGPIPE signal, so that clients on the same host that are killed >> // don't also kill us: >> #ifdef SO_NOSIGPIPE >> int set_option = 1; >> setsockopt(ourSocket, SOL_SOCKET, SO_NOSIGPIPE, &set_option, sizeof set_option); >> #endif >> #endif > > As the other portion of the code should be needed to be done only > ounce at start of the app (and not everytime we create a socket). The "#else" part of the code that I suggested - i.e., the line signal(SIGPIPE, SIG_IGN); was intended for those systems - if any - that don't define "SO_NOSIGPIPE" (but do define "SIGPIPE"). (Also, because this code will be executed in the "RTSPServer" constructor, it will usually be done only once per process, because most processes won't create more than one "RTSPServer" object.) But anyway, I'll include this change in a future 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 Apr 21 00:08:36 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Apr 2012 17:08:36 +1000 Subject: [Live-devel] Introducing the "LIVE555 Proxy Server" Message-ID: <3DD4599A-3804-4AE0-88F6-A044FE984CA3@live555.com> The latest release (2012.04.21) of the "LIVE555 Streaming Media" software includes a new application - the "LIVE555 Proxy Server" - which is documented at: http://www.live555.com/proxyServer/ This server acts as a unicast RTSP 'proxy' for one or more back-end (unicast or multicast) streams. It maintains a single connection to the back-end stream, regardless of how many clients are streaming from the proxy. It is ideal, for example, for streaming from a RTSP-enabled video camera (which might not be able to handle more than one connection at a time). The "LIVE555 Proxy Server" is build automatically in the "proxyServer" subdirectory of the top-level "live" directory. It uses the new "ProxyServerMediaSession" class. If you want to build your own RTSP 'proxy server', you can use this class. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 21 12:38:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2012 05:38:59 +1000 Subject: [Live-devel] Questions on MPEG2 Transport Stream In-Reply-To: <4F918613.60108@embedded-sol.com> References: <4F903A70.6090707@embedded-sol.com> <53928BC7-D1B8-43C6-9470-19334D8614CB@live555.com> <4F918613.60108@embedded-sol.com> Message-ID: <9E99EAFE-AB50-4BA2-85D4-51FF9B6A67C1@live555.com> >> We also have code that will convert (video or audio) Elementary Streams to Transport Streams: the "MPEG2TransportStreamFromESSource" class. > > Does it mean that converting ES to PES is not necessary if ES can be converted to TS directly ? Yes, because the "MPEG2TransportStreamFromESSource" class is implemented by attaching a simple PES header to the input; if you use that class, you don't need to do that yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Fri Apr 20 02:28:54 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Fri, 20 Apr 2012 12:28:54 +0300 Subject: [Live-devel] Live555 RTSP Proxy Server Message-ID: <1A249ECA3EA5474A99C51A940C8FEC2C@work> hello, i compiled Live555 Library today i don't see the RTSP Proxy server in testprog directory is somewhere else ? thank you, Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6830 (20120126) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From keary.griffin at unwiredappeal.com Sat Apr 21 10:32:58 2012 From: keary.griffin at unwiredappeal.com (Keary Griffin) Date: Sat, 21 Apr 2012 13:32:58 -0400 Subject: [Live-devel] Patch to help support SRTP Message-ID: <4F92EF4A.6060905@unwiredappeal.com> Hi, I've been using the attached patch in combination with VLC to support SRTP streams. The patch simply changes the AuxHandlerFunction to pass the packetSize by reference so it can be changed. The actual packetSize for SRTP will be less than the original packetSize after decryption and removal of some encryption header information. It would be great to get this change (or something else that I could use to accomplish the same thing) into the main line of the live555 library-- I don't want to submit my SRTP patches to VLC until the changes necessary are already in live555. I do realize this changes the API of live555, so make break existing applications. Any recommendations on how to support changing packetSize without breaking the API would be welcome as well. Thanks, Keary -------------- next part -------------- A non-text attachment was scrubbed... Name: live-auxhandler-patch.patch Type: text/x-diff Size: 731 bytes Desc: not available URL: From mapedd at gmail.com Fri Apr 20 02:27:29 2012 From: mapedd at gmail.com (=?UTF-8?Q?Tomasz_Ku=C5=BAma?=) Date: Fri, 20 Apr 2012 11:27:29 +0200 Subject: [Live-devel] MJPEG -> MKV In-Reply-To: References: <683FF2B4-3B62-45E9-AD3F-468E6BE00808@gmail.com> Message-ID: 2012/4/20 Ross Finlayson > My job is to save this stream to disk as a mkv file. As far as i know to > save some video file to MKV container i can use mkvmerge tool from > mkvtoolnix. But the problem here is how to save MJPEG video stream to > something compatible with matroska ... > > Does live555 have built in support to do such a thing? > > > Sorry, no. There's currently no support in the library for writing a > Matroska file (only for streaming from (i.e., reading from) such files). > Ok, i was expecting this. In that case how can i save MJPEG video stream to disk, so that, later with help of tool like mkvtoolnix i can pack this video file to mkv? Proper file saving is crucial in this case, AVIFileSink doesn't work as axpected. I belive that saving this stream and encoding to MPEG4 will do the job, later on i could merge this file to MKV, is this correct? > > > Does saving it as a MPEG4 will do the job? > > > No (because a "MPEG4" file is not a Matroska file). > > > Does any of the testPrograms from live555 source can do that? > > > No. > > > 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 > > -- Pozdrawiam Tomek Ku?ma GG: 5828446 mapedd at gmaill.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 21 13:02:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2012 06:02:05 +1000 Subject: [Live-devel] MJPEG -> MKV In-Reply-To: References: <683FF2B4-3B62-45E9-AD3F-468E6BE00808@gmail.com> Message-ID: <73D0392F-B615-469F-85D6-BD6D64CA35E3@live555.com> >> My job is to save this stream to disk as a mkv file. As far as i know to save some video file to MKV container i can use mkvmerge tool from mkvtoolnix. But the problem here is how to save MJPEG video stream to something compatible with matroska ... >> >> Does live555 have built in support to do such a thing? > > Sorry, no. There's currently no support in the library for writing a Matroska file (only for streaming from (i.e., reading from) such files). > > > Ok, i was expecting this. In that case how can i save MJPEG video stream to disk Note that each MJPEG video 'frame' will be a complete JPEG image. If you save each incoming frame to disk - as a separate JPEG file - then you can later do whatever you want with these files (using some other library, not ours, because our library doesn't include any decoding/encoding/transcoding). The way to do this is to use the "FileSink" class, but setting the "oneFilePerFrame" parameter to "True". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 21 13:18:16 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2012 06:18:16 +1000 Subject: [Live-devel] Live555 RTSP Proxy Server In-Reply-To: <1A249ECA3EA5474A99C51A940C8FEC2C@work> References: <1A249ECA3EA5474A99C51A940C8FEC2C@work> Message-ID: <23970B1D-ADB3-40C0-B5B2-7B9F780CCF40@live555.com> > i don't see the RTSP Proxy server in testprog directory That's because it's in the "proxyServer" directory instead. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 21 13:29:10 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2012 06:29:10 +1000 Subject: [Live-devel] Patch to help support SRTP In-Reply-To: <4F92EF4A.6060905@unwiredappeal.com> References: <4F92EF4A.6060905@unwiredappeal.com> Message-ID: <03C4D04D-DD06-4579-9826-EAA7B7B584F9@live555.com> > I've been using the attached patch in combination with VLC to support SRTP streams. The patch simply changes the AuxHandlerFunction to pass the packetSize by reference so it can be changed. The actual packetSize for SRTP will be less than the original packetSize after decryption and removal of some encryption header information. Thanks for the note. I wasn't sure if anyone was actually using the "setAuxilliaryReadHandler()" mechanism anymore, so it was interesting to read that it was being used to implement SRTP. > It would be great to get this change (or something else that I could use to accomplish the same thing) into the main line of the live555 library Yes, this will be included in the next release of the library. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Fri Apr 20 12:32:21 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Fri, 20 Apr 2012 22:32:21 +0300 Subject: [Live-devel] Live555 RTSP Proxy Server References: <1A249ECA3EA5474A99C51A940C8FEC2C@work> <23970B1D-ADB3-40C0-B5B2-7B9F780CCF40@live555.com> Message-ID: <9BE0FE90A9FD4A178FB1C7366DABD7E9@work> thank you a lot ross, what about transcoding please ? ----- Original Message ----- From: "Ross Finlayson" To: "LIVE555 Streaming Media - development & use" Sent: Saturday, April 21, 2012 11:18 PM Subject: Re: [Live-devel] Live555 RTSP Proxy Server >> i don't see the RTSP Proxy server in testprog directory > > That's because it's in the "proxyServer" directory instead. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6830 (20120126) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6830 (20120126) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6830 (20120126) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From finlayson at live555.com Sat Apr 21 18:45:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2012 11:45:02 +1000 Subject: [Live-devel] Live555 RTSP Proxy Server In-Reply-To: <9BE0FE90A9FD4A178FB1C7366DABD7E9@work> References: <1A249ECA3EA5474A99C51A940C8FEC2C@work> <23970B1D-ADB3-40C0-B5B2-7B9F780CCF40@live555.com> <9BE0FE90A9FD4A178FB1C7366DABD7E9@work> Message-ID: > what about transcoding please ? Our libraries do not include any decoding, encoding, or transcoding support. That's something you'd need to do yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 21 22:46:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2012 15:46:51 +1000 Subject: [Live-devel] Two possible problems in RTSPServer class In-Reply-To: References: Message-ID: <64C2C7BE-B757-4B9D-B8D6-3C04798BB289@live555.com> > 1. I have seen possible ServerMediaSession object leak in > RTSPServer::RTSPClientSession::handleCmd_SETUP method. > This method changes client session object member variable > fOurServerMediaSession (pointer to ServerMediaSession) and calls > fOurServerMediaSession->incrementReferenceCount() if this > ServerMediaSession is really changed. But this method does not call > decrementReferenceCount() on previously stored ServerMediaSession (if > any). So if an RTSP client will send two SETUP commands referring > different streams then ServerMediaSession object of stream of first > SETUP command will have excess reference counter increment that will > prevent this ServerMediaSession object from being deleted. Maybe there > are no such RTSP client but I think any protection against harmful > behaviour of other software is welcome. Yes, there exist unusual situations in which the reference count might get too high, but fixing this is not a high priority, because in the most common situations, the reference count will get set correctly. (Also, it is relatively unusual for "removeServerMediaSession()" to be called.) > 2. Also I have seen possible ServerMediaSession object relations bug > in RTSPServer::addServerMediaSession/RTSPServer::removeServerMediaSession > methods. > Method addServerMediaSession adds a ServerMediaSession object to > hashmap fServerMediaSessions and call removeServerMediaSession on > ServerMediaSession object previously set in the hashmap (if both > objects have same stream name). Method removeServerMediaSession > removes from the hashmap new ServerMediaSession object just added by > addServerMediaSession. Yes, this is a bug. It will get fixed in a future release. (Perhaps then I'll address the first issue also :-) Thanks for reporting this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mapedd at gmail.com Sat Apr 21 15:25:00 2012 From: mapedd at gmail.com (=?utf-8?Q?Tomasz_Ku=C5=BAma?=) Date: Sun, 22 Apr 2012 00:25:00 +0200 Subject: [Live-devel] MJPEG -> MKV In-Reply-To: <73D0392F-B615-469F-85D6-BD6D64CA35E3@live555.com> References: <683FF2B4-3B62-45E9-AD3F-468E6BE00808@gmail.com> <73D0392F-B615-469F-85D6-BD6D64CA35E3@live555.com> Message-ID: <5C43F301-9109-42E9-B80D-F71CF77249D0@gmail.com> Thank you so much for this answer, i was suspecting this is the case, now i'm sure. I'll use ffmpeg to enocode those single jpeg files to some useful video format. Thanks again for help! Pozdrawiam Tomek Ku?ma Dnia 21 kwi 2012 o godz. 22:02 Ross Finlayson napisa?(a): >>> My job is to save this stream to disk as a mkv file. As far as i know to save some video file to MKV container i can use mkvmerge tool from mkvtoolnix. But the problem here is how to save MJPEG video stream to something compatible with matroska ... >>> >>> Does live555 have built in support to do such a thing? >> >> Sorry, no. There's currently no support in the library for writing a Matroska file (only for streaming from (i.e., reading from) such files). >> >> >> Ok, i was expecting this. In that case how can i save MJPEG video stream to disk > > Note that each MJPEG video 'frame' will be a complete JPEG image. If you save each incoming frame to disk - as a separate JPEG file - then you can later do whatever you want with these files (using some other library, not ours, because our library doesn't include any decoding/encoding/transcoding). > > The way to do this is to use the "FileSink" class, but setting the "oneFilePerFrame" parameter to "True". > > > 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 krishnaks at iwavesystems.com Mon Apr 23 10:03:21 2012 From: krishnaks at iwavesystems.com (Krishna) Date: Mon, 23 Apr 2012 10:03:21 -0700 Subject: [Live-devel] Live555 Library build for IOS 5.1 References: <001301cd1f1c$4019cb30$2a02a8c0@iwdtp219> <029cd7f97da275403f918c9d0ed7f340.squirrel@124.124.219.233> Message-ID: <012901cd2172$fcf97e50$2a02a8c0@iwdtp219> Any reply on this?? ----- Original Message ----- From: To: Sent: Thursday, April 19, 2012 10:17 PM Subject: [Live-devel] Live555 Library build for IOS 5.1 > > > > > Hi, > > I m trying to build Live 555 for IOS 5.1 > I have updated config.iphoneos file for IOS 5.1.(config.iphoneos attached) > But I am getting following make error > > > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-g++-4.2 > -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. > -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 > -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch armv7 > --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk > -Wall Media.cpp > cc1plus: error: unrecognized command line option "-arch" > make[1]: *** [Media.o] Error 1 > make: *** [all] Error 2 > > > What may be the issue? > > Thanks in advance > > -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From ashfaque at iwavesystems.com Mon Apr 23 06:55:55 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Mon, 23 Apr 2012 19:25:55 +0530 Subject: [Live-devel] waiting on DESCRIBE response Message-ID: <3CEA61959BDC4ADCB252BF8B18523024@iwns10> Hi Ross, I am getting following messages on Client side when playing the URL with testRTSPClient application. Received 1448 new bytes of response data. Have received 1448 total bytes of a DESCRIBE RTSP response; awaiting 30924 bytes more. Received 2896 new bytes of response data. Have received 4344 total bytes of a DESCRIBE RTSP response; awaiting 28028 bytes more. Received 2896 new bytes of response data. Have received 7240 total bytes of a DESCRIBE RTSP response; awaiting 25132 bytes more. Received 2759 new bytes of response data. Have received 9999 total bytes of a DESCRIBE RTSP response; awaiting 22373 bytes more. After this it will hang here and does not proceed further. Very few times it will get connected and starts streaming. I am not able to track the reason for this. I am using a H264 encoded file in the transmitter side due to unavailability of camera device. Please let me know the reason for this and how it can be resolved. Thanks & Regards, Ashfaque -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 23 12:16:11 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2012 07:16:11 +1200 Subject: [Live-devel] waiting on DESCRIBE response In-Reply-To: <3CEA61959BDC4ADCB252BF8B18523024@iwns10> References: <3CEA61959BDC4ADCB252BF8B18523024@iwns10> Message-ID: <57D1CA94-229E-4AED-806D-3BBF63F2539A@live555.com> > I am getting following messages on Client side when playing the URL with testRTSPClient application. > > > Received 1448 new bytes of response data. > Have received 1448 total bytes of a DESCRIBE RTSP response; awaiting 30924 bytes more. > Received 2896 new bytes of response data. > Have received 4344 total bytes of a DESCRIBE RTSP response; awaiting 28028 bytes more. > Received 2896 new bytes of response data. > Have received 7240 total bytes of a DESCRIBE RTSP response; awaiting 25132 bytes more. > Received 2759 new bytes of response data. > Have received 9999 total bytes of a DESCRIBE RTSP response; awaiting 22373 bytes more. > > After this it will hang here and does not proceed further. The problem is that your server is including - in its response to the client's RTSP "DESCRIBE" command - a "Content-Length:" header that specifies a response payload content (in this case a "SDP description") that's much too big. You should be able to see this clearly by noting the "Content-Length:" header in the response that's received by "testRTSPClient". I.e., the problem is that your server is broken. (If you had used our software to implement your server, then you would not have had this problem :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.liu17 at gmail.com Sun Apr 22 22:09:33 2012 From: daniel.liu17 at gmail.com (=?GB2312?B?wfXB+rfJ?=) Date: Mon, 23 Apr 2012 13:09:33 +0800 Subject: [Live-devel] Need the OutPacketBuffer be that larger(fLimit)? Message-ID: Dear Sir, I found the outpacketBuffer size is almost the same as the input buffer. when set the OutPacketBuffer::maxSize = 60000, the outpacketBuffer size is 60816 bytes, and the fInputBuffer in H264FUAFragmenter is 60000. I traced the "fPacketStart" and "fCurOffset" in OutPacketBuffer class( I just send H264 video and pcma audio only). For fPacketStart, it's 0 after each RTP packet is send. And the fCurOffset is always smaller than 1448 (max rtp packet size). So, my question is, need the outpacketBuffer be that larger, up to 60816 bytes? The left space size (60816-1448) is not used. right? In my opinion, it just need to be a little larger than 1448, such as 1500. Pls confirm and give me some advise,thank you very much! --Daniel Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmendiondo at electrochance.com Mon Apr 23 06:32:59 2012 From: hmendiondo at electrochance.com (Hugo Mendiondo) Date: Mon, 23 Apr 2012 10:32:59 -0300 Subject: [Live-devel] Live video Message-ID: <000b01cd2155$9f1e9210$dd5bb630$@com> Hello, I want to know if it is possible to send live video streaming with this library. I mean, I need to connect an IP camera to my server and send live video to other PC. I have made some tests with the media server using VLC as client and it Works ok. Thanks. Sin t?tulo.jpg Hugo Mendiondo ELECTRO CHANCE S.R.L. Av. General Paz 13095, L. del Mirador (B1752CGM) Pcia. de Buenos Aires Tel?fono planta: +54 11 4453-8860 int: 102 website: www.electrochance.com ________________.___________________________________________________________ _________________________________________ La informaci?n contenida en este correo electr?nico es para uso exclusivo de los destinatarios del mismo. Esta prohibido a las personas o entidades que no sean los destinatarios de este correo, realizar cualquier tipo de modificaci?n, copia o distribuci?n del mismo. Si Ud. recibe este correo por error, tenga a bien notificar al emisor y luego eliminarlo. The information transmitted is intended only for the person or entity to witch it is addressed and may contain confidential and/ or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this an error, please contact the sender and delete the material from any computer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1104 bytes Desc: not available URL: From finlayson at live555.com Mon Apr 23 12:50:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2012 07:50:17 +1200 Subject: [Live-devel] Need the OutPacketBuffer be that larger(fLimit)? In-Reply-To: References: Message-ID: <85EE2AB3-024A-4F6F-BF57-D5FE8F79B761@live555.com> > So, my question is, need the outpacketBuffer be that larger, up to 60816 bytes? In general, "OutPacketBuffer::maxSize" should be at least as large as the largest single frame of data that you expect to feed into your "RTPSink" (subclass) object. This will usually be larger than the network packet size, in which case our code (i.e. our implementation of the appropriate RTP payload format) will fragment each frame of data - as appropriate - so that it fits properly into outgoing RTP packets. However, H.264 is an exception to this, because we implement its RTP payload format somewhat differently. For H.264, we place a separate 'fragmenter' object (a "H264FUAFragmenter") in front of the "RTPSink"; this 'fragmenter' object delivers 'fragment' NAL units that are small enough to fit into an outgoing RTP packet. NOTE, HOWEVER, that "H264FUAFragmenter" uses "OutPacketBuffer::maxSize" to figure out how big to make *its own* internal buffer, and this buffer needs to be at least as large as the largest H.264 NAL unit delivered by your data source (encoder) - so you should not reduce "OutPacketBuffer::maxSize", just because you are only delivering H.264. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 23 12:51:31 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2012 07:51:31 +1200 Subject: [Live-devel] Live video In-Reply-To: <000b01cd2155$9f1e9210$dd5bb630$@com> References: <000b01cd2155$9f1e9210$dd5bb630$@com> Message-ID: <4FF50EA2-0F85-4694-806D-F3754112292F@live555.com> > I want to know if it is possible to send live video streaming with this library. > I mean, I need to connect an IP camera to my server and send live video to other PC. READ THE FAQ (as you were asked to do before posting to the mailing list). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Mon Apr 23 22:50:58 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Tue, 24 Apr 2012 11:20:58 +0530 Subject: [Live-devel] waiting on DESCRIBE response In-Reply-To: <57D1CA94-229E-4AED-806D-3BBF63F2539A@live555.com> References: <3CEA61959BDC4ADCB252BF8B18523024@iwns10> <57D1CA94-229E-4AED-806D-3BBF63F2539A@live555.com> Message-ID: <7ED64D8837C44D18B484DBFDE514E9DF@iwns10> Hi Ross, I am using Live555 server application only. Reference is taken from testH264VideoStreamer as reference. H264VideoStreamDiscreteFramer is used as the framer. the problem is that your server is broken. What does this mean? The cause for this? Regards, Ashfaque From: Ross Finlayson Sent: Tuesday, April 24, 2012 12:46 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] waiting on DESCRIBE response I am getting following messages on Client side when playing the URL with testRTSPClient application. Received 1448 new bytes of response data. Have received 1448 total bytes of a DESCRIBE RTSP response; awaiting 30924 bytes more. Received 2896 new bytes of response data. Have received 4344 total bytes of a DESCRIBE RTSP response; awaiting 28028 bytes more. Received 2896 new bytes of response data. Have received 7240 total bytes of a DESCRIBE RTSP response; awaiting 25132 bytes more. Received 2759 new bytes of response data. Have received 9999 total bytes of a DESCRIBE RTSP response; awaiting 22373 bytes more. After this it will hang here and does not proceed further. The problem is that your server is including - in its response to the client's RTSP "DESCRIBE" command - a "Content-Length:" header that specifies a response payload content (in this case a "SDP description") that's much too big. You should be able to see this clearly by noting the "Content-Length:" header in the response that's received by "testRTSPClient". I.e., the problem is that your server is broken. (If you had used our software to implement your server, then you would not have had this problem :-) 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 Apr 23 23:05:44 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2012 18:05:44 +1200 Subject: [Live-devel] waiting on DESCRIBE response In-Reply-To: <7ED64D8837C44D18B484DBFDE514E9DF@iwns10> References: <3CEA61959BDC4ADCB252BF8B18523024@iwns10> <57D1CA94-229E-4AED-806D-3BBF63F2539A@live555.com> <7ED64D8837C44D18B484DBFDE514E9DF@iwns10> Message-ID: <574DFE63-FAA9-447B-9E1F-B173E88A4191@live555.com> > I am using Live555 server application only. Reference is taken from testH264VideoStreamer as reference. OK, thanks for the clarification. Please put your "test.264" on a web server, and send us the URL, so we can download it and test it ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishnaks at iwavesystems.com Tue Apr 24 11:27:01 2012 From: krishnaks at iwavesystems.com (Krishna) Date: Tue, 24 Apr 2012 11:27:01 -0700 Subject: [Live-devel] Live555 Library build for IOS 5.1 References: <001301cd1f1c$4019cb30$2a02a8c0@iwdtp219><029cd7f97da275403f918c9d0ed7f340.squirrel@124.124.219.233> <012901cd2172$fcf97e50$2a02a8c0@iwdtp219> Message-ID: <001f01cd2247$d785b960$2a02a8c0@iwdtp219> Hi, I have updated config.iphoneos (config.iphoneos attached) and able to build static libraries for iphoneos. Regards, KP ----- Original Message ----- From: "Krishna" To: "LIVE555 Streaming Media - development & use" Sent: Monday, April 23, 2012 10:03 AM Subject: Re: [Live-devel] Live555 Library build for IOS 5.1 > Any reply on this?? > > ----- Original Message ----- > From: > To: > Sent: Thursday, April 19, 2012 10:17 PM > Subject: [Live-devel] Live555 Library build for IOS 5.1 > > >> >> >> >> >> Hi, >> >> I m trying to build Live 555 for IOS 5.1 >> I have updated config.iphoneos file for IOS 5.1.(config.iphoneos >> attached) >> But I am getting following make error >> >> >> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-g++-4.2 >> -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. >> -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 >> -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch armv7 >> --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk >> -Wall Media.cpp >> cc1plus: error: unrecognized command line option "-arch" >> make[1]: *** [Media.o] Error 1 >> make: *** [all] Error 2 >> >> >> What may be the issue? >> >> Thanks in advance >> >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: config.iphoneos Type: application/octet-stream Size: 1148 bytes Desc: not available URL: From ashfaque at iwavesystems.com Mon Apr 23 23:42:32 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Tue, 24 Apr 2012 12:12:32 +0530 Subject: [Live-devel] waiting on DESCRIBE response In-Reply-To: <574DFE63-FAA9-447B-9E1F-B173E88A4191@live555.com> References: <3CEA61959BDC4ADCB252BF8B18523024@iwns10><57D1CA94-229E-4AED-806D-3BBF63F2539A@live555.com><7ED64D8837C44D18B484DBFDE514E9DF@iwns10> <574DFE63-FAA9-447B-9E1F-B173E88A4191@live555.com> Message-ID: <7AE241E2260E40979C7DDF127676CC39@iwns10> Hi Ross, Here is the link of my test.h264 file. http://dl.dropbox.com/u/63577672/test.h264 Please let me know your test results. Regards, Ashfaque From: Ross Finlayson Sent: Tuesday, April 24, 2012 11:35 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] waiting on DESCRIBE response I am using Live555 server application only. Reference is taken from testH264VideoStreamer as reference. OK, thanks for the clarification. Please put your "test.264" on a web server, and send us the URL, so we can download it and test it ourselves. 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 Shaheed at scansoft.co.za Tue Apr 24 04:38:26 2012 From: Shaheed at scansoft.co.za (Shaheed Abdol) Date: Tue, 24 Apr 2012 13:38:26 +0200 Subject: [Live-devel] Streaming from a live source Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8D2E@SSTSVR1.sst.local> Hi Ross, I have read the FAQ, and searched this list for answers. I have found a similar issue and there you advised the user to actually allow the frames to be dropped, and to set the fNumTruncatedBytes variable to the correct value. I am using the DeviceSource class to encapsulate a live source (camera). My downstream object is a MPEG4VideoStreamDiscreteFramer, which has the correct buffer sizes etc. I am using the Event Trigger method to signal that new data has arrived at the camera, but for some reason the stream "dies" after a few seconds (using VLC to connect to RTSP stream). Looking at the logs I have added, it is clear that the frames are not being handled properly. This is a portion of my DeviceSource class (renamed to InputDeviceSource): void InputDeviceSource::deliverFrame0(void * clientData) { reinterpret_cast(clientData)->deliverFrame(); } void InputDeviceSource::deliverFrame() { if (!isCurrentlyAwaitingData()) return; //if not explicitly waiting for data, we short-circuit. //this might not be neccessary fFrameSize = fParams.provider->GetData(fParams.stream, fTo, fMaxSize); //this performs the copy. Copies last chunk of previous frame if truncation would occur. if (fFrameSize <= fMaxSize) { fDurationInMicroseconds = 166666; //6 fps - set only when full frames are delivered gettimeofday(&fPresentationTime, NULL); } else //set to 0 when copying frame portions. fDurationInMicroseconds = 0; LOG((*g_logger), "deliverFrame - frameSize[" << fFrameSize <<"] fMaxSize[" << fMaxSize <<"] fDuration[" << fDurationInMicroseconds <<"]"); //write the log to disk if (fFrameSize > 0) //will be -1 if camera while waiting for data from camera FramedSource::afterGetting(this); //signal that data is available. } /* Called from external thread when data becomes available. */ void InputDeviceSource::SignalDataWaiting(void * clientData) { if (NULL == clientData) return; //sanity check - for some reason this could be null InputDeviceSource * source = reinterpret_cast(clientData); TaskScheduler * ourScheduler = source->m_scheduler; //added this member (set in constructor) if (ourScheduler) //sanity check. ourScheduler->triggerEvent(source->eventTriggerId, source); } //called from external thread when camera signals that data is ready I am doing my best to call signalDataWaiting from the external thread when we detect that only a portion of a frame has been delivered to the DiscreteStreamFramer. Should I call signalDataWaiting for frame portions? Or should I truncate the data and allow the following full frame to be sent? Thank you Regards ___________________________________ Shaheed Abdol Web: www.scansoft.co.za Tel: +27 21 913 8664 Cell: +27 79 835 8771 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32497 bytes Desc: SST Email.png URL: From finlayson at live555.com Tue Apr 24 13:12:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2012 13:12:05 -0700 Subject: [Live-devel] waiting on DESCRIBE response In-Reply-To: <7AE241E2260E40979C7DDF127676CC39@iwns10> References: <3CEA61959BDC4ADCB252BF8B18523024@iwns10><57D1CA94-229E-4AED-806D-3BBF63F2539A@live555.com><7ED64D8837C44D18B484DBFDE514E9DF@iwns10> <574DFE63-FAA9-447B-9E1F-B173E88A4191@live555.com> <7AE241E2260E40979C7DDF127676CC39@iwns10> Message-ID: > Here is the link of my test.h264 file. > http://dl.dropbox.com/u/63577672/test.h264 > > Please let me know your test results. Sorry, but when I downloaded this file (and renamed it as "test.264"), I had no problem streaming it with "testH264VideoStreamer", and playing the stream using "testRTSPClient". In particular: Sending request: DESCRIBE rtsp://192.168.21.2:8554/testStream RTSP/1.0 CSeq: 2 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.04.13) Accept: application/sdp Received 741 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Tue, Apr 24 2012 20:08:00 GMT Content-Base: rtsp://192.168.21.2:8554/testStream/ Content-Type: application/sdp Content-Length: 572 v=0 o=- 1335298038366664 1 IN IP4 192.168.21.2 s=Session streamed by "testH264VideoStreamer" i=test.264 t=0 0 a=tool:LIVE555 Streaming Media v2012.04.13 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.21.2 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:Session streamed by "testH264VideoStreamer" a=x-qt-text-inf:test.264 m=video 18888 RTP/AVP 96 c=IN IP4 232.122.112.88/255 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHqaAtD2Q,aM4wpIA= a=control:track1 Ditto if I stream this file using "testOnDemandRTSPServer". So I don't understand why you're having problems with this file. Are you sure you haven't modified the supplied code? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.liu17 at gmail.com Tue Apr 24 03:35:59 2012 From: daniel.liu17 at gmail.com (=?GB2312?B?wfXB+rfJ?=) Date: Tue, 24 Apr 2012 18:35:59 +0800 Subject: [Live-devel] eventTrigger problem Message-ID: Dear Sir, I got eventTrigger problem on the data input. see below: I have 8 input channels(8 camerals),live source, and I have tested two methods of implementations of DeviceSource for input video, using eventTrigger mechnism. method 1:( I get this method from live555 mailing list, it seems this method is recommended) Using just one eventTriggerId for all DeviceSource instances. And just use the "clientData" param in Function "triggerEvent(EventTriggerId eventTriggerId, void* clientData) " to discriminate the DeviceSource instances which represent each input channel. It works, but with low efficiency. It seems that the input data is not fetched as quickly as possible, and it results large data loss at the input side. method 2: Using 8 "eventTriggerId"s, and one for each channel. So in function triggerEvent(*, *), it has two params to discriminate the DeviceSource instances. And this works better than method 1, the input data loss is small. My question is: 1.why method 1 cause such large input data loss? 2. If I use method 2, are there any shortcomings? Thank you, any advises is appreciated. --Daniel Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From csavtche at gmail.com Tue Apr 24 10:21:53 2012 From: csavtche at gmail.com (Constantin Savtchenko) Date: Tue, 24 Apr 2012 13:21:53 -0400 Subject: [Live-devel] Compiling On Windows, Why Not msvcprt.lib? Message-ID: Hello all, A quick google research on the mailing list archives revealed no prior answers on this. In the installation instructions, it is recommended to copy over the old msvcirt.lib and add it to the Include path. I successfully compiled by simply modifying the testProgs.mak to link with the newer, supported msvcprt.lib instead. Is there a reason that this approach is not suggested? In other words, am I going to run into problems by using Live555 libraries with the newer Microsoft Library? Thank you in advance. Constantin S -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 24 14:05:30 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2012 14:05:30 -0700 Subject: [Live-devel] eventTrigger problem In-Reply-To: References: Message-ID: > I got eventTrigger problem on the data input. see below: > I have 8 input channels(8 camerals),live source, and I have tested two methods of implementations of DeviceSource for input video, using eventTrigger mechnism. As a general rule, if the 'event handler function' is the same for multiple events, then you should create just one event trigger id for this handler function, and use the "clientData" parameter to distinguish the different events when you later 'trigger' it. (Ie., your "method 1".) > My question is: 1.why method 1 cause such large input data loss? I don't understand why it would. Perhaps your own event handling function (i.e., the handler function that you registered using "createEventTrigger()") is somehow to blame? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwright3 at slb.com Wed Apr 25 04:04:14 2012 From: mwright3 at slb.com (Martin Wright) Date: Wed, 25 Apr 2012 11:04:14 +0000 Subject: [Live-devel] DeviceSource.cpp socket implementation In-Reply-To: References: Message-ID: Hi I'm wondering if anybody has a simple socket reading version of the testOnDemandRTSPServer program. I need to source raw PCM audio from a socket knowing the sample size, frequency and number of channels and send frames to the RTP sink. It would be really useful to see a concrete example of how DeviceSource needs to be modified to achieve this. Thanks (I realise this is a big ask) Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Wed Apr 25 07:01:28 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Wed, 25 Apr 2012 16:01:28 +0200 Subject: [Live-devel] Android log patch Message-ID: <4F981FD80200004D0006A55C@pta-emo.csir.co.za> Hi Ross, Please take a look if you would consider the attached patch. It allows live555 to log to the logcat window (instead of std out/std err) when compiled for android (i.e. ANDROID is defined). The other option would be to write an AndroidUsageEnvironment class, but since there are in any case changes (#ifdefs) for ANDROID in the latest live555 codebase, this approach might be better as client code does not have to be changed and automatically has logging to the logcat window. We found this to be especially helpful when debugging the android version of VLC. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: android_log.patch Type: application/octet-stream Size: 1780 bytes Desc: not available URL: From finlayson at live555.com Wed Apr 25 07:44:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Apr 2012 07:44:45 -0700 Subject: [Live-devel] DeviceSource.cpp socket implementation In-Reply-To: References: Message-ID: <96345891-60FC-4035-B5C9-F4DC4F8AC5AE@live555.com> > I?m wondering if anybody has a simple socket reading version of the testOnDemandRTSPServer program. What you really mean to ask for is "a subclass of the 'OnDemandServerMediaSubsession' class that reads from a socket". There is such a class that you can use as a model: "MPEG2TransportUDPServerMediaSubsession". Note also how this is used in "testOnDemandRTSPServer". If, however, you are asking about reading from a *stream* (i.e., TCP) socket, rather than from a datagram socket, then you should be able to convert the socket into a "FILE*" (assuming that you're not using Windoze), and instead use "WAVAudioFileServerMediaSubsession" as a model for your new "OnDemandServerMediaSubsession" subclass. (Either way, you will need to write your own "OnDemandServerMediaSubsession" subclass.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 25 07:58:11 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Apr 2012 07:58:11 -0700 Subject: [Live-devel] Android log patch In-Reply-To: <4F981FD80200004D0006A55C@pta-emo.csir.co.za> References: <4F981FD80200004D0006A55C@pta-emo.csir.co.za> Message-ID: <1AA51BF5-B4A3-42F7-B3DF-1CF41383ED3A@live555.com> > Please take a look if you would consider the attached patch. > It allows live555 to log to the logcat window (instead of std out/std err) > when compiled for android (i.e. ANDROID is defined). Sorry, no, because this is too specific to one particular environment. What you should be doing instead is defining your own subclass of "BasicUsageEnvironment" and reimplementing the various "operator<<" virtual functions in your subclass, and then using this subclass in your application, instead of "BasicUsageEnvironment". This is exactly how the "UsageEnvironment" virtual base class was intended to be used. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnx.mcnamara at intel.com Wed Apr 25 05:52:25 2012 From: johnx.mcnamara at intel.com (Mcnamara, JohnX) Date: Wed, 25 Apr 2012 12:52:25 +0000 Subject: [Live-devel] Possible bug in H264VideoStreamParser Message-ID: Hi, The H264VideoStreamParser::Parse() method appears to insert additional 0x00000001 start codes when the buffered data is greater than the BANK_SIZE and the fBank[] banks are switched. Steps to reproduce: 1. Convert a H.264 video such as the Live555 sample slamtv10.264 file to MPEG-TS using testProgs/testH264VideoToTransportStream. 2. Demux the H.264 data from the MPEG-TS file. (I used a modified version of testProgs/MPEG2TransportStreamIndexer). 3. Compare the demuxed H.264 data with the input H.264 file. In the output file at every BANK_SIZE (approx) offset there is an addition 0x00000001 start code compared to the source data. This doesn't (generally occur) at the start of a NAL unit. The first difference occurs after the byte sequence 0x94caf7ce in the TS or H.264 files (using slamtv10.264 as an input). It is followed by an extra 0x00000001: ... 94ca f7ce 0000 0001 83f3 539b ... The demuxed H.264 data causes the JM H.264 reference decoder to complain: http://iphome.hhi.de/suehring/tml/ Error: Found NALU with forbidden_bit set, bit error? It is probably caused by StreamParser::ensureValidBytes1() throwing an (intended) exception after the BANK_SIZE buffer is full which causes a re-entry to H264VideoStreamParser::parse() which in turn does save4Bytes(0x00000001) when fOutputStartCodeSize is non-zero. However, it may not be valid to add the start code in this case. This was tested with Live555 version "2012.04.18". Do you think this is an issue or is it valid output? Regards, John. -- -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chsu at cs.nthu.edu.tw Wed Apr 25 06:54:33 2012 From: chsu at cs.nthu.edu.tw (Cheng-Hsin Hsu) Date: Wed, 25 Apr 2012 21:54:33 +0800 Subject: [Live-devel] missed RTP packets when streaming directly from libx264 Message-ID: <41D1CC22-AA3C-40F3-8EBB-FBC18B14CBF8@cs.nthu.edu.tw> Greetings, I'm try to stream live video using X264 and live555. Currently, what I do is: (i) whenever doGetNextFrame() is called, I read a frame from a local YUV file, and encode it into one or multiple NAL units, and (ii) whenever deliverFrame() is called I copy all the NALs to the buffer and set fPresentationTime and fDurationInMicroseconds as follows: gettimeofday(&fPresentationTime, NULL); // If you have a more accurate time - e.g., from an encoder - then use that instead. fDurationInMicroseconds = 33333.33; But when playing the RTP/RTSP stream using ffplay, I got this: [h264 @ 0x7f95e400f600] RTP: missed 1 packets64KB sq= 0B f=0/0 Last message repeated 2 times 0KB vq= 64KB sq= 0B f=0/0 [h264 @ 0x7f95e4011400] concealing 396 DC, 396 AC, 396 MV errors [h264 @ 0x7f95e411a200] concealing 396 DC, 396 AC, 396 MV errors0 [h264 @ 0x7f95e400f600] RTP: missed 18 packets0KB sq= 0B f=0/0 [h264 @ 0x7f95e400f600] RTP: missed 4 packets62KB sq= 0B f=0/0 [h264 @ 0x7f95e400f600] RTP: missed 22 packets [h264 @ 0x7f95e4010e00] concealing 396 DC, 396 AC, 396 MV errors0 [h264 @ 0x7f95e400f600] RTP: missed 1 packets [h264 @ 0x7f95e4010800] concealing 1188 DC, 1188 AC, 1188 MV errors [h264 @ 0x7f95e4010e00] concealing 1426 DC, 1426 AC, 1426 MV errors [h264 @ 0x7f95e4011400] concealing 396 DC, 396 AC, 396 MV errors0 [h264 @ 0x7f95e400f600] RTP: missed 1 packets [h264 @ 0x7f95e400f600] RTP: missed 4 packets63KB sq= 0B f=0/0 [h264 @ 0x7f95e400f600] RTP: missed 7 packets [h264 @ 0x7f95e400f600] RTP: missed 2 packets64KB sq= 0B f=0/0 Last message repeated 1 times 0KB vq= 59KB sq= 0B f=0/0 [h264 @ 0x7f95e411a200] concealing 396 DC, 396 AC, 396 MV errors [h264 @ 0x7f95e4010200] corrupted macroblock 5 22 (total_coeff=-1) [h264 @ 0x7f95e4010200] error while decoding MB 5 22 [h264 @ 0x7f95e4010200] concealing 660 DC, 660 AC, 660 MV errors [h264 @ 0x7f95e4010800] concealing 657 DC, 657 AC, 657 MV errors0 [h264 @ 0x7f95e4010e00] concealing 656 DC, 656 AC, 656 MV errors0 I'm not sure why I got missed RTP packets as both server and client run on the same laptop. Where should I look into? Any clues are highly appreciated. Best regards, Chenghsin From finlayson at live555.com Wed Apr 25 08:43:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Apr 2012 08:43:39 -0700 Subject: [Live-devel] missed RTP packets when streaming directly from libx264 In-Reply-To: <41D1CC22-AA3C-40F3-8EBB-FBC18B14CBF8@cs.nthu.edu.tw> References: <41D1CC22-AA3C-40F3-8EBB-FBC18B14CBF8@cs.nthu.edu.tw> Message-ID: > I'm try to stream live video using X264 and live555. Currently, what I do is: (i) whenever doGetNextFrame() is called, I read a frame from a local YUV file, and encode it into one or multiple NAL units, and (ii) whenever deliverFrame() is called I copy all the NALs to the buffer This is a mistake. You should instead be copying ***one NAL unit at a time*** to your downstream object (which should be a "H264VideoStreamDiscreteFramer"). > fDurationInMicroseconds = 33333.33; BTW, "fDurationInMicroseconds" is an unsigned integer, not a float. > But when playing the RTP/RTSP stream using ffplay I suggest that you first test your stream using "testRTSPClient" (and "openRTSP"), before using a 3rd-party RTSP client. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 25 19:31:27 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Apr 2012 19:31:27 -0700 Subject: [Live-devel] Possible bug in H264VideoStreamParser In-Reply-To: References: Message-ID: Although I can't rule out the possibility of a bug in "H264VideoStreamParser", I think that your problem is that the buffer used by the "FileSink" object in the "testH264VideoToTransportStream" demo application was too small for at least some of the NAL units in your input file. Unfortunately, our code did not warn you about this. I have now installed a new version (2012.04.26) of the "LIVE555 Streaming Media" code that: - Increases the buffer size used by the "FileSink" object in the "testH264VideoToTransportStream" demo application, and - Warns you (with a console error message) when the buffer used by any of the "*Sink" classes is too small. I suspect that this new version should solve your problem. (If not, let us know.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trn200190 at gmail.com Wed Apr 25 04:47:47 2012 From: trn200190 at gmail.com (i m what i m ~~~~) Date: Wed, 25 Apr 2012 17:17:47 +0530 Subject: [Live-devel] not understandable error Message-ID: Hi i am getting this error when i am running my project made from live media library.... WHAT DOES THIS ERROR MEAN????? testH264VideoStreamer.obj : error LNK2019: unresolved external symbol "public: static class DeviceSourceFICard * __cdecl DeviceSourceFICard::createNew(class UsageEnvironment &,class FICardDeviceParameters,class DeviceParameters)" (?createNew at DeviceSourceFICard@@SAPAV1 at AAVUsageEnvironment @@VFICardDeviceParameters@@VDeviceParameters@@@Z) referenced in function "void __cdecl play(void)" (?play@@YAXXZ) Thank You -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshf87 at live.com Wed Apr 25 19:01:03 2012 From: joshf87 at live.com (Josh) Date: Wed, 25 Apr 2012 22:01:03 -0400 Subject: [Live-devel] MPEG4GenericRTPSink.cpp:44:65: error: 'tolower' was not declared in this scope Message-ID: g++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. -O -DSOCKLEN_T=int -DLOCAL E_NOT_USED -DRTSPCLIENT_SYNCHRONOUS_INTERFACE=1 -D__MINGW32__ -Wall -Wno-deprecated MPEG4GenericRTPS ink.cpp In file included from MPEG4GenericRTPSink.cpp:22:0: include/Locale.hh:52:44: warning: 'typedef' was ignored in this declaration [enabled by default] MPEG4GenericRTPSink.cpp: In constructor 'MPEG4GenericRTPSink::MPEG4GenericRTPSink(UsageEnvironment&, Groupsock*, u_int8_t, u_int32_t, const char*, const char*, const char*, unsigned int)': MPEG4GenericRTPSink.cpp:44:65: error: 'tolower' was not declared in this scope make[1]: *** [MPEG4GenericRTPSink.o] Error 1 make[1]: Leaving directory `/home/Joshua/mplayer/live/liveMedia' make: *** [all] Error 2 I'm getting this error attempting to compile under MinGW/GCC 4.6.2 (from mingw.org). I'm compiling it for MPlayer. From gordu at dvr2010.com Thu Apr 26 06:37:56 2012 From: gordu at dvr2010.com (Gord Umphrey) Date: Thu, 26 Apr 2012 09:37:56 -0400 Subject: [Live-devel] Visual Studio 2008 Message-ID: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> We are still getting heap corruption with the libraries that we have built with VS 2008. Is there anywhere that we can download the .lib?s directly so that we can narrow down where the problem is? Are there any tricks to building with VS 2008? The FAQ suggestions do not help. Thanks, Gord. -------------- next part -------------- An HTML attachment was scrubbed... URL: From csavtche at gmail.com Thu Apr 26 06:48:10 2012 From: csavtche at gmail.com (Constantin Savtchenko) Date: Thu, 26 Apr 2012 09:48:10 -0400 Subject: [Live-devel] Visual Studio 2008 In-Reply-To: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> Message-ID: Did you compile with msvcirt or msvcprt? Constantin On Apr 26, 2012 9:46 AM, "Gord Umphrey" wrote: > We are still getting heap corruption with the libraries that we have > built with VS 2008. > > Is there anywhere that we can download the .lib?s directly so that we can > narrow down where the problem is? > > Are there any tricks to building with VS 2008? The FAQ suggestions do not > help. > > Thanks, > Gord. > > _______________________________________________ > 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 sunkwei at gmail.com Thu Apr 26 07:23:25 2012 From: sunkwei at gmail.com (=?GB2312?B?y+8g5+I=?=) Date: Thu, 26 Apr 2012 22:23:25 +0800 Subject: [Live-devel] Visual Studio 2008 In-Reply-To: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> Message-ID: <9A953F73-EB40-4A9E-8270-A93ABAB549C8@gmail.com> ? 2012-4-26???9:37? Gord Umphrey ??? > We are still getting heap corruption with the libraries that we have built with VS 2008. > > Is there anywhere that we can download the .lib?s directly so that we can narrow down where the problem is? > > Are there any tricks to building with VS 2008? The FAQ suggestions do not help. > > Thanks, > Gord. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel the simplest steps: 1. in vs2008, create a static lib project; 2. for the project, add all source files, include UsageEnvironment/*.cpp, BasicUsageEnvironment/*.cpp, group sock/*.cpp and liveMedia/*.cpp 3. cp all headers into a folder, and add the folder into vs project include search path? 4. build ? 5. ?.. SunKW -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marlon at scansoft.co.za Thu Apr 26 07:27:37 2012 From: Marlon at scansoft.co.za (Marlon Reid) Date: Thu, 26 Apr 2012 16:27:37 +0200 Subject: [Live-devel] Visual Studio 2008 In-Reply-To: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8D39@SSTSVR1.sst.local> Hi, Try these build files for VS2008. It works just fine for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testRelay.vcproj Type: application/octet-stream Size: 5235 bytes Desc: testRelay.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testWAVAudioStreamer.vcproj Type: application/octet-stream Size: 5257 bytes Desc: testWAVAudioStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vobStreamer.vcproj Type: application/octet-stream Size: 5239 bytes Desc: vobStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WindowsAudioInputDevice_Mixer.vcproj Type: application/octet-stream Size: 6001 bytes Desc: WindowsAudioInputDevice_Mixer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WindowsAudioInputDevice_noMixer.vcproj Type: application/octet-stream Size: 6007 bytes Desc: WindowsAudioInputDevice_noMixer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live.vcproj Type: application/octet-stream Size: 59082 bytes Desc: live.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mediaServer.vcproj Type: application/octet-stream Size: 5534 bytes Desc: mediaServer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamIndexer.vcproj Type: application/octet-stream Size: 5271 bytes Desc: MPEG2TransportStreamIndexer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openRTSP.vcproj Type: application/octet-stream Size: 5459 bytes Desc: openRTSP.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: playSIP.vcproj Type: application/octet-stream Size: 5376 bytes Desc: playSIP.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sapWatch.vcproj Type: application/octet-stream Size: 5233 bytes Desc: sapWatch.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testAMRAudioStreamer.vcproj Type: application/octet-stream Size: 5257 bytes Desc: testAMRAudioStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testDVVideoStreamer.vcproj Type: application/octet-stream Size: 5251 bytes Desc: testDVVideoStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testGSMStreamer.vcproj Type: application/octet-stream Size: 5247 bytes Desc: testGSMStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMP3Receiver.vcproj Type: application/octet-stream Size: 5426 bytes Desc: testMP3Receiver.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMP3Streamer.vcproj Type: application/octet-stream Size: 5247 bytes Desc: testMP3Streamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG1or2AudioVideoStreamer.vcproj Type: application/octet-stream Size: 5277 bytes Desc: testMPEG1or2AudioVideoStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG1or2AudioVideoToDarwin.vcproj Type: application/octet-stream Size: 5277 bytes Desc: testMPEG1or2AudioVideoToDarwin.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG1or2ProgramToTransportStream.vcproj Type: application/octet-stream Size: 5289 bytes Desc: testMPEG1or2ProgramToTransportStream.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG1or2Splitter.vcproj Type: application/octet-stream Size: 5257 bytes Desc: testMPEG1or2Splitter.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG1or2VideoReceiver.vcproj Type: application/octet-stream Size: 5219 bytes Desc: testMPEG1or2VideoReceiver.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG1or2VideoStreamer.vcproj Type: application/octet-stream Size: 5567 bytes Desc: testMPEG1or2VideoStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG2TransportStreamer.vcproj Type: application/octet-stream Size: 5271 bytes Desc: testMPEG2TransportStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG2TransportStreamTrickPlay.vcproj Type: application/octet-stream Size: 5283 bytes Desc: testMPEG2TransportStreamTrickPlay.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG4VideoStreamer.vcproj Type: application/octet-stream Size: 5261 bytes Desc: testMPEG4VideoStreamer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testMPEG4VideoToDarwin.vcproj Type: application/octet-stream Size: 5261 bytes Desc: testMPEG4VideoToDarwin.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testOnDemandMirandaRTSPServer.vcproj Type: application/octet-stream Size: 5231 bytes Desc: testOnDemandMirandaRTSPServer.vcproj URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testOnDemandRTSPServer.vcproj Type: application/octet-stream Size: 5213 bytes Desc: testOnDemandRTSPServer.vcproj URL: From Guy.Bonneau at miranda.com Thu Apr 26 16:23:39 2012 From: Guy.Bonneau at miranda.com (BONNEAU Guy) Date: Thu, 26 Apr 2012 23:23:39 +0000 Subject: [Live-devel] Visual Studio 2008 In-Reply-To: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> Message-ID: <24665DDC0D7CF047BD6471A56E615EA69E32AFB8@CA-OPS-MAILBOX.miranda.com> Gord included is a zip file of a folder named visual2008.zip. Unzip the folder in root directory of the live folder. Then open the solution file live.sln in the folder visual2008. Make sure the live folder contain the entire original unmodified live555 library. The solution contains almost all the test application of live555 including testRTSPClient application. It should compile fine all the testing applications except for one (this is normal) and you shouldn?t have any issue to run them under windows. I took a fast look at your issue and I believe I might have found the cause of the corruption. Put a breakpoint at line 1263 of file RTSPClient.cpp. This line should be: client->connectionHandler1(); Set testRTSPClient as the starting application of the solution and setup the argument in the debug property dialog. The run and wait for the timeout to occur. You will break at line 1263 of file RTSPClient. Then trace and debug the code single stepping until you reach line 399 of testRTSPClient.cpp . At this point this is the call stack you should have: RTSPClient::connectionHandler (void* instance, int /*mask*/) client->connectionHandler1() RTSPClient::connectionHandler1() handleRequestError(request) RTSPClient::handleRequestError(RequestRecord* request) if (request->handler() != NULL) (*request->handler())(this, resultCode, strDup(envir().getResultMsg())); continueAfterDESCRIBE(RTSPClient* rtspClient, int resultCode, char* resultString) shutdownStream(rtspClient); void shutdownStream(RTSPClient* rtspClient, int exitCode) Medium::close(rtspClient); //(Breakpoint) I might be wrong but this is what I believe might be the issue. The rtspClient object is deleted by Medium::close(rtspClient) in the context of the object still being used. I did not go further in the investigation. But this should be a good starting point because anything is possible after the deleting of the rtspClient including heap corruption. Hope this help! Guy Bonneau From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Gord Umphrey Sent: Thursday, April 26, 2012 9:38 To: live-devel at ns.live555.com Subject: [Live-devel] Visual Studio 2008 We are still getting heap corruption with the libraries that we have built with VS 2008. Is there anywhere that we can download the .lib?s directly so that we can narrow down where the problem is? Are there any tricks to building with VS 2008? The FAQ suggestions do not help. Thanks, Gord. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Visual2008.zip Type: application/x-zip-compressed Size: 42719 bytes Desc: Visual2008.zip URL: From nixchun at gmail.com Thu Apr 26 19:17:20 2012 From: nixchun at gmail.com (Nix Lo) Date: Fri, 27 Apr 2012 10:17:20 +0800 Subject: [Live-devel] Typo error in ive/mediaServer/Makefile.tail In-Reply-To: References: Message-ID: Hi, I think there might be a typo error in file live/mediaServer/Makefile.tail, "live555MediaServer*,*$(CPP)" should be changed to "live555MediaServer*.*$(CPP)", thank you very much. Best Regards, nix -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Apr 26 19:54:20 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 26 Apr 2012 20:54:20 -0600 Subject: [Live-devel] not understandable error In-Reply-To: References: Message-ID: <4F9A0A5C.4080708@etr-usa.com> On 4/25/2012 5:47 AM, i m what i m ~~~~ wrote: > > i am getting this error when i am running my project made from live > media library.... > WHAT DOES THIS ERROR MEAN????? http://lmgtfy.com/?q=LNK2019 From finlayson at live555.com Thu Apr 26 20:09:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Apr 2012 20:09:46 -0700 Subject: [Live-devel] Typo error in ive/mediaServer/Makefile.tail In-Reply-To: References: Message-ID: <4B8AD2A0-30EE-40A8-987D-A552D2978563@live555.com> > I think there might be a typo error in file live/mediaServer/Makefile.tail, "live555MediaServer,$(CPP)" should be changed to "live555MediaServer.$(CPP)", thank you very much. Yes, you're right. Thanks for the report. 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 Thu Apr 26 21:03:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Apr 2012 21:03:46 -0700 Subject: [Live-devel] testRTSPClient heap corruption In-Reply-To: <24665DDC0D7CF047BD6471A56E615EA69E32AFB8@CA-OPS-MAILBOX.miranda.com> References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> <24665DDC0D7CF047BD6471A56E615EA69E32AFB8@CA-OPS-MAILBOX.miranda.com> Message-ID: Guy Bonneau wrote: > I took a fast look at your issue and I believe I might have found the cause of the corruption. Put a breakpoint at line 1263 of file RTSPClient.cpp. This line should be: > > client->connectionHandler1(); > > Set testRTSPClient as the starting application of the solution and setup the argument in the debug property dialog. The run and wait for the timeout to occur. You will break at line 1263 of file RTSPClient. Then trace and debug the code single stepping until you reach line 399 of testRTSPClient.cpp . At this point this is the call stack you should have: > > RTSPClient::connectionHandler (void* instance, int /*mask*/) > client->connectionHandler1() > > RTSPClient::connectionHandler1() > handleRequestError(request) > > RTSPClient::handleRequestError(RequestRecord* request) > if (request->handler() != NULL) (*request->handler())(this, resultCode, strDup(envir().getResultMsg())); > > continueAfterDESCRIBE(RTSPClient* rtspClient, int resultCode, char* resultString) > shutdownStream(rtspClient); > > void shutdownStream(RTSPClient* rtspClient, int exitCode) > Medium::close(rtspClient); //(Breakpoint) > > > I might be wrong but this is what I believe might be the issue. The rtspClient object is deleted by Medium::close(rtspClient) in the context of the object still being used. Yes, Guy has definitely found a potential problem. The "RTSPClient" code needs to be more careful about not accessing "RTSPClient" object state after calling "handleRequestError()", because of the likelihood (which in fact happens in "testRTSPClient") of the "RTSPClient" object being deleted when the error is handled. This will be fixed in the next release of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Apr 26 21:58:16 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 26 Apr 2012 22:58:16 -0600 Subject: [Live-devel] testRTSPClient heap corruption In-Reply-To: References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> <24665DDC0D7CF047BD6471A56E615EA69E32AFB8@CA-OPS-MAILBOX.miranda.com> Message-ID: <4F9A2768.90600@etr-usa.com> On 4/26/2012 10:03 PM, Ross Finlayson wrote: > The "RTSPClient" code > needs to be more careful about not accessing "RTSPClient" object state > after calling "handleRequestError()", because of the likelihood (which > in fact happens in "testRTSPClient") of the "RTSPClient" object being > deleted when the error is handled. It might be worth Valgrinding all of the sample programs. Valgrind runs best[*] on Linux, but a bug it finds on Linux is probably a bug on OS X and BSD, too. [*] http://valgrind.org/info/platforms.html From ashu.bhatt at tcs.com Fri Apr 27 01:19:30 2012 From: ashu.bhatt at tcs.com (Ashutosh Bhatt) Date: Fri, 27 Apr 2012 08:19:30 +0000 Subject: [Live-devel] FW: Reg. configure and running issue for livemedia 555 In-Reply-To: <4F9B0D52BDDD4845A9C90B65CA81FF3136250F32@INMUMEXM03.TCS.com> References: <4F9B0D52BDDD4845A9C90B65CA81FF3136250F32@INMUMEXM03.TCS.com> Message-ID: <4F9B0D52BDDD4845A9C90B65CA81FF3136254F5F@INMUMEXM03.TCS.com> Hello Team, I am installing and configuring the live555 media server to showcasing the demo requirement to the client related to sip applications , Actually I am working in an application in which I need to stream a live video through IP camera . I used your source code to stream through Live555media server supporting RTSP I want steps to run a basic video call where i can get a streamed video file as output from a running live streaming video. I went through the documentation on site.However i was not able to execute the basic video call.Would appreciate your quick help in this.Request you to provide steps to execute such call. I am using Linux platform Rgds, ASHUTOSH BHATT Tata Consultancy Services ________________________________ From: Ashutosh Bhatt Sent: Friday, April 27, 2012 12:10 PM To: support at live555.com Subject: Reg. configure and running issue for livemedia 555 Hello Team, I am installing and configuring the live555 media server to showcasing the demo requirement to the client related to sip applications , Actually I am working in an application in which I need to stream a live video through IP camera . I used your source code to stream through Live555media server supporting RTSP I want steps to run a basic video call where i can get a streamed video file as output from a running live streaming video. I went through the documentation on site.However i was not able to execute the basic video call.Would appreciate your quick help in this.Request you to provide steps to execute such call. I am using Linux platform ASHUTOSH BHATT Tata Consultancy Services =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 27 01:50:37 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2012 01:50:37 -0700 Subject: [Live-devel] FW: Reg. configure and running issue for livemedia 555 In-Reply-To: <4F9B0D52BDDD4845A9C90B65CA81FF3136254F5F@INMUMEXM03.TCS.com> References: <4F9B0D52BDDD4845A9C90B65CA81FF3136250F32@INMUMEXM03.TCS.com> <4F9B0D52BDDD4845A9C90B65CA81FF3136254F5F@INMUMEXM03.TCS.com> Message-ID: <34510CFE-4CC9-4368-8644-F514EFF28A12@live555.com> > I am installing and configuring the live555 media server to showcasing the demo requirement to the client related to sip applications You understand, I hope, that the "LIVE555 Media Server" uses the RTSP protocol, not SIP. > I want steps to run a basic video call where i can get a streamed video file as output from a running live streaming video. I suggest that you begin by reviewing the "openRTSP" demo application (which records incoming data from a "rtsp://" stream to a file), and the "testRTSPClient" demo application (which illustrates how you could develop your own RTSP client application). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordu at dvr2010.com Fri Apr 27 06:14:18 2012 From: gordu at dvr2010.com (Gord Umphrey) Date: Fri, 27 Apr 2012 09:14:18 -0400 Subject: [Live-devel] testRTSPClient does not assemble frames correctly In-Reply-To: References: Message-ID: <2144B74FAE58486CB625B400639BB794@SmokeyPC> Thank you Guy for the good work with "testRTSPClient heap corruption". When testRTSPClient successfully receives a stream, we are finding that the received frames are not assembled correctly. For most (if not all to my knowledge) streams, you should have an I frame, followed by a fixed amount of P frames, followed by an I frame, etc, etc. I.e. you should see this: I frame 32 P frames I frame 32 P frames etc, etc However, we are finding a variable number of P frames. Sometimes you will get an I frame every 10th frame, sometimes every 16th frame, etc. I think what's happening is that sometimes multiple P frames are being combined into a single P frame. This variable GOP size is a problem for a lot of decoders. So far we have tested this on 3 different RTSP sources with the same result. Any ideas? Thanks, Gord. From Guy.Bonneau at miranda.com Fri Apr 27 07:39:34 2012 From: Guy.Bonneau at miranda.com (BONNEAU Guy) Date: Fri, 27 Apr 2012 14:39:34 +0000 Subject: [Live-devel] testRTSPClient does not assemble frames correctly In-Reply-To: <2144B74FAE58486CB625B400639BB794@SmokeyPC> References: <2144B74FAE58486CB625B400639BB794@SmokeyPC> Message-ID: <24665DDC0D7CF047BD6471A56E615EA69E32B17B@CA-OPS-MAILBOX.miranda.com> Gord, We haven't used the live555 library to parse the mpeg2 capture. We use our own parser implementation. Thus I am afraid that I cannot help much regarding if the live555 could have any issue parsing the incoming Mpeg2 data. Here is some suggestion to help you with debugging your issue. 1- Make sure your network setup doesn't "lose" any IP packets. 2- Use an Mpeg2 stream analyzer to check the conformance of the capture stream and identify what is wrong. I use Elecard. 3- Use VLC to capture the IP stream simultaneously with your own application that uses live555. If VLC capture is fine then it might be an issue with either your application or the live555 library. If the capture is not fine with VLC then the issue is with the encoder (unless packets were lost). 5- To my knowledge a variable GOP size should not be an issue for an Mpeg2 decoder. If it is an issue for the decoder you use then you should switch to another decoder because the one you use is not conformant to the ISO spec. Hope this help Guy |-----Original Message----- |From: live-devel-bounces at ns.live555.com [mailto:live-devel- |bounces at ns.live555.com] On Behalf Of Gord Umphrey |Sent: Friday, April 27, 2012 9:14 |To: live-devel at ns.live555.com |Subject: [Live-devel] testRTSPClient does not assemble frames correctly | |Thank you Guy for the good work with "testRTSPClient heap corruption". | |When testRTSPClient successfully receives a stream, we are finding that the |received frames are not assembled correctly. | |For most (if not all to my knowledge) streams, you should have an I frame, |followed by a fixed amount of P frames, followed by an I frame, etc, etc. | |I.e. you should see this: | |I frame |32 P frames |I frame |32 P frames |etc, etc | | |However, we are finding a variable number of P frames. Sometimes you will |get an I frame every 10th frame, sometimes every 16th frame, etc. |I think what's happening is that sometimes multiple P frames are being |combined into a single P frame. | |This variable GOP size is a problem for a lot of decoders. | | |So far we have tested this on 3 different RTSP sources with the same result. | | |Any ideas? | |Thanks, |Gord. | | |_______________________________________________ |live-devel mailing list |live-devel at lists.live555.com |http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Fri Apr 27 08:29:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2012 08:29:33 -0700 Subject: [Live-devel] testRTSPClient does not assemble frames correctly In-Reply-To: <2144B74FAE58486CB625B400639BB794@SmokeyPC> References: <2144B74FAE58486CB625B400639BB794@SmokeyPC> Message-ID: > However, we are finding a variable number of P frames. Sometimes you will get an I frame every 10th frame, sometimes every 16th frame, etc. > I think what's happening is that sometimes multiple P frames are being combined into a single P frame. > > This variable GOP size is a problem for a lot of decoders. > > > So far we have tested this on 3 different RTSP sources with the same result. What type of data is this? MPEG-2 Elementary Stream video? H.264 Elementary Stream video? MPEG Transport Stream (containing MPEG-2 or H.264 video)? Do the "3 different RTSP sources" come from servers implemented using our code (e.g., using one of our server demo applications), or using some other RTSP server implementation? Are you seeing network packet loss (you can test this by running "openRTSP -Q" on the stream)? If you are seeing significant packet loss, then be sure to read http://www.live555.com/liveMedia/faq.html#packet-loss It's unlikely that our RTP receiving code is 'combining multiple P frames into a single P frame' if the source data is formatted properly according to the appropriate RTP payload format. But if network packet loss is occurring, then the received stream will (of course!) have missing frames (including probably some missing I-frames, because they are larger and thus more susceptible to packet loss (unless they have been built as multiple 'slices')). These lost frames will (of course!) cause video artifacts when the the video is decoded and rendered. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bstump at codemass.com Fri Apr 27 09:19:08 2012 From: bstump at codemass.com (Barry Stump) Date: Fri, 27 Apr 2012 09:19:08 -0700 Subject: [Live-devel] Problem with LocaleCategory typedef Message-ID: I'm getting compiler typedef warnings for liveMedia/include/Locale.hh, line 52 (Live555 version 2012.04.21) which looks like this: typedef enum LocaleCategory { All, Numeric }; Shouldn't the LocaleCategory type name come at the end, like this? typedef enum { All, Numeric } LocaleCategory; -Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Apr 27 09:36:16 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 27 Apr 2012 10:36:16 -0600 Subject: [Live-devel] Problem with LocaleCategory typedef In-Reply-To: References: Message-ID: <4F9ACB00.1020202@etr-usa.com> On 4/27/2012 10:19 AM, Barry Stump wrote: > I'm getting compiler typedef warnings for liveMedia/include/Locale.hh, > line 52 (Live555 version 2012.04.21) which looks like this: > > typedef enum LocaleCategory { All, Numeric }; > > Shouldn't the LocaleCategory type name come at the end, like this? > > typedef enum { All, Numeric } LocaleCategory; I don't see why it needs a typedef at all. An enum is a type, in the loose way C and C++ use that term. From finlayson at live555.com Fri Apr 27 13:14:36 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2012 13:14:36 -0700 Subject: [Live-devel] testRTSPClient heap corruption In-Reply-To: <24665DDC0D7CF047BD6471A56E615EA69E32AFB8@CA-OPS-MAILBOX.miranda.com> References: <6B707AE0B3434F9789F0F9291AF8625F@SmokeyPC> <24665DDC0D7CF047BD6471A56E615EA69E32AFB8@CA-OPS-MAILBOX.miranda.com> Message-ID: <69629BA4-26D2-4F3C-87F0-5931B459684B@live555.com> FYI, I've now installed a new version (2012.04.27) of the "LIVE555 Streaming Media" code that should fix the issue that Guy Bonneau noted. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 27 13:17:57 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2012 13:17:57 -0700 Subject: [Live-devel] Problem with LocaleCategory typedef In-Reply-To: <4F9ACB00.1020202@etr-usa.com> References: <4F9ACB00.1020202@etr-usa.com> Message-ID: <3E9F2586-97AD-41A2-9BA7-FE12314963B1@live555.com> OK, the "typedef" has been removed in the latest version of the code (just installed). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bstump at codemass.com Fri Apr 27 13:41:39 2012 From: bstump at codemass.com (Barry Stump) Date: Fri, 27 Apr 2012 13:41:39 -0700 Subject: [Live-devel] Problem with LocaleCategory typedef In-Reply-To: <3E9F2586-97AD-41A2-9BA7-FE12314963B1@live555.com> References: <4F9ACB00.1020202@etr-usa.com> <3E9F2586-97AD-41A2-9BA7-FE12314963B1@live555.com> Message-ID: > OK, the "typedef" has been removed in the latest version of the code (just > installed). > > Thanks Ross. I'm finally seeing zero warnings when compiling Live555. -Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Sat Apr 28 01:09:26 2012 From: zanglan at yahoo.com (Lan Zang) Date: Sat, 28 Apr 2012 16:09:26 +0800 (CST) Subject: [Live-devel] The question on how to handle the incoming H.264 RTP data of live555 server Message-ID: <1335600566.42903.YahooMailNeo@web15803.mail.cnb.yahoo.com> Hi, all I am new to this live555 media server. I am trying to make a server running on ubuntu that can perform the following task: It gets h.264 video data over RTP from others (e.g. ffmpeg), then it will broadcast the video to other viewers( e.g. vlc player) via rtsp protocol. After reading the codes of live555MediaServer.cpp and testOnDemandRTSPServer.cpp and some other files plus a little guessing, I think I shall prepare a class that will treat h.264 RTP data derived from?OnDemandServerMediaSubsession. I call it?H264VideoUDPServerMediaSubsession. ?In this class, function createNewStreamSource() will create an instance of class H264VideoStreamFramer, with?H264VideoRTPSource created to read from RTP. createNewRTPSink() will create H264VideoRTPSink to send data out. Then in the main function, I will create a RTSPServer, and add the mediaSession(With 1 subsession of previously created class,?H264VideoUDPServerMediaSubsession); After all, the server seems running. But if I send h.264 data to the server, the server will keep complaining: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (1080). 380 bytes of trailing data will be dropped! ... I know I must be wrong, but can you shed some light on this? Regards, & Thanks Lan Zang(Sander) From finlayson at live555.com Sat Apr 28 02:32:30 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 28 Apr 2012 02:32:30 -0700 Subject: [Live-devel] The question on how to handle the incoming H.264 RTP data of live555 server In-Reply-To: <1335600566.42903.YahooMailNeo@web15803.mail.cnb.yahoo.com> References: <1335600566.42903.YahooMailNeo@web15803.mail.cnb.yahoo.com> Message-ID: > I am new to this live555 media server. I am trying to make a server running on ubuntu that can perform the following task: > It gets h.264 video data over RTP from others (e.g. ffmpeg), then it will broadcast the video to other viewers( e.g. vlc player) via rtsp protocol. If your H.264 video source is accessible via RTSP, then you could use our new "LIVE555 Proxy Server" application, which already does all of this: http://www.live555.com/proxyServer/ > After reading the codes of live555MediaServer.cpp and testOnDemandRTSPServer.cpp and some other files plus a little guessing, I think I shall prepare a class that will treat h.264 RTP data derived from OnDemandServerMediaSubsession. I call it H264VideoUDPServerMediaSubsession. > > In this class, function createNewStreamSource() will create an instance of class H264VideoStreamFramer Almost. Because the data source (a "H264VideoRTPSource") delivers discrete H.264 NAL units (i.e., one at a time), rather than a byte stream, you must use a "H264VideoStreamDiscreteFramer", not a "H264VideoStreamFramer". Everything else looks correct, as far as I can tell. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Sat Apr 28 07:57:09 2012 From: zanglan at yahoo.com (Lan Zang) Date: Sat, 28 Apr 2012 22:57:09 +0800 (CST) Subject: [Live-devel] The question on how to handle the incoming H.264 RTP data of live555 server In-Reply-To: References: <1335600566.42903.YahooMailNeo@web15803.mail.cnb.yahoo.com> Message-ID: <1335625029.46286.YahooMailNeo@web15802.mail.cnb.yahoo.com> Ross, Thanks for your reply. I did not read the "live555 proxy server" yet. But from the name I guess this server will work as a proxy. But I am expecting to do a little different. I'd like the live555 will support the source to publish the video directly. I suppose the supporting of "RECORD" and "ANNOUNCE" in RTSP shall be added. I wander if there is any special consideration that the live555 does not support them. And for the?H264VideoStreamDiscreteFramer thing, you are right. I changed to this class, and now the errors are eliminated. Regards, Lan Zang(Sander) ________________________________ From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Saturday, April 28, 2012 5:32 PM Subject: Re: [Live-devel] The question on how to handle the incoming H.264 RTP data of live555 server I am new to this live555 media server. I am trying to make a server running on ubuntu that can perform the following task: >It gets h.264 video data over RTP from others (e.g. ffmpeg), then it will broadcast the video to other viewers( e.g. vlc player) via rtsp protocol. > If your H.264 video source is accessible via RTSP, then you could use our new "LIVE555 Proxy Server" application, which already does all of this:http://www.live555.com/proxyServer/ After reading the codes of live555MediaServer.cpp and testOnDemandRTSPServer.cpp and some other files plus a little guessing, I think I shall prepare a class that will treat h.264 RTP data derived from?OnDemandServerMediaSubsession. I call it?H264VideoUDPServerMediaSubsession. > >?In this class, function createNewStreamSource() will create an instance of class H264VideoStreamFramer Almost. ?Because the data source (a "H264VideoRTPSource") delivers discrete H.264 NAL units (i.e., one at a time), rather than a byte stream, you must use a "H264VideoStreamDiscreteFramer", not a "H264VideoStreamFramer". Everything else looks correct, as far as I can tell. 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 Apr 28 10:40:40 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 28 Apr 2012 10:40:40 -0700 Subject: [Live-devel] The question on how to handle the incoming H.264 RTP data of live555 server In-Reply-To: <1335625029.46286.YahooMailNeo@web15802.mail.cnb.yahoo.com> References: <1335600566.42903.YahooMailNeo@web15803.mail.cnb.yahoo.com> <1335625029.46286.YahooMailNeo@web15802.mail.cnb.yahoo.com> Message-ID: <6C43116F-822F-4D54-B8E1-A2B5A5480042@live555.com> > Thanks for your reply. I did not read the "live555 proxy server" yet. But from the name I guess this server will work as a proxy. But I am expecting to do a little different. I'd like the live555 will support the source to publish the video directly. I suppose the supporting of "RECORD" and "ANNOUNCE" in RTSP shall be added. I wander if there is any special consideration that the live555 does not support them. Sorry, but our server doesn't - and probably never will - support this style of proxying. If you want to do this, then I suggest using Apple's "Darwin Streaming Server" instead. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sambhav at saranyu.in Sun Apr 29 02:36:50 2012 From: sambhav at saranyu.in (Kumar Sambhav) Date: Sun, 29 Apr 2012 15:06:50 +0530 Subject: [Live-devel] RTCP Receiver Report information Message-ID: Hi, How can the OnDemand RTSP Server application get the RTCP Receiver Report information ? Regards, Sambhav From finlayson at live555.com Sun Apr 29 07:21:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Apr 2012 07:21:46 -0700 Subject: [Live-devel] RTCP Receiver Report information In-Reply-To: References: Message-ID: <6582CEE8-01A8-4DC0-BC6D-9D93884AE441@live555.com> > How can the OnDemand RTSP Server application get the RTCP Receiver Report information ? Our RTSP servers (including "testOnDemandRTSPServer") automatically receive RTCP Receiver Reports from clients. Information obtained from these reports is stored in a database (class: "RTPTransmissionStatsDB") for each "RTPSink" object. See "liveMedia/include/RTPSink.hh"; note, in particular, the function "RTPSink::transmissionStatsDB()". You would need to write your own code to keep track of each "RTPSink" object (most likely, in your implementation(s) of the "createNewRTPSink()" virtual function), and access and display the records (class: "RTPTransmissionStats") from each "RTPSink" object's database. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sambhav at saranyu.in Sun Apr 29 11:14:27 2012 From: sambhav at saranyu.in (Kumar Sambhav) Date: Sun, 29 Apr 2012 23:44:27 +0530 Subject: [Live-devel] RTCP Receiver Report information In-Reply-To: <6582CEE8-01A8-4DC0-BC6D-9D93884AE441@live555.com> References: <6582CEE8-01A8-4DC0-BC6D-9D93884AE441@live555.com> Message-ID: <506C065E-FD97-431F-A1D6-CE747207B8E1@saranyu.in> Thanks Ross. In the proposed implementation the application has to periodically query the stats. Is there a way to have an implementation where an application callback is called every time an RTCP RR is received ? Regards, Sambhav On Apr 29, 2012, at 7:51 PM, Ross Finlayson wrote: >> How can the OnDemand RTSP Server application get the RTCP Receiver Report information ? > > Our RTSP servers (including "testOnDemandRTSPServer") automatically receive RTCP Receiver Reports from clients. > > Information obtained from these reports is stored in a database (class: "RTPTransmissionStatsDB") for each "RTPSink" object. See "liveMedia/include/RTPSink.hh"; note, in particular, the function "RTPSink::transmissionStatsDB()". > > You would need to write your own code to keep track of each "RTPSink" object (most likely, in your implementation(s) of the "createNewRTPSink()" virtual function), and access and display the records (class: "RTPTransmissionStats") from each "RTPSink" object's database. > > > 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 Sun Apr 29 12:39:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Apr 2012 12:39:45 -0700 Subject: [Live-devel] RTCP Receiver Report information In-Reply-To: <506C065E-FD97-431F-A1D6-CE747207B8E1@saranyu.in> References: <6582CEE8-01A8-4DC0-BC6D-9D93884AE441@live555.com> <506C065E-FD97-431F-A1D6-CE747207B8E1@saranyu.in> Message-ID: <8B7DF681-2127-41B1-BAB4-2ED2A15AA9E2@live555.com> > Is there a way to have an implementation where an application callback is called every time an RTCP RR is received ? Yes, you can call "setRRHandler()" on the "RTCPInstance" object. See "liveMedia/include/RTCP.hh". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Mon Apr 30 11:37:20 2012 From: warren at etr-usa.com (Warren Young) Date: Mon, 30 Apr 2012 12:37:20 -0600 Subject: [Live-devel] PATCH: raw UDP mode for testMPEG2TransportStreamer Message-ID: <4F9EDBE0.9000808@etr-usa.com> Attached is a quick hack on testMPEG2TransportStreamer.cpp to give it a compile-time mode for raw UDP streaming instead of RTP. Perhaps it would be useful to include this in the next version. -------------- next part -------------- A non-text attachment was scrubbed... Name: raw-udp-mp2ts.patch Type: text/x-patch Size: 2437 bytes Desc: not available URL: From warren at etr-usa.com Mon Apr 30 12:17:43 2012 From: warren at etr-usa.com (Warren Young) Date: Mon, 30 Apr 2012 13:17:43 -0600 Subject: [Live-devel] RTP/raw UDP stream joining after stream starts Message-ID: <4F9EE557.60209@etr-usa.com> Ross, would you please look at this MP2TS file for us? http://etr-usa.com/live555/novideo.ts It always streams successfully via RTSP over raw UDP from mediaServer, but shows no video when streamed from testMPEG2TransportStreamer if the sender starts before the receiver. This doesn't happen with any other file we have tried so far. I'm guessing the problem is that some necessary bit of synchronization data appears only at the beginning of the file, so that if the client isn't receiving when it goes by, it never figures out how to decode the video properly. I see this with three different clients: testMPEG2TransportReceiver, VLC, and an STB. The patch in my previous message is a result of going down a rathole, thinking maybe the problem was in the demuxing that's part of RTP. I figured I could avoid the problem by going with raw UDP streaming, so I hacked testMPEG2TransportStreamer to do that. By the way, I've attached a new version of that patch. The previous one doesn't build if you pound out USE_RAW_UDP, and it should have that line commented out by default anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: raw-udp-mp2ts2.patch Type: text/x-patch Size: 2779 bytes Desc: not available URL: From bruno.abreu at livingdata.pt Mon Apr 30 12:19:00 2012 From: bruno.abreu at livingdata.pt (Bruno Abreu) Date: Mon, 30 Apr 2012 20:19:00 +0100 Subject: [Live-devel] StreamReplicator bug deactivating a replica? Message-ID: <20120430173439.M10739@livingdata.pt> Hello Ross and everyone I never got to thank you for fixing the race condition in H264VideoFileServerMediaSubsession and MPEG4VideoFileServerMediaSubsession (release 2011.06.14) so, thank you very much for that one. I believe I came across another bug. We are running an application in which we create 3 replicas (thank you also for the StreamReplicator) from each live source: one for multicast streaming, one for unicast streaming and another for video file storing. Soon after we started using the StreamReplicator we noticed that frequently, when a unicast client closed a session, the whole pipeline stopped. After some debugging I came across the following lines of code which I changed as you can see: ============ --- live-2012.04.27/liveMedia/StreamReplicator.cpp 2012-04-27 20:53:46.000000000 +0100 +++ live-new/liveMedia/StreamReplicator.cpp 2012-04-30 19:25:15.000000000 +0100 @@ -143,16 +143,16 @@ } } else { // The replica that's being removed was not our 'master replica', but make sure it's not on any of our queues: - for (StreamReplica*& r1 = fReplicasAwaitingCurrentFrame; r1 != NULL; r1 = r1->fNext) { - if (r1 == replicaBeingDeactivated) { - r1 = replicaBeingDeactivated->fNext; + for (StreamReplica** r1 = &fReplicasAwaitingCurrentFrame; (*r1) != NULL; r1 = &((*r1)->fNext)) { + if ((*r1) == replicaBeingDeactivated) { + (*r1) = replicaBeingDeactivated->fNext; replicaBeingDeactivated->fNext = NULL; break; } } - for (StreamReplica*& r2 = fReplicasAwaitingNextFrame; r2 != NULL; r2 = r2->fNext) { - if (r2 == replicaBeingDeactivated) { - r2 = replicaBeingDeactivated->fNext; + for (StreamReplica** r2 = &fReplicasAwaitingNextFrame; (*r2) != NULL; r2 = &((*r2)->fNext)) { + if ((*r2) == replicaBeingDeactivated) { + (*r2) = replicaBeingDeactivated->fNext; replicaBeingDeactivated->fNext = NULL; break; } ============ By using a reference, it's always the head of the list that's updated which, I believe, is not what was meant. If there is (as it happens in our case) more than one replica waiting on a frame and the replica being deactivated in not the first on that list, the replicas in front of the list are lost. Now I'm guessing a bit but I believe that then, when the frame finally arrives, the master replica will wait forever for the other replicas to ask for the current frame when, in fact, they already did (hence the pipeline halt). Using the patch above did, at least, fix the symptoms. I don't think all the parentheses I've used are necessary but I like to use them for safety. Thanks in advance for any enlightenment or new release that may fix this issue. Bruno Abreu -- Living Data - Sistemas de Informa??o e Apoio ? Decis?o, Lda. Rua Lu?s de Cam?es, N? 133, 1? B Phone: +351 213622163 1300-357 LISBOA Fax: +351 213622165 Portugal URL: www.livingdata.pt From warren at etr-usa.com Mon Apr 30 12:29:04 2012 From: warren at etr-usa.com (Warren Young) Date: Mon, 30 Apr 2012 13:29:04 -0600 Subject: [Live-devel] Cygwin doesn't include xlocale.h Message-ID: <4F9EE800.9010808@etr-usa.com> Live555 2012.04.27 builds if you add "-DXLOCALE_NOT_USED" to config.cygwin. From jshanab at smartwire.com Mon Apr 30 07:19:16 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Mon, 30 Apr 2012 14:19:16 +0000 Subject: [Live-devel] 100% CPU in tcpReadHandler in extream case. Message-ID: <615FD77639372542BF647F5EBAA2DBC20B22ACD3@IL-BOL-EXCH01.smartwire.com> From: Jeff Shanab Sent: Monday, April 30, 2012 9:15 AM To: live-devel at lists.live555.com. Subject: 100% CPU in tcpReadHandler in extream case. I have read thru the archives and found mention of this issue before but also that it had definitely been fixed in 2010.03.14. I am running 2012.2.29 libraries in my application recording 24x7 up to 45 RTSP streams running on Windows server 2008. After about a week of running the cpu will go from it's normal 15% to 100% and then stay there. If I profile the code during this time It always shows that the majority of the time is in tcpReadHandler as called from SingleStep and doEventLoop. I need to get this to last longer and would appreciate any insights to what can cause this. Potential issues. It is a VMWare VM on a decent rack mounted server. Of the 45 connections only 10 are restreaming constantly, another 10 are just waiting for the camera to announce itself and another 5 or 6 are in a retrying loop every 5-60 seconds (random backoff timer on failed connections) Sanity checks. The number of sockets in use is in line with the number of connections. So I think I am ok with socket resources. This is a 4G box with 50% of the memory free and the app taking less than 200MB. No virus or heavy disk activity. Restarting the application and waiting for streams to reconnect goes back to 15% CPU Jeff Shanab, Manager, Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [Description: Description: Description: Description: cid:706AA5FB-B29A-4B95-B275-FE31EE559CF0 at hsd1.il.comcast.net.] [Description: Description: Description: Description: Description: Description: Description: sig4] [Description: Description: Description: Description: Description: Description: Description: sig3] [Description: Description: Description: Description: Description: Description: Description: sig2] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 7675 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1494 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 1470 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 1506 bytes Desc: image004.gif URL: From john.virga at powerstream.net Mon Apr 30 07:47:12 2012 From: john.virga at powerstream.net (John Virga) Date: Mon, 30 Apr 2012 07:47:12 -0700 Subject: [Live-devel] LIVE555 RTMP Message-ID: <8153A88690F9CD4B9CD1BECC033C166602002434F4F3@EXVMBX003-4.exch003intermedia.net> Is RTMP going to be supported in the future for stream creation and acquisition? Thanks! ~ - ~ - ~ - ~ - ~ - ~ - ~ John J. Virga Advanced Services Engineer ~ - ~ - ~ - ~ - ~ - ~ - ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 30 14:32:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2012 14:32:56 -0700 Subject: [Live-devel] PATCH: raw UDP mode for testMPEG2TransportStreamer In-Reply-To: <4F9EDBE0.9000808@etr-usa.com> References: <4F9EDBE0.9000808@etr-usa.com> Message-ID: <6A99337E-F17C-4F59-BD22-363F0E8EC38E@live555.com> > Attached is a quick hack on testMPEG2TransportStreamer.cpp to give it a compile-time mode for raw UDP streaming instead of RTP. > > Perhaps it would be useful to include this in the next version. No, because streaming over raw UDP is a bad idea, and I don't want to further encourage its use. (Although raw UDP streaming works with Transport Stream data, it's still a bad idea, because you miss out on the ability of RTP to handle out-of-order network packets, and you miss out on the benefits of RTCP (for statistics monitoring and 'liveness' indications).) (Also, a UDP-streaming version of "testMPEG2TransportStreamer" would be incompatible with "testMPEG2TransportReceiver" (unless, of course, that were hacked in the same way.)) If people really want a UDP-streaming version of "testMPEG2TransportStreamer", then they can easily write their own application to do so. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 30 14:33:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2012 14:33:19 -0700 Subject: [Live-devel] LIVE555 RTMP In-Reply-To: <8153A88690F9CD4B9CD1BECC033C166602002434F4F3@EXVMBX003-4.exch003intermedia.net> References: <8153A88690F9CD4B9CD1BECC033C166602002434F4F3@EXVMBX003-4.exch003intermedia.net> Message-ID: <249D0503-9931-4DAB-B029-9F5363F1B421@live555.com> > Is RTMP going to be supported in the future for stream creation and acquisition? No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 30 14:46:16 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2012 14:46:16 -0700 Subject: [Live-devel] Cygwin doesn't include xlocale.h In-Reply-To: <4F9EE800.9010808@etr-usa.com> References: <4F9EE800.9010808@etr-usa.com> Message-ID: > Live555 2012.04.27 builds if you add "-DXLOCALE_NOT_USED" to config.cygwin. OK, I'll do this 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 Mon Apr 30 15:41:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2012 15:41:35 -0700 Subject: [Live-devel] RTP/raw UDP stream joining after stream starts In-Reply-To: <4F9EE557.60209@etr-usa.com> References: <4F9EE557.60209@etr-usa.com> Message-ID: <851195B3-339D-42B8-8E3D-336482A67375@live555.com> > Ross, would you please look at this MP2TS file for us? > > http://etr-usa.com/live555/novideo.ts > > It always streams successfully via RTSP over raw UDP from mediaServer, but shows no video when streamed from testMPEG2TransportStreamer if the sender starts before the receiver. > > This doesn't happen with any other file we have tried so far. I'm guessing the problem is that some necessary bit of synchronization data appears only at the beginning of the file, so that if the client isn't receiving when it goes by, it never figures out how to decode the video properly. Yes, that appears to be the case. Because (according to VLC) the video is MPEG-1 or 2 (packed, along with MPEG audio, into a Transport Stream), I suspect that the video contains a MPEG "Video Sequence Header" only at the beginning, so that if a receiver misses getting this, then the MPEG decoder won't be able to render the rest of the data. BTW, you can get the same effect by running tail -c +188001 novideo.ts > novideo-tail.ts i.e., to chop off the first 1000 188-byte Transport Packets. If you do this, you'll find that VLC can't play video from "novideo-tail.ts" either. Because the data is Transport Stream data - which we don't demultiplex before streaming - there's nothing we can do in our code to overcome this. You would need to demultiplex the Transport Stream and then reprocess the MPEG video to include "Video Sequence Headers" periodically, rather than just at the start of the file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 30 18:32:28 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2012 18:32:28 -0700 Subject: [Live-devel] StreamReplicator bug deactivating a replica? In-Reply-To: <20120430173439.M10739@livingdata.pt> References: <20120430173439.M10739@livingdata.pt> Message-ID: Thanks for the report. Yes, there is a bug in that code, although it wasn't quite what you thought. Try replacing those two "for" loops with the following: for (StreamReplica* r1 = fReplicasAwaitingCurrentFrame; r1 != NULL;) { if (r1 == replicaBeingDeactivated) { if (r1 == fReplicasAwaitingCurrentFrame) fReplicasAwaitingCurrentFrame = r1->fNext; r1 = r1->fNext; replicaBeingDeactivated->fNext = NULL; break; } else { r1 = r1->fNext; } } for (StreamReplica* r2 = fReplicasAwaitingNextFrame; r2 != NULL;) { if (r2 == replicaBeingDeactivated) { if (r2 == fReplicasAwaitingNextFrame) fReplicasAwaitingNextFrame = r2->fNext; r2 = r2->fNext; replicaBeingDeactivated->fNext = NULL; break; } else { r2 = r2->fNext; } } } If you find any problem with this, then please let us know ASAP. Otherwise I'll release a new version of the code with this change. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: